Mudando a história

Seguindo o post anterior, há algo que precisa ser conhecido para tornar todos esses commits um pouco melhores.

Considere os seguintes casos:
– você faz muitos commits e acaba com dois ou três commits que mudam todas as mesmas linhas
– você revisa seu log e vê um pequeno erro tipográfico em um dos comentários ( próximo post )
– você descobrir que um commit introduz algum código ruim ( próximo post )

Primeiro, relaxe, é muito melhor ter dezenas de commits curtos e a necessidade de alterar alguns deles ao invés de ter um commit grande com algumas linhas para editar. E não há problema em editar o histórico, desde que o histórico que você está alterando não tenha sido extraído ou mesclado por outra pessoa. Lembre- se : comprometa – se cedo, ramifique frequentemente .

Em todos esses casos, você pode usar git rebase -i :

$ git rebase -i HEAD~X

O X é o número de commits que você quer voltar na história, tome cuidado porque todos os commits nessa lista serão reescritos pelo git mesmo se você não tocá-los. A conseqüência direta disso é que quebrará o histórico para esses commits, portanto, desencadeará conflitos e problemas no momento da fusão para aqueles que já retiraram ou mesclaram esses commits.

Uma boa maneira de usar esse comando é quando você está encerrando seu branch de tópico antes de empurrá-lo: revisando uma última vez os commits que ele inclui e certificando-se de que está tudo certo. Use git cli ou um cliente GUI para verificar os commits, então use rebase -i se um dos casos listados anteriormente apareceu.

Fussssiiiioooonnnn

Você tem três commits mudando a mesma linha, o último é o bom.

Digamos que eles estejam entre os 4 últimos commits:

$ git rebase -i HEAD~4

Isso iniciará um editor com uma lista de commits desta maneira:

1 pick 9594048 adding google tracking
2 pick ff985cd changing google api key
3 pick 02a424d fixing api key
4 pick 5320563 something else

Como os comentários abaixo dessas linhas explicam, há várias coisas que você pode fazer. Vamos nos concentrar no squash e no conserto .

Os commits são listados do mais antigo ao mais novo (o último, na parte inferior, da lista é o mais novo commit da história) e suas ações em um commit afetarão o anterior (o anterior no histórico) ou a si mesmo.

squash e fixup são muito semelhantes, eles permitem mesclar dois ou mais commits em um.

Se você verificar as 4 linhas você pode ver que os 3 primeiros são semelhantes, se você pudesse verificar os diffs era evidente que commits # 2 e # 3 estão apenas fazendo pequenas mudanças para corrigir um erro de digitação ea sintaxe. Eles não estão trazendo nenhuma mudança funcional, mas permitem que o código funcione corrigindo bugs introduzidos no commit # 1.

squash permite que você junte os commits, mas reutilize as mensagens dos commits que estão sendo esmagados no commit que está sendo criado a partir deles.

fixup apenas descarta as mensagens de commit dos commits esmagados, mantendo apenas a mensagem do commit principal.

No nosso caso, não queremos manter as mensagens dos commits comprimidos, então usaremos o fixup:

1 pick 9594048 adding google tracking
2 f ff985cd changing google api key
3 f 02a424d fixing api key
4 pick 5320563 something else

Uma vez que você salve e saia do editor, git irá mesclar os commits # 2 e # 3 em # 1, então mostrará a mensagem do commit # 1 e permitirá que você edite se quiser. Feito isso, o trabalho será concluído, editado o histórico e retornado ao prompt do shell.

Se você verificar os registros, deverá fornecer algo assim:

$ git log --oneline
5320563 something else
12a544d adding google tracking
...

E voila ! Seus três commits alterando as mesmas linhas foram mesclados em um e o histórico está mais limpo.

Isso tornará a leitura da solicitação pull mais simples e isso é importante.

Os comandos squash e fixup são úteis para simplificar seus commits, na prática eles permitem que você faça toneladas de commits enquanto escreve um pedaço de código sem pensar muito sobre a aparência do histórico. Depois de ter algo limpo e funcionando, você pode facilmente limpar os commits ruins, deixando apenas um código de trabalho limpo e bonito. Mais uma vez, isso mostra como os commits são baratos no git.

Os demais casos de uso serão detalhados em outra dica, esta já é um pouco longa.