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