Sou um comunicador habitual e achei que combina comigo, mas é verdade que minhas mensagens de confirmação são quase sempre como,
Age: 9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.
Portanto, não posso dizer exatamente que fazer confirmações tão frequentes e habituais no meu ramo (mercurial) incentivou exatamente os logs de confirmação mais detalhados. Às vezes, eu até comprometo o código pela metade se, digamos, minha esposa me pede para sair para jantar; nesse momento, eu simplesmente copio e uso apressadamente a mensagem de confirmação "Trabalhando em" anterior.
Meus padrões de log de confirmação normalmente são como, "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"
Por outro lado, ele salvou minha bunda. Às vezes, encontro um caso delicado que não previ e testei, quando as confirmações frequentes me ajudam a descobrir exatamente onde introduzi o erro.
Portanto, eu não conheço os melhores hábitos e certamente não sou o único a ouvir os hábitos ideais de log de confirmação, mas certamente posso dizer que confirmar com mais frequência pode definitivamente ajudar quando você precisar executar uma regressão.
Cada alteração de uma linha deve ser confirmada?
Eu cometi alterações em uma linha antes, mas geralmente são complicadas e talvez eu tenha pouco tempo. Meus commits nem sempre se parecem com unidades perfeitas e completas de trabalho ou mudança. Como já foi dito, às vezes são apenas o resultado de minha esposa me pedir para sair para jantar inesperadamente.
TBH muitos dos meus commits que seguem esse "Working on [...]"padrão de log não estão modelando unidades coerentes de mudança (por que muitas vezes não consigo apresentar uma mensagem melhor que isso "Working on [...]"), mas apenas o resultado de eu respirar, como fazer uma xícara de café. A "Completed [...]"mensagem indica o fim dessa unidade de trabalho, e muitas vezes escrevo uma mensagem muito mais detalhada junto com as primeiras "Started working on [...]"mensagens de tipo quando começo a trabalhar em algo. Se você faz uma média de confirmações como uma vez a cada 15 minutos, as mensagens "Trabalhando [...] em" são mais intermediárias para o que alguém pode confirmar em uma confirmação mais massiva com uma mensagem mais detalhada.
Devo confirmar antes de qualquer teste (por exemplo, pelo menos para erros de sintaxe / compilação e, em seguida, preciso desfazê-lo totalmente; pois a ideia não funcionou ou a mensagem é uma mentira)?
Eu apenas vou em frente e cometo antes mesmo de executar testes algumas vezes (novamente se eu tiver um evento inesperado). Além disso, mesmo sendo solo, envio para um servidor (apenas um rodando aqui em casa em uma LAN) que faz CI. Pode parecer um exagero, mas não sei, eu me acostumei a me apoiar nisso nos meus locais de trabalho anteriores. Além disso, não quero me incomodar em ter que executar todos os meus testes de unidade e integração manualmente todas as vezes. Eu gosto de ter tudo isso ligado a apenas empurrar. Se um teste falhar, é fácil trabalhar de maneira progressiva, onde eu faço a regressão, corrijo o erro na última revisão e continuo. Dito isto, pelo menos construo o código contra uma compilação de depuração antes de confirmar.
Devo me certificar de me comprometer todas as manhãs / tardes antes de parar de trabalhar para o jantar enquanto ainda está fresco?
Eu gosto de me comprometer antes de sair e fazer uma pausa entre a programação. Eu realmente não pensei muito no porquê exatamente até encontrar essa pergunta. Suponho que é para me impedir de continuar de onde parei sem um log de confirmação no lugar de onde parei para que eu possa diferenciar e assim por diante. Hmm, eu preciso voltar para você, pois talvez não seja teoricamente necessário, dada a frequência com que eu me comprometo. Ainda me sinto mais confortável em fazer e empurrar antes de sair do computador por qualquer motivo. Parte disso pode ser o antigo medo psicológico de, digamos, o computador pegando fogo depois que eu saio e tendo os gerentes de projeto nos dias em que estávamos usando SVN com os desenvolvedores às vezes passando semanas sem comprometer a respiração de nossos pescoços e constantemente nos lembrando de verificar o código o mais rápido possível, lembrando-nos que nosso código é propriedade da empresa. Além disso, é um pouco mais eficiente, especialmente com o envio para que meu processo de IC possa começar a executar todos os testes enquanto estiver fora, para que eu possa voltar e ver os resultados.
Ah, e às vezes fico um pouco bêbado depois que saio e geralmente é uma má idéia tentar escrever código complexo enquanto bêbado (embora nem sempre; uma vez, eu criei um sistema de menu de contexto muito bom depois de ter um momento eureka enquanto estava bêbado, mas eu só tinha 6 cervejas e não era tão complexo de codificar). Se eu tentar fazer isso, pelo menos eu cometi o código sobriamente escrito antes de voltar a voltar para, em vez de misturar o código bêbado com o código sóbrio, quando o meu log de confirmação pode ser como, "Reverting back to code written before Jagermeister shots."não faço isso com muita frequência, a menos que eu tenha uma inspiração de código bêbado, mas nesses raros casos, realmente ajudou o fato de eu ter cometido algo antes de sair e ficar bêbado.