Por que devo escrever uma mensagem de confirmação?

Por que devo escrever uma mensagem de confirmação? Eu não quero e acho que é estúpido toda vez.

Um front-end da GUI que eu uso, que ficará sem nome, força você a fazê-lo. Eu ouço outros fazendo isso sempre, mesmo que estejam usando o VCS na linha de comando.

Se eu me comprometer várias vezes ao dia e não terminar um recurso, sobre o que estou escrevendo? SOMENTE escrevo uma mensagem depois de muitas confirmações e sinto que é hora de uma mini tag ou quando faço uma tag real.

Estou certo ou estou faltando alguma coisa? Também estou usando um sistema distribuído

Para todas as pessoas que dizem "confirmar apenas quando você tiver uma mensagem útil e bem pensada para escrever, e quando seu recurso estiver 100% completo e você tiver testes de unidade", eu digo: você ainda está na mentalidade do SVN .

Se você estiver usando git , é o que eu chamaria de fluxo de trabalho inteligente:

1. Confirme quantas vezes quiser . Escreva qualquer mensagem rápida antiga lá. Ninguém vai ver de qualquer maneira.
2. Depois de dizer, 10 confirmações, você concluiu o recurso em que estava trabalhando. Agora escreva testes e confirme esses testes. Ou o que mais você quiser. Se você gosta de TDD, escreva testes primeiro, eu não ligo, nem o git.
3. git rebase -idesde o primeiro commit 'bagunçado', você adicionou e corrigiu seu histórico local esmagando, editando, omitindo e limpando seu histórico recente em commits lógicos e limpos com boas mensagens .
4. Após a limpeza, peça a alguém para retirar você.
5. Enxague e repita.

Observe que a etapa 3 é quando você acaba com os commits legais que procurava e que, usando o SVN, você deve se abster de confirmar até executar as duas primeiras etapas, que é o que a maioria das outras respostas está sugerindo. IOW, você não deseja impor seu código não-escrito e não-escrito a outras pessoas, para não confirmar por uma semana até que seu recurso seja concluído. Você não está usando o controle de versão em todo o seu potencial.

Observe também que, entre as etapas 1 e 3, você pode fazer git pushalterações no seu próprio repositório particular de repo- sições no servidor para obter backups gratuitos se o disco rígido do laptop morrer.

Porque quando algum mantenedor pobre está caçando um bug e descobre que ele foi adicionado na rev. xyz, ele vai querer saber o que rev. xyz deveria fazer.

Você comenta seu código fonte, certo?

Você escreve os melhores comentários, aqueles que dizem por que, como o código diz apenas como ?

A mensagem de confirmação é um comentário e, portanto, é muito importante e quanto mais você pensa em corrigi-la, mais útil é para um futuro mantenedor do software.

Para qualquer software ativo, esse comentário específico será exibido em algo como

(encontrado em http://longair.net/blog/2009/04/25/a-few-git-tips/ ). Isso permite uma visão panorâmica de quem trabalhou no software quando e o que eles fizeram.

Observe que esse é o objetivo final do comentário de confirmação, ou seja, aparecer nessa lista dizendo "o que " para o seu futuro eu ou seu colega, e essa é a razão pela qual você deve tomar cuidado ao escrever boas mensagens de confirmação.

Se a mensagem de confirmação parecer estúpida para você, parece que você está usando confirmações incorretas.

As confirmações devem ser feitas por um bom motivo - devem estar relacionadas às tarefas que você detalhou para o recurso em que está trabalhando. Sejam essas tarefas formais ou apenas em sua mente, cada alteração que você confirmar deve concluir mais ou menos uma tarefa e, portanto, ser funcional de alguma forma.

Então, suas mensagens de confirmação têm um propósito muito melhor. Descreva a tarefa que você concluiu e, se não for rastreada em outro lugar, por que essa tarefa foi necessária ou para qual finalidade ela serve:

• Refatorou a classe de usuário para melhor encapsulamento
• Criou stubs de API para que as interfaces pudessem ser usadas na classe do controlador
• Convertida a classe de banco de dados em uma classe abstrata para que um banco de dados falso possa ser usado em casos de teste

Então você ou outros desenvolvedores podem navegar no histórico do repositório ou do arquivo e facilmente ver onde certas evoluções aconteceram e por quê. Ou, se uma revisão em particular for considerada culpada de um bug, a mensagem de confirmação fornecerá uma pista do motivo pelo qual essa linha foi inserida, para que você não apenas a retire e tente rebote algo que se pensava ser fixo, e você pode corrigi-lo da maneira certa.

Enviar comentários não resolve tudo. Sempre há uma chance de que eles possam enganar tanto quanto ajudam - especialmente quando os desenvolvedores estão com raiva de ter que entrar neles. Tente o seguinte: considere-os como uma trilha de migalhas de pão na floresta ou um waypoint de montanhismo ou balas de rastreamento. Quando bem, eles podem traçar um caminho confuso.

Não faça um grande negócio com eles. Seja honesto:

• "Editado entidades de índice espacial, Daos e UIs para lidar com o recurso X"
• "Check-in incremental para solicitação de recurso # 1234 e bug # 5678"
• "Eu quebrei a última versão. Esses são os arquivos que eu perdi."

Mantenha-o curto e "grande figura". Se possível, consulte um número de problema no seu sistema de recursos / erros. Algumas UIs de controle de versão incluem um campo para esse tipo de coisa.

Reduz o número de WTF / minuto;)

que se traduz em uma equipe mais feliz (que não te odeia) e uma melhor saída da equipe potencialmente a um custo menor

Portanto, o resto da sua equipe sabe que WTF você está fazendo o check-in das alterações na árvore do projeto.

