##Commits Regulares
Commits Regulares baseiam-se na prática de comitar suas alterações regularmente no controle de versão, ou seja, no mínimo uma vez por dia. Desta forma as alterações são disponibilizadas para outros desenvolvedores em partes, o que facilita o uso de outras praticas, como code review, integração continua, etc.
####Pontos de Atenção
Porém, desenvolvedores devem ter cuidado sobre os efeitos de seus comits, se planejando melhor, e as vezes fazendo uso de tecnicas, como configurações para habilitar e desativar uma funcionalidade.
####Porque comitar regularmente
Trabalhos complexos, seja em funcionalidades complexas, grandes refactorings; podem levar dias, as vezes semanas para serem concluídos. Isto porque o desenvolvedor evitará comitar suas alterações até que ele se sinta confiante que seu código esteja em um bom estado e que não afetará outras funções do sistema.
Praticas como essa podem ser problematicas. Ao efetuar o comite o desenvolvedor poderá ter diversos problemas de merge, e seu código acaba não sendo testado regularmente.
O controle de versão beneficia comites regulares. Em particular, é impossivel refatorar uma aplicação com segurança a menos que você comite regularmente. Comitando regularmente, suas alterações ficam disponiveis para outros integrantes da equipe verem e interagirem, trazendo uma melhor indicação que suas alterações não quebraram a aplicação. Assim merges são sempre pequenos e gerenciaveis, bugs são encontrados em uma fase onde o custo de correção ainda é baixo.
####Evite Branches para novas funcionalidades
Definindo branches: qualquer código desenvolvido por longo periodos sem integração na trunk/master.
Esta não é uma boa pratica, porque vai contra a filosofia da integração continua. Alterações na branche somente são testadas quando reintegradas, e que pode levar a diversos problemas de merge durante sua reintegração.
Uma melhor solução é desenvolver novas funcionalidades incrementalmente e comita-las regularmente. Isso mantem o software funcional e sempre testado (caso exista integração continua). A possibilidade de conflitos causados por refactorings é reduziada, problemas de integração são capturados quando o custo de correção é baixo, o que resulta em software de alta qualidade.
Com o uso de branches de longa duração o código não é testado, afinal não há integração continua em branches e, testes unitarios não são suficientes para assegurar a qualidade do código. Desenvolvimentos por longos periodos atrapalham code review e podem causar merges complicados, devido a alta quantidade de arquivos e linhas alteradas.
####Maior eficiencia
Introduzir alterações incrementalmente, após a conclusão de cada alteração, se usado corretamente, resultara em comits ao menos uma vez por dia, geralmente diversas vezes por dia. Isso pode parecer inviavel, se você não esta habituado a esta pratica, porém ela leva a um processo mais efeciente de desenvolvimento.
###Use mensagens significavas em comits
Imagine a seguinte situação:
- O desenvolvedor esta de ferias e o build foi quebrado. Em seu comit existe o comentario: "bug obscuro corrigido".
- Então você remove as alterações dele e outra parte do sistema quebra.
- Você acaba gastando diversas horas para faze-lo voltar a funcionar ou mesmo debugando o código.
Mensagens descritivas, explicando o que foi feito e porque, podem ajudar a economizar diversas horas de trabalho. Portanto não seja preguiçoso, use comentarios significativos e descritivos.
Entendi. Pois é, uma idéia que to tentando eliminar aqui é a brilhante "branch por sprint". Não consigo ver nada além de possíveis cagadas vindas disso.
Mesmo assim, o problema do código não ser testado é bem mais comportamental (do dev) do que da branch em si. Se o dev sempre escrevesse testes unitarios e etc o problema seria evitado e não impactaria na branch "estável". O code review nesse caso aconteceria no pull-request também =)
Porém, isso não justificaria long-life branches, visto o conceito de feature branches, e features podem ser quebradas em features menores na maioria dos casos. No caso de uma branch ter de ser grande, nada como um "git pull --rebase origin master" para tornar o merge o mais simples possivel posteriormente.