Quais são as boas estratégias de check-in de controle de origem para grandes tarefas?

A regra geral é manter os check-ins pequenos e fazer check-in com frequência. Mas, às vezes, a tarefa exige grandes alterações na estrutura subjacente. Em seguida, fazer o check-in antes de executar a tarefa interromperá o projeto até você fazer o check-in do trabalho finalizado.

Então, quais estratégias as pessoas usam para reduzir o risco de perder o trabalho ou decidir que algo está sendo feito é a abordagem errada e depois mudar de idéia depois de remover o código e tentar outra abordagem?

Quando eu puder, eu vou fazer o check-in, meio trabalho comentado ou, se ele compilar e nada estiver usando novos arquivos, eu os verificarei. Quanto maior a alteração, maior a probabilidade de eu ramificar o projeto e depois voltar atrás quando eu tiver tudo funcionando novamente. Outra opção que o sistema de controle de origem permite são os conjuntos de prateleiras, que são basicamente pequenos ramos. Então, quando terminar o dia ou chegar a um ponto de decisão, arquivarei minhas alterações e, se algo catastrófico acontecer, ou se eu quiser voltar a esse ponto, posso.

Eu uso o git, então minha resposta é "branch". Ramifique e comprometa a refeição à medida que você completa os vários bits.

Empurre seus commits a montante como você está feliz, para que seus colegas possam revisar as alterações sem interromper o tronco.

Quando todos estiverem satisfeitos com o código, mescle e pronto!

(O que eu costumo fazer para ramificações de execução relativamente longa é mesclar periodicamente o tronco (mestre, na terminologia git) em minha ramificação, para que as duas ramificações não divergam radicalmente.

Eu acho que a resposta vai variar com base no tipo de sistema de controle de versão que você está usando: centralizado (por exemplo, subversão) ou distribuído (por exemplo, git). Eu não tenho nenhuma experiência no mundo real com o uso de um sistema de controle de fonte distribuído, então minha resposta é baseada no que fazemos com o subversion.

Se houver uma grande mudança em andamento que interromperá a construção de nosso tronco por um período de tempo ou que realmente atrapalhará o restante da equipe de alguma outra maneira, criaremos uma filial. Eu diria, no entanto, que você deve fazer o máximo possível para evitar ter que fazer isso - a maioria das alterações pode ficar lado a lado com o restante do código com pouco esforço. Por exemplo, você pode acionar caminhos de código no novo código (com instruções if simples ou injetar as novas versões com base nas definições de configuração se estiver usando uma estrutura DI). Então, quando você terminar, basta alterar a configuração para a nova versão, testar tudo, excluir o código não utilizado, testar novamente e finalmente excluir a configuração. Você nem sempre pode fazer isso, mas devido à sobrecarga de manter um ramo, acho que você deve sempre verificar se isso é possível.

Se você ramifica, acho que o erro que muitas vezes vejo as pessoas cometem é não manter a ramificação atualizada com o tronco. Você deve estar constantemente mesclando alterações do tronco no seu ramo enquanto ele existir, para que, quando terminar, a mesclagem inversa de tudo de volta seja bastante trivial.

Em nossa equipe, usamos o subversion e normalmente cometemos pequenas alterações diretamente no tronco. Para tarefas maiores, o desenvolvedor que trabalha nele normalmente cria uma ramificação privada, que é mesclada no tronco depois de concluída. Em seguida, o ramo privado é excluído. Naturalmente, enquanto o ramo privado existe, seu proprietário deve fazer o check-in com frequência.

Tentamos evitar ramificações de longa duração e mesclagens de tronco a ramo, porque isso exige contabilidade cuidadosa. Em vez disso, temos ramificações de vida relativamente curta que são mescladas novamente ao tronco uma vez e são excluídas logo depois.

E temos uma regra de que nada pode ser confirmado ou mesclado ao tronco até que pelo menos uma outra pessoa examine as alterações e as aprove.

Assim como o comentário usual das pessoas do servidor SQL "depende"

Se você puder, sugiro que você crie uma ramificação no código para continuar aplicando pequenos check-ins do seu trabalho. Depois de concluído, faça uma mesclagem no tronco principal.

Sim, existe alguma chance de duplicar o esforço de fazer isso. mas pelo menos você manterá uma trilha de trabalho que poderá revertê-la.