Para que você tenha um histórico claro e conciso do git que documenta de maneira clara e fácil as alterações feitas e os motivos.
Por exemplo, um típico log do Git 'não confinado' pode ser parecido com o seguinte:
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
787g8fgf78... hotfix for #5849564648
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test
Que bagunça!
Considerando que um log git mais cuidadosamente gerenciado e mesclado com um pouco de foco adicional nas mensagens para isso pode parecer:
7hgf8978g9... 8483948393 Added new slideshow feature
787g8fgf78... 5849564648 Hotfix for android display issue
9080gf6567... 6589685988 Implemented pop-up to select language
Eu acho que você pode ver o ponto de esmagar commits geralmente e o mesmo princípio se aplica a pull requests - Readability of the History. Você também pode estar adicionando a um log de commit que já tem centenas ou até mesmo milhares de commits e isso ajudará a manter a história crescente curta e concisa.
Você quer se comprometer com antecedência e com frequência. É uma prática recomendada por vários motivos. Eu acho que isso me leva a freqüentemente ter commits que são "wip" (trabalho em andamento) ou "parte A done" ou "typo, minor fix" onde estou usando o git para me ajudar a trabalhar e me dar pontos de trabalho que Eu posso voltar se o seguinte código não estiver funcionando enquanto eu progrido para fazer as coisas funcionarem. No entanto, eu não preciso ou quero esse histórico como parte do histórico final do git para que eu possa esmagar meus commits - mas veja as notas abaixo sobre o que isso significa em um branch de desenvolvimento vs. master.
Se houver marcos importantes que representem estágios de trabalho distintos, ainda é aceitável ter mais de um commit por recurso / tarefa / bug. No entanto, isso pode destacar o fato de que o ticket em desenvolvimento é 'muito grande' e precisa ser dividido em partes menores que podem ser autônomas, por exemplo:
8754390gf87... Implement feature switches
parece "1 trabalho". Ou eles existem ou não! Parece que não faz sentido quebrá-lo. No entanto, a experiência me mostrou que (dependendo do tamanho e da complexidade da organização) um caminho mais granular poderia ser:
fgfd7897899... Add field to database, add indexes and a trigger for the dw group
9458947548g... Add 'backend' code in controller for when id is passed in url.
6256ac24426... Add 'backend' code to make field available for views.
402c476edf6... Add feature to UI
Pequenas peças significam revisões de código mais fáceis, testes de unidade mais fáceis, melhor oportunidade para qa, melhor alinhamento ao Princípio de Responsabilidade Única, etc.
Para os aspectos práticos de quando realmente fazer tais abóboras, há basicamente dois estágios distintos que têm seu próprio fluxo de trabalho
- seu desenvolvimento, por exemplo puxar pedidos
- seu trabalho adicionado à ramificação da linha principal, por exemplo mestre
Durante o seu desenvolvimento você se compromete 'cedo e freqüentemente' e com mensagens rápidas 'descartáveis'. Você pode querer esmagar aqui às vezes, por exemplo squashing em wip e todo commit de mensagens. Está tudo bem, dentro do ramo, manter vários commits que representam etapas distintas feitas no desenvolvimento. A maioria das abóboras que você escolhe fazer deve estar dentro dessas ramificações de recursos, enquanto elas estão sendo desenvolvidas e antes de mesclar para mestre. Ao adicionar à ramificação da linha principal, você deseja que as confirmações sejam concisas e formatadas corretamente de acordo com o histórico da linha principal existente. Isso pode incluir o ID do sistema do Ticket Tracker, por exemplo, JIRA como mostrado nos exemplos. A prática de squashing não se aplica realmente a menos que você queira 'fazer roll-up' de vários commits distintos no master. Normalmente você não faz.
Usar --no-ff
ao mesclar para o mestre usará uma confirmação para a mesclagem e também preservará o histórico (na ramificação). Algumas organizações consideram isso uma boa prática. Veja mais em link Você também verá o efeito prático em git log
, em que --no-ff
commit será o último commit , no topo da HEAD (quando acabou de fazer), enquanto que sem --no-ff
pode estar mais abaixo na história, dependendo das datas e outros commits.