Quam criou essa política tem que apanhar com um gato morto até ele miar.

Falou tudo! Pensei isso antes mesmo de acabar de ler o texto.

Aqui no trabalho usamos branhces para implementar novas funcionalidades. Antes comitavamos sempre no trunk mas isso trazia uma perda de velocidade, pois se alguem tivesse terminado uma funcionalidade “nao poderia” colocar em produção pois as outras funcionalidade inacabadas tambem faziam parte desse codigo e estavam comitadas no trunk. É claro que antes de colocar em producao poderiamos “limpar” o codigo e retirar qualquer vinculo com as funcionalidades inacabadas, mas nao faziamos isso. ;-)

O que fazemos para minimizar os conflitos na hora do merge é o segunte: Cada desenvolvedor faz diariamente a “absorção” do codigo que está no trunk. Assim a “distância” entre o trunk e a branch nao tende a ficar grande e quando for a hora de fazer o contrario (jogar no trunk as modificacoes da branch) a tendência é que nao existam conflitos, pois como a branch é a implementacao de uma coisa nova, essa “coisa” é novidade no trunk. Mesmo que a branch altere um codigo existente no trunk, as absorções diárias evitam conflitos nesses códigos.

Estamos trabalhando assim há alguns meses e tem funcionado muito bem. A velocidade que gahamos é que sempre que uma funcionalidade acaba de ser implementada é feito o merge dessa branch com o trunk e o “novo” sistema já pode ir pra produção.

E atribuimos em nossa polita que haverá um lock de dados quando alguém for fazer alguma iteração de dados.

“Imagine uma equipe com 10 desenvolvedores que usam a política de sempre fazer o commit das alterações feitas durante o dia antes de ir embora da empresa.”

Quam criou essa política tem que apanhar com um gato morto até ele miar. Só se dá commit quando vc tem algo completo e compilável, de preferência junto com a documentação correspondente sob o mesmo tag para eventuais consultas.

@el_foo
O que ele quis dizer é que pdoe comitar o código quebrado em um branch privado, mas que na hora do merge, o último commit tem que estar funcionando direito. Funciona, mas não acho uma boa idéia, pois estimula uma má pratica (commit de código quebrado) e dá trabalho extra, merges de projetos grandes são penosos