Sobre trabalhar com git workflow e pequenos commits

Nas ultimas duas sprints no trabalho, estive pesquisando e sofrendo para manter um padrão de pequenos commits, específicos e também a criação de pequenos PR's

o que não deu certo.

PR's Enorme com vários pequenos commits

No geral da coisa existia 3 problemas:

• Commits longos com várias alterações são ruins e trabalhasos de revisar e comentar
• PR's grandes com pequenos commits são muito longos e bagunçados, com muitas responsabilidades
• GIT LOCAL REFS ERRORS

Git local refs errors

Uma ótima solução para isso é começar a ramificar as branchs

• refs/origins/pix
• refs/origins/pix/logica
• refs/origins/pix/screens
• refs/origins/pix/screens/keys
• refs/origins/pix/refactor (ou tanto faz)

da pra ver que nesse caminho, o pix se torna uma pasta dentro da pasta origin que é a base no git, e a logica uma pasta dentro de pix

O problema é que isso não da certo.

O git armazena ponteiros para o HEAD de cada branch na .git, isso significa que quando crio a partir da main, um refs/origins/pix ele permite. Quando tento pix/screens ele da erro: fatal: cannot lock ref 'refs/heads/feat/pix/screens': 'refs/heads/feat/pix' exists; cannot create 'refs/heads/feat/pix/screens'

Isso por que nossa refs existe como uma master, nesse cenário, ela permite uma deepth, de 3, ou seja refs/head/feat/pix. Ainda assim, eu não quero PR's complexos ou commits fora de contexto

Solução

hello/world/master into hello/world/master allowing you to always have a master truth for all children.

cada branch pode ter o seu index, permitindo a criação de uma base no meu caso, main para o melhor workflow.

$ git checkout feat/pix/master
Switched to a new branch 'feat/pix/master'
$ git checkout -b feat/pix/screens
Switched to a new branch 'feat/pix/screens'

Isso permite:

• Melhor organização de cada branch e fatures nela, algumas branchs vão precisar de adição/refactor futuramente, mas vão existir com seus nomes já estáticos: screens | flow
• Melhores commits, mais organizados, além da liberdade de fazer commits menores, sem se misturarem com outros pontos da aplicação
• Melhores e menores PR's, alguns que possam até ser revisados de forma aberta pelo time, como os relacionados a UI screens