##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.
concordo com o @dstori e incremento que, ao menos com git, branches podem ser testadas separadamente em forma de pull-requests (Exemplo).
Ainda quanto ao git: git incentiva o uso de branches, logo, o seu item sobre branches iria contra a filosofia deles (feature-branches). Claro, falando de SVN, concordo plenamento contigo.
Quanto aos outros itens, fully agreed, e acredito que o uso de git acarreteria em uma maior quantidade de commits, feedbacks constantes e etc (embora o git em si não seja o tópico desse gist).