Com controle de versões, não é necessário que tudo seja tão amarrado. É responsabilidade de cada um “mesclar” suas modificações ao fazer o “commit”. O que o artigo diz, é que o programador deve conhecer o paradigma para não atrapalhar os outros. Fazer “commit” só pra fazer backup atrapalha todos os outros.

A solução é: (eu acho)
* Modifica-se o código.
* Testa-se.
* Update.
* Resolução de conflitos.
* Commit.

Os commits devem ser os menores possíveis que não “quebrem o build”. Claro que “quebrar o build” por acidente não é um problema tão grave. O time pode simplesmente voltar para uma versão anterior enquanto alguém arruma o problema. Assim a equipe não precisa parar.

Um efeito colateral indesejado de se fazer “commits de backup” é que os desenvolvedores não irão fazer “updates” com tanta freqüência. Para evitar “updates” vão evitar “commits”. Assim, os problemas serão detectados mais tardiamente. Só haverão “commits de backup”.

Se você tiver “ramos” (branches) no controle de versões é ainda pior. Se, com tantos “commits de backup” já é difícil fazer update no tronco principal, imagine mesclar diferenças entre os “ramos” e o tronco principal? E se der conflito, como você vai decidir qual é o código correto se o “commit” está incompleto?

André Caldas.