Os commits podem ser considerados pequenos demais? [duplicado]

14

Possible Duplicates:
git / other VCS - how often to commit?
How often should I/do you make commits?

O uso do controle de origem é muito diferente de um desenvolvedor para outro e de projeto para outro. Alguns cometem com muita frequência; outros podem passar um dia inteiro ou vários dias sem se comprometer (especialmente quando trabalham no projeto sozinhos ou sabem que outros membros da equipe estão trabalhando em partes muito diferentes do projeto).

Exemplos

Às vezes, vejo compromissos extremamente pequenos, tanto na vida real quanto em webcasts e outros materiais de aprendizagem. Alguns exemplos, principalmente da vida real, são:

  • Um commit que resolve um bug # ... ou implementa um recurso # ... alterando uma linha de código.

    IMHO, é um caso perfeitamente válido para um commit, especialmente se o sistema de rastreamento de bugs estiver vinculado ao controle de versão e for atualizado automaticamente de acordo com as revisões. Mesmo sem esse link, é útil rastrear quais commits resolveram o que, independentemente do número de alterações necessárias para resolver um bug ou implementar um recurso.

  • Uma confirmação que altera uma única configuração (dado que, no contexto, as definições de configuração devem estar no controle de origem).

    IMHO, isso pode ser mesclado às vezes com outro commit, a menos que a configuração anterior quebre a compilação ou introduza um bug ou possa afetar outros desenvolvedores (por exemplo, uma string de conexão que foi alterada após a migração do servidor de banco de dados de teste).

  • Um commit que corrige a ortografia de uma palavra, por exemplo, em uma string exibida para o usuário.

    IMHO, na maioria dos casos, isso pode ser mesclado com outro commit (a menos que, novamente, quebre a compilação). O único caso em que não pode ser mesclado é quando, se for deixado, a ortografia incorreta pode ser propagada através de código e seria muito complicada ou impossível de alterar mais tarde, como acontece com Cabeçalho HTTP referer .

  • Um commit que adiciona um comentário a um método (enquanto o método já era explícito o suficiente) ou resolve outra regra relacionada ao estilo menor.

    Exemplo: no .NET Framework, o StyleCop requer a documentação de cada método, e o comentário XMLDoc para um construtor (que também é o método) deve começar com:

    Initializes a new instance of the <Class name here> class.

    Um commit pode impor essa última regra, substituindo um comentário no código legado:

    Creates a new vehicle with the specified number of wheels.

    por:

    Initializes a new instance of the Vehicle class, using the specified number of wheels.

    Em outras palavras, a revisão não tem outro significado senão adequar a parte do código aos padrões de estilo usados na base de código.

    IMHO, isso pode ser mesclado com outro commit em todos os casos (afinal de contas, regras relacionadas a estilos devem ser aplicadas em commits para rejeitar os commits do código que não combina com eles), a menos que haja várias mudanças em vários lugares.

Perguntas

Estou errado nesses pontos?

Existe algo como um comprometimento muito pequeno, ou é uma prática de se comprometer com muita frequência uma boa prática?

Vale a pena cometer mudanças muito pequenas, já que isso "poluiria" o registro de revisão e dificultaria a localização das mudanças relevantes entre pequenas mudanças que ninguém se importa e que não quebram ou soltam a compilação, nem afeta outros desenvolvedores?

    
por Arseni Mourzenko 23.02.2012 / 18:49
fonte

4 respostas

31

Errado é uma palavra muito strong, porque isso é uma questão de estilo / preferência. No entanto, minha preferência é aparentemente diametralmente oposta à sua.

Eu prefiro muito mais ver edições de estilo de código e pequenas alterações de documentação feitas em seus próprios commits. Se eu estou fazendo uma revisão de código, ou tentando descobrir onde um bug foi introduzido, é muito mais fácil se cada commit não tocar em meia dúzia de problemas aleatórios. No meu mundo, um commit ideal conserta um bug ou completa um recurso. Dessa forma, se a correção ou o novo recurso acabarem tendo algum problema sério, o backup será muito mais fácil: você não precisa tentar desvendar um pacote de mudanças não relacionadas ao problema.

Agora, se você tiver um lote de alterações que são apenas problemas de documentação / formatação, sinta-se à vontade para agrupá-las e seu comentário de confirmação deverá indicar "Apenas alterações de formatação / documentação".

    
por 23.02.2012 / 19:08
fonte
8

Primeiro, não acho que haja uma resposta a essa pergunta. Como você aponta, difere muito entre indivíduos e projetos.

Eu aplico algo como a ideia de SoC (Separation of Concerns) para commits. Ou seja, tento me comprometer em uma base "por tarefa". Ou, em outras palavras, evite cometer "várias áreas de trabalho" de uma só vez. Nesse sentido, não existe compromisso muito pequeno.

    
por 23.02.2012 / 19:06
fonte
5

Pequenos commits são ótimos. IMHO, quanto menor, melhor. Em particular, pequenos commits são bons porque são facilmente passíveis de revisão. Eu prefiro rever 5 pequenas mudanças independentes do que 1 mudança maior que incorpora todas elas.

    
por 23.02.2012 / 19:28
fonte
3

Eu não acho que qualquer commit seja pequeno demais, desde que o comentário seja preciso; falta de comentários ou cometer erros são repreensíveis.

Pessoalmente, prefiro enviar alterações em grupos lógicos, por exemplo, um commit para refatoração antes de fazer qualquer mudança lógica, depois outro para mudanças para corrigir o bug.

Eu também prefiro que os comentários contenham alguns detalhes, por isso vou olhar todos os arquivos que foram alterados para reunir as alterações relacionadas que podem ser cobertas pelo mesmo comentário, separando aqueles que precisam de alguns detalhes que não se aplicam a outros arquivos.

    
por 23.02.2012 / 19:23
fonte