##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.
Sim o git facilita o uso de branches, afinal tudo são branches.
Porém, o principal motivo de se evitar branches, é um longo periodo (superior a um dia) sem comitar na trunk /master.
Isso faz com que suas alterações não sejam testadas, além de impactar em outras boas praticas, como code review, por exemplo.
Afinal gostariamos evitar problemas com conflitos, merges, falta de testes e, melhorar a qualidade do código.