Sobre o aprimoramento das práticas de consolidação

Eu estava pensando em maneiras de melhorar minhas práticas de consolidação.

Existe alguma co-relação entre não. de linhas de código fonte e não. de confirmações?

Em um projeto recente em que estive envolvido, obtive 30 confirmações por 1000 linhas.

Um arquivo típico do projeto possui essas estatísticas

language: JavaScript
total commits that include this file: 32

total lines: 1408
source lines: 1140
comment lines: 98

no. of function declarations: 28
other declarations: 8

Outro arquivo tem esses ...

Language: Python
total commits that include this file: 17

total lines: 933
source lines: 730
comment lines: 80

classes: 1
methods: 10

Eu também acho que não. de confirmações está mais relacionado a não. de recursos ou não. de alterações no código e menos no não. de linhas.

O lema geral da comunidade git é fazer pequenos commit e comprometer-se frequentemente.

Então, você realmente pensa em comprometer a estratégia antes de iniciar o projeto. Por falar nisso, existe algo como estratégia de confirmação? Se sim, qual é a sua?

Se você estiver usando um DVCS, deverá estar comprometendo com muita frequência. Eu confirmo toda vez que meu código está em um estado estável, que não está relacionado a linhas de código. Você deseja uma árvore com muitos pequenos commits atômicos que facilitam a visualização do que você fez em cada um. Se você está tentando rastrear uma regressão encontrada ao testar, isso facilita muito a pesquisa binária e a confirmação exata, porque você terá menos alterações por confirmação. Eu só confirmo quando meu código é compilado - minha idéia de "atômico" é que ele compila, passa nos testes de unidade de regressão e passa em um teste de integração rápida. Às vezes, um teste de unidade é incluído, e às vezes não.

Quando você pressiona, deve pressionar todos os recursos. O resto do mundo não deseja que seus "erros de verificação neste arquivo" sejam confirmados todos os dias. O Git fornece rebase, o que permite que você limpe sua árvore de consolidação pressionando vários commit juntos. A comunidade parece estar incerta sobre quanta história você deve comprometer. Eu diria que você deve juntar os commits que não mostram nada da história, como "arquivo perdido" ou "regressão burra". Você deseja apresentar uma história o mais limpa possível, para que todos possam ver facilmente o que você fez.

Em um sistema de controle de versão centralizado, você precisa comprometer muito mais se quiser manter um bom histórico. Minha recomendação é que você trabalhe em recursos menores e conclua-os o máximo que puder antes de confirmar. Seu conceito de "atômico" aqui deve ser um recurso que funcione e seja testado. Você não deseja comprometer nada que interrompa os espaços de trabalho de outros desenvolvedores, porque eles serão atualizados com frequência e é muito mais difícil trabalhar em recursos independentes que se sobrepõem. Você comprometerá menos, mas esses comprometimentos geralmente serão mais difíceis do que o seu DVCS médio.

Você pode ver que a proporção de linhas de código e número de confirmações depende do tamanho dos seus recursos e do fluxo de trabalho que você usa. Seu fluxo de trabalho será diferente, dependendo do sistema de controle de versão que você usa, portanto, geralmente não é possível prever como serão as suas confirmações. Cada instituição possui seu próprio padrão e deve determinar por si mesma qual deve ser o fluxo de trabalho ideal.

Eu tive commits para correções de bugs que mudaram um caractere . O tamanho não é realmente o fator determinante aqui. Uma boa regra geral é confirmar sempre que você puder pensar em uma mensagem de confirmação que faça sentido. Quando compartilhar seus commits é uma pergunta diferente. Isso varia de acordo com a cultura do seu grupo, mas geralmente envolve você estar razoavelmente confiante de que suas alterações funcionam conforme o esperado.

Não acho que o número de confirmações deva estar relacionado ao número de linhas. Mais provável para problemas resolvidos / características introduzidas. Eu uso essa abordagem bastante simples (git):

• Comprometa-se frequentemente com a ramificação local, mas somente quando algo relevante muda (problema intrigante resolvido, adiciona alguns arquivos / funções importantes). Dessa forma, você pode navegar facilmente entre as etapas que levaram à solução final do que você estava trabalhando em determinado momento.
• Mesclar confirmações locais em uma única confirmação relacionada ao recurso / problema ao enviar para o repositório remoto / público. Dessa forma, tudo o que você fez e tornou-se público, é bem descrito e coerente, para que todos saibam o que você estava fazendo (ou pelo menos tenha uma breve ideia).

No geral, o que você faz localmente é para você - mantenha a abordagem que funciona para você. As confirmações públicas devem ser mais bem pensadas, mas eu não desenvolveria uma estratégia totalmente nova se a equipe já tivesse uma abordagem de trabalho. Fique consistente com os outros.

Para a posteridade, confirme todos os arquivos relacionados a um bug / recurso em uma revisão. Isso o ajudará imensamente mais tarde, quando você precisar saber quais arquivos foram tocados para corrigir um bug.

Tornará mais fácil voltar e ver o que você fez para ver 5 arquivos registrados no bug # 783, em vez de tentar rastrear 5 confirmações (uma para cada arquivo). Isso pode ser aliviado se você tiver uma melhor integração de controle de origem / fluxo de trabalho que corresponda a um check-in para um item de job / bug / feature / backlog. Ainda confirme com frequência, mas coloque os arquivos / recursos relacionados no mesmo check-in sempre.

Se você tiver seu IC configurado para "criar cada confirmação", isso ajudará você a fazer isso.