TL; DR : comprometer e ramificar é barato com o git, então pare de se preocupar com isso: divida seus recursos em pequenos blocos e faça commit no início e com frequência .
Git é uma ferramenta maravilhosa, mas muitos de nós o usamos como um svn glorificado . Git não é apenas sobre recursos, mas também sobre fluxos e devemos prestar mais atenção a isso ao aprender ou ensinar sobre git.
Git é um software de controle de versão distribuído , com o git é barato criar commits ou branches:
– o commit / branching não requer um acesso a um servidor central
– o commit / branching não impacta diretamente outros desenvolvedores
– o commit / branching leva alguns segundos para acontecer
– mesclar e diferenciar commits / branches é muito rápido
Como eu disse a um jovem desenvolvedor recentemente: pare de se preocupar em terminar isso ou aquilo antes de se comprometer, apenas comprometa-se assim que passar uma etapa . É claro que é bom terminar um recurso inteiro antes de cometer ou fazer um novo branch, mas tornará isso muito mais difícil a médio e longo prazo quando outros desenvolvedores (ou você) olharem para trás, farão alguns diffs, patches, proporão mudanças etc. ..
Assim, chegamos ao ponto importante: comprometa – se cedo, ramifique frequentemente .
Desenvolvedores jovens ou bagunceiros (como eu) tendem a se apressar em escrever código para implementar o recurso X ou Y; este é um péssimo hábito. Não há problema em fazer isso se você quiser apenas testar e verificar uma ideia, mas deve apenas descartar o código depois de concluir o teste.
Depois de saber para onde ir, você precisa dividir o recurso que deseja adicionar em alguns blocos . Cada tijolo precisa ser o menor possível: um ou dois (unidade ou integração) testes para adicionar para descrever o tijolo e o correspondente um ou dois métodos para escrever (ou alterar) para fazê-los passar.
Agrupe os tijolos por dependência de um ao outro, se você tiver 10 tijolos para fazer, com cerca de 10 a 20 testes e métodos para escrever e todos eles são “dependentes” uns dos outros, você pode ter que voltar ao quadro branco e pensar novamente.
Agrupar dois ou três blocos provavelmente está ok, dez não, dez está começando a ser um monte de código para envolver a mente.
Cada grupo de tijolos se tornará um branch tópico, já que cada grupo não depende de outro que você possa ramificar do master ou de qualquer branch de pré-produção em que sua equipe esteja trabalhando.
Isso tornará o processo de desenvolvimento mais rápido: você pode enviar ramificações de tópico mais cedo, já que são menores, seus colegas desenvolvedores podem verificá-los mais cedo, comentá-los e aceitar as solicitações de pull mais cedo também. Por serem pequenos, levam menos de um pomodoro para conferir cada um, por isso não atrapalha muito o próprio ritmo.
Você pode não terminar o dia com todo o recurso no branch principal, mas já parte dele está, foi comentado, melhorado e aprovado por outros e, possivelmente, desencadeou alguma refatoração no trabalho de outros desenvolvedores.
O objetivo por trás de tudo isso é enviar o código rapidamente . Em 2012, até 15 de agosto, o GitHub teve mais de 2300 implantações de produção (desde 1º de janeiro), com uma média de 10 por dia! Este é o caminho a seguir: para cada implantação, provavelmente havia várias solicitações de pull e mesclagens envolvidas no upstream, então você pode imaginar o ritmo que isso implica.
Commits curtos são mais fáceis de ler e envolver a mente, então são pequenos ramos de tópicos (5 commits ou menos). Ajuda a verificar, comentar, melhorar e enviar o código rapidamente.
Lembre – se : commits e branches menores também implicam em menos complexidade no código, o que significa menos bugs.
commit cedo, ramifica frequentemente .
Para ter uma visão mais ampla sobre a qualidade do código, você deve conferir esta palestra de Brandon Keepers (GitHub): https://speakerdeck.com/u/bkeepers/p/why-our-code-smells .
Respostas relacionadas:
Forçar um “git stash pop”