Quando comprometer o código?

57

Ao trabalhar em um projeto, o código pode ser desenvolvido razoavelmente rápido em um único dia ou pouco a pouco por um período prolongado de algumas semanas / meses / anos. Como commits de código estão se tornando uma medida de desenvolvimento de projeto, não significa que ele tenha mais código escrito do que um projeto com menos commits.

Então a questão é quando realmente fazer um commit no repositório para que o commit seja justificável?

Como um complemento: é uma prática correta medir o desenvolvimento de um projeto com base em seus commits?

    
por gnat 14.06.2011 / 17:18
fonte

11 respostas

77

Você confirma quando atinge um estado de base de código que deseja lembrar. Existem muitas razões pelas quais você pode querer lembrar de um estado de base de código específico, portanto, não pode haver regras rígidas sobre quando confirmar. No entanto, o número de commits definitivamente não é uma medida de qualidade ou progresso.

    
por 14.06.2011 / 17:26
fonte
30

Eu gosto de pensar em codificação como escalada neste contexto. Você sobe um pouco e depois coloca uma âncora na rocha. Se você alguma vez cair, a última âncora que você plantou é o ponto que te prende, então você nunca cairá mais do que alguns metros. O mesmo com o controle de origem; você codifica um pouco, e quando você alcança uma posição um pouco estável, você confirma uma revisão. Se você alguma vez falhar horrivelmente, você pode sempre voltar para a última revisão, e você sabe que é estável.

Dito isso, se você trabalha em uma equipe, é normal certificar-se de que o que quer que você faça seja completo, faça sentido, construa de forma limpa e não quebre as coisas de outras pessoas. Se você precisar fazer alterações maiores que possam interferir no trabalho de outras pessoas, crie uma ramificação para que você possa se comprometer sem incomodar ninguém.

Também depende do sistema SCM que você está usando. Os sistemas distribuídos geralmente tornam a mesclagem e o bifurcação simples e rápida, e você pode comprometer localmente; isso significa que você deve se comprometer muito e pressionar / fundir quando tiver feito uma quantidade substancial de trabalho. Com sistemas centralizados como o svn ou o cvs, o commit é mais caro e afeta a todos. Ramificação parcialmente resolve esse problema, mas porque isso acontece no servidor, pode ser dolorosamente lento e mesclar pode ser complicado. Assim, com SCMs centralizados, geralmente há uma cultura mais cuidadosa, na qual você só se compromete depois de ter feito uma quantidade significativa de trabalho.

Quanto ao add-on: Por favor, por favor, não faça isso. Linhas de código, número de commits, número de bugs encontrados / resolvidos, etc., são medidas muito ruins de qualidade ou mesmo quantidade.

    
por 14.06.2011 / 17:42
fonte
13

Se você estiver usando o DVCS como o Mercurial ou o Git, você deve se comprometer com o seu repositório local sempre que tiver feito uma quantidade significativa de trabalho. No entanto, apenas envie-o para o repositório compartilhado somente depois que ele estiver funcionando, uma mudança independente que tenha sido testada.

Para o VCS não distribuído (como, por exemplo, SVN), a mesma lógica se aplica, em vez de o repositório local usar a ramificação privada, em vez de mesclar por push com a ramificação principal.

    
por 14.06.2011 / 17:43
fonte
9

Você deve se comprometer com antecedência e com frequência.

Eu conheço pessoas que se comprometem a cada 90 segundos. A sério. Parece funcionar para eles. Eu experimentei cometer cada vez que eu salvar um arquivo, que é provavelmente mais do que 90 segundos. Hoje, eu provavelmente me comprometo a cada 15 minutos. Um VCS que permite esmagar vários commits em um e que permite commits locais (como o git) torna isso muito mais fácil.

Com que frequência você deve se comprometer? Difícil dizer, mas provavelmente com mais frequência do que você é agora. Continue a cometer cada vez mais frequência, encontre um ponto que pareça absurdamente frequente e, em seguida, recue um pouco. Provavelmente você vai acabar com algo razoável.

Você mede o desenvolvimento de um produto com base no valor entregue aos usuários. Não há outra medida precisa.

    
por 14.06.2011 / 17:50
fonte
7

Confirme somente quando você testou com sucesso a função / módulo / funcionalidade dada e você está razoavelmente seguro de que ela está pronta para integração ou teste do sistema.

E para responder às suas perguntas adicionais - NÃO !! a medida de onde o projeto está nunca deve ser determinada pelo número de commits ... quem sabe o que foi realmente cometido? Foi testado com sucesso pelo sistema ou testado em unidade. Só porque está comprometido - não significa que esteja pronto para produção.

    
por 14.06.2011 / 17:21
fonte
7