porque se você não praticar a digitação de mensagens decentes, acabará como meu colega que entra em mensagens como

no changes

ou

testing

para confirmações com mais de cem arquivos alterados (sem brincadeira aqui !!).

Se você se tornar um desenvolvedor desse tipo, parecerá estúpido aos olhos do resto do mundo, por mais estúpido que você pense que é apenas inserir uma mensagem.

Por que você confirma se as alterações não são significativas?

Apenas confirme alterações que tenham um significado. Por exemplo, fiz uma refatoração bastante grande na outra semana, o que me levou cerca de 3 dias. Eu teria toneladas de confirmações durante esse tempo. Algumas foram pequenas mudanças ('renomeou a classe X para Y para refletir nova responsabilidade' ou 'mudou o método Z () para a classe Q') e outras foram realmente grandes. Quando termino um recurso / refatoração, verifico se alguns commits podem ser esmagados (pelo menos o git suporta isso, não conheço outras ferramentas), mas geralmente os deixo como estão, pois ajuda mais tarde.

Eu acho que você não cometeria no meio da edição de uma linha, por isso deve ter um significado. Apenas descreva o que você fez desde o último commit.

imagine uma condição quando você interrompeu seu sistema fazendo algumas alterações e perceba isso após vários commits por equipe. Você não lembra qual foi a alteração, mas lembra que algo pode dar errado quando aprimora o recurso X ou remove um arquivo do módulo Y.

Infelizmente, o número da revisão não informa quando você alterou X ou Y. Portanto, sua escolha é ler todos os códigos confirmados nos últimos N dias ou apenas ler mensagens de confirmação detalhadas que você escreveu (muito mais legível que o código).

Portanto, se você escrever o mesmo texto chato, inútil e não relacionado na mensagem de confirmação, porque você precisa, é mais prejudicial do que ter uma mensagem de confirmação. Porque, em vez de encontrar a raiz do erro, a mensagem errada irá desviá-lo.

Portanto, tente escrever mensagens de confirmação significativas toda vez que você confirmar, o que pode ajudar você e o mantenedor.

Se você está trabalhando com outras pessoas, as mensagens de confirmação são muito importantes para realmente ver o que outras pessoas fizeram: procurar as diferenças para cada uma delas é muito mais trabalhoso e você pode não entender por que alguém fez isso. Se você trabalha com outras pessoas e alguém (talvez não você) precise realmente olhar para trás, por exemplo, para rastrear como o comportamento mudou desde a versão anterior de maneiras inesperadas ... você está realmente dificultando a vida por não usar uma dica útil no commit mensagem.

Se você estiver trabalhando sozinho ... em um projeto que é principalmente codificado 'como está' (por exemplo, um único site ou script simples), posso ver mais ou menos de onde você é. Se eu trabalhar em algo assim, só me importo com a data / hora ou as alterações mais recentes ao continuar trabalhando em algo (você tem um ponto para restaurar, mas isso só importa durante o desenvolvimento, não depois de implementado). O controle de versão é apenas uma maneira de fazer backups com alguns pontos positivos - concordo plenamente que não está fazendo uso completo do sistema - mas em alguns projetos de pequena escala, isso pode não ser necessário.

O pensamento me ocorreu antes que o Controle de Versão estivesse sendo usado de duas formas diferentes, uma de documentar as mudanças no projeto e outra como uma ajuda aos desenvolvedores em vigor ... e esses dois são totalmente diferentes um do outro. As mensagens de confirmação são muito importantes, por um lado, e podem ser inúteis, por outro.

Está faltando alguma coisa. Não deve ser uma razão para realizar um commit caso contrário você não estaria fazendo isso.

Tudo o que você precisa fazer no comentário é colocar o motivo em palavras, mesmo que seja apenas wip: adding new state objects

Como muitos outros, faço um pouco de codificação no meu tempo livre e uso um sistema de controle de revisão para acompanhar meu desenvolvimento e alterações. A quantidade de tempo livre disponível varia muito de semana para semana e de mês para mês. Muitas foram as ocasiões em que eu não tenho tempo para codificar um projeto por semanas ou meses, e o tempo que eu normalmente variava de 10 minutos (dia típico) a 40 minutos (bom dia). Essas certamente não são ótimas condições - especialmente para problemas de depuração.

Era essencial manter anotações que não se perdessem e fossem facilmente recuperáveis. No final de cada sessão, o trabalho da sessão seria confirmado com uma mensagem detalhada. Eu poderia então percorrer o histórico de submissões e acompanhar meu progresso e processo de pensamento. Isso me permitiu retomar onde estava na semana passada ou no mês passado com a menor quantidade de tempo precioso perdido.

O ponto que estou tentando ilustrar é que boas mensagens de confirmação ajudam você (e qualquer outra pessoa que vem depois de você) a descobrir o que aconteceu, o que está acontecendo, para onde as coisas estão acontecendo e, acima de tudo, por quê.

Pense nisso logicamente por um minuto. Quando você está cometendo isso significa que algo foi feito. Se você não deixar mensagem, como as outras pessoas saberão o que foi feito?

Se você não comentar seus commits, poderá ficar tentado a comentar a alteração na fonte. Com o tempo, isso pode confundir a fonte.

As mensagens de confirmação são uma maneira rápida de saber o que está acontecendo nesse check-in e ajudará outros desenvolvedores da sua equipe quando eles quiserem saber qual aspecto do código foi alterado em quais revisões (por várias razões).

Em uma nota relacionada, sugiro especificar o número do caso do rastreador de erros (espero que você esteja usando um) na mensagem de confirmação, para que seja útil no futuro rastrear facilmente as coisas.

Para que o mantenedor desse código, um ano depois, saiba quem deve procurar esse código atroz. :)