As confirmações são os blocos de construção de qualquer dado / código controlado pela versão. Cada commit deve fazer exatamente um dos seguintes:

  • Adicione uma nova peça de dados ou função
  • Corrija um ou mais bugs (um commit para cada correção, se possível), onde a correção pode ser:
    • Melhoria do desempenho
    • Corrigindo o comportamento incorreto do código
    • Removendo erros tipográficos
  • Refatorando código ou dados sem alterar a semântica. Isso inclui:
    • Reescrevendo o código que se comporta de maneira idêntica ao original
    • Alterando a representação de dados para um formato diferente
    • Formatando código ou dados para atender às diretrizes de formatação do projeto
  • Mesclar alterações de outra ramificação (upstream / downstream)

Além disso, ao trabalhar em ramificações, os commits devem ir para uma ramificação que seja mais adequada. Dois commits não devem ter a mesma mensagem de commit (implicando mudanças similares), mas em diferentes branches, pois confunde os colaboradores. Uma maneira melhor é se comprometer com a ramificação principal e mesclar com o ramo de recursos.

Se os committers seguirem a regra acima, será trivial:

  • Reverter uma alteração específica sem efeitos colaterais
  • Identifique o comportamento alterando a alteração de código das alterações de formatação de código
  • Mesclar entre diferentes ramos, evitando a maioria dos conflitos
  • Colabore com outros desenvolvedores que podem extrair suas alterações com facilidade

Em relação ao progresso do projeto de medição baseado em commits, é possível que commits de Refactoring e consertos de Bug fixos não sejam levados em conta.

    
por 14.06.2011 / 20:42
fonte
6

As a add-on: Is it a correct practice to measure a project's development based on its commits?

Não. Há um diário WTF sobre o porquê essa é uma idéia horrível.

Minha regra geral para confirmar o código é fazer o check-in quando eu completar um trecho de código e ele compilar. O pedaço não está realmente definido. Se for uma tarefa pequena, talvez eu não faça o check-in até que eu termine. Se for maior, eu posso fazer check-in após cada parte lógica ser concluída.

Mas nunca verifique se não compila. Eu sei que parece uma coisa estúpida para dizer em voz alta, mas eu tive que explicar isso para as pessoas antes.

    
por 14.06.2011 / 17:27
fonte
1

Faça um commit quando o código estiver pronto para ser compartilhado com outros usuários do código - quando estiver relativamente estável, seguro e devidamente testado.

E não, eu não acho que os commits sejam uma ótima métrica para o desenvolvimento de um projeto, porque eu conheço alguns desenvolvedores que irão cometer pequenas e pequenas alterações, e outros que irão cometer apenas grandes mudanças na funcionalidade. Como você mede quantitativamente o valor de um commit em detrimento de outro?

    
por 14.06.2011 / 17:23
fonte
1

Assim que a tarefa correspondente for concluída . Uma tarefa faz parte de uma história do usuário .

Uma tarefa é executada quando:

  • a unidade correspondente testa passe,
  • O código
  • está devidamente documentado e
  • o código é confirmado.

Você pode ter uma definição diferente de feita .

Não vejo o valor em medir o número de confirmações. No entanto, se você vê alguém trabalhando por um longo período na mesma história de usuário (ou pior, histórias), isso é um cheiro.

    
por 14.06.2011 / 17:34
fonte
1

Confirme todas as mudanças significativas que você acha que não quebram alguma coisa. A única coisa que você não deve cometer são mudanças de estilo porque elas não incorporam mudanças na lógica. Mas por outro lado, quanto menores forem as alterações, melhor.

Quanto menor o commit, mais detalhado você pode documentar o processo de pensamento, que é um aspecto de um bom log de commit. Uma boa revisão de código não deve ser apenas sobre o resultado do código, mas também sobre o processo de pensamento.

Além disso, ter muitos commits pequenos facilita a divisão, um recurso muito pouco usado no controle de versão, que me salvou muitas horas procurando bugs nas bases de código do palheiro.

Bissetrando em resumo; Descubra um problema na base de código atual. Em seguida, escolha um commit no changelog onde você tem certeza de que o problema específico não existe. Comece verificando o commit no meio entre a versão "boa" e a "ruim". Teste para ver se o problema ainda está presente. Se for, você precisa olhar mais para trás, no meio do "bom" e do commit testado anteriormente. Se o problema desaparecer, ele será introduzido após essa alteração específica, portanto, você precisa verificar o meio entre o "mau" e o commit testado anteriormente. Repetir. Eventualmente, você terminará com o commit que apresentou o problema. Mas somente se você tiver pequenos commits, senão você saberá apenas em qual grande quantidade de mudanças a questão passou a existir.

Aqui é como funciona com o Git, mas o principal se aplica a qualquer controle de versão.

    
por 12.08.2016 / 11:10
fonte
-1

Quando:

  • constrói (SEMPRE)
  • testes de unidade passam
  • funciona (a menos que esteja claramente marcado como "trabalho em andamento")
  • os benefícios de salvar o estado do código outweight o incômodo de executar os testes, pensando em uma boa mensagem de confirmação e resolvendo quaisquer conflitos de mesclagem durante o processo de confirmação
por 14.06.2011 / 17:55
fonte