Você pode recomendar um bom modelo / diretrizes de mensagem de confirmação para aplicar na empresa? [fechadas]

No Git, é possível definir e aplicar um bom modelo de confirmação.

Você pode recomendar (de preferência com argumentação) um bom modelo / diretrizes de consolidação a serem aplicados na empresa?

eu uso

[Abc]: Message.

Com Add, Mod (ify), Ref (atuação), Fix, Rem (ove) e Rea (dability), fica fácil extrair o arquivo de log.

Exemplo:

Add: New function to rule the world.  
Mod: Add women factor in Domination.ruleTheWorld().  
Ref: Extract empathy stuff to an abstract class.  
Fix: RUL-42 or #42 Starvation need to be initialised before Energy to avoid the nullpointer in People.  
Rem: freeSpeech is not used anymore.  
Rea: Removed old TODO and extra space in header.  

Se eu tiver mais de uma linha, eu as classificarei com as mais importantes primeiro.

Usamos o seguinte:

[Identificação do ticket no JIRA]: [Mensagem: O que foi feito] Por exemplo - ABC-123: Adicionado capacidade de configurar a apresentação por região.

Nesse caso, com a integração adequada, você poderá obter arquivos alterados / excluídos / adicionados no seu rastreador de problemas. No entanto, esteja ciente de que você deve evitar algo como ABC-123: Concluído ou ABC-123: Corrigido com filtros, se possível.

Há uma regra simples, que é uma convenção seguida por muitos (se não todos) SCMs e pela maioria das ferramentas que funcionam com SCMs:

A primeira linha de uma mensagem de confirmação é um breve resumo, enquanto o restante da mensagem contém os detalhes.

Portanto, a maioria das ferramentas exibe apenas a primeira linha e exibe toda a mensagem sob demanda.

Um mau uso típico de uma mensagem de confirmação é uma lista de marcações de alterações (somente o primeiro marcador será mostrado). Outro uso indevido é escrever uma mensagem detalhada em uma única linha.

Portanto, se há uma coisa a ser aplicada, eu diria que é o comprimento máximo da primeira linha.

Pessoalmente, nunca vi um modelo de confirmação geral que valha a pena usar. O comentário deve dizer de forma concisa o que os commits estão relacionados, por exemplo, qual recurso / correção de bug ou uma breve declaração de por que as alterações foram feitas.

As informações sobre o que foi confirmado não devem ser incluídas, isso pode ser determinado pelo sistema scm. Mais informações sobre bugs / recursos pertencem a onde sempre os bugs e recursos são rastreados.

Ao atualizar um relatório de bug após uma confirmação, acho bom também declarar a revisão da confirmação junto com os comentários no relatório. Dessa maneira, você pode encontrar o caminho entre o comentário de confirmação e o relatório de erros, e para cada comentário no relatório de erros, você pode encontrar o que foi confirmado, mas você não duplica as informações no relatório de erros e na mensagem de confirmação.

Então, ao visualizar o histórico de revisões de um arquivo, você tem boas mensagens breves descrevendo o histórico, mas também sabe onde procurar mais detalhes sobre relatórios de erros ou descrições de tarefas para obter mais detalhes.

No Git, é possível aplicar quase tudo com os ganchos do Git . Verifique os exemplos em .git / hooks para obter idéias.

Quanto à mensagem, em um caso muito geral, você deseja incluir informações suficientes sobre o problema que estava resolvendo E a própria solução para poder encontrar e identificar esse commit posteriormente. Na maioria dos casos, o problema será referenciado como um número de bug (com integração adequada ao seu sistema de rastreamento de erros). Se você tiver outros sistemas com os quais seu processo se integra (como o sistema de rastreamento de revisão de código), inclua também os bits apropriados:

Extracted checking foobar range from bar() into foo(min, max) to re-use
in yadda() and blah(). foo() returns true if foobar is in the
specified range and false otherwise.

BugID: 123456
ReviewedBy: mabuddy
AutomergeTo: none

Mas você quer manter as coisas simples. Caso contrário, as pessoas encontrarão uma maneira de enganar o sistema e produzir mensagens de confirmação inúteis.

Usamos um modelo que contém

• O número de identificação do bug / recurso / correção
• Um sim / não descrevendo se o código foi testado ou não
• E uma seção de detalhes para uma breve descrição da intenção do commit

Os dois primeiros são omitidos na maioria das vezes (no entanto, ocasionalmente todos os três), então não é realmente um grande problema.

Geralmente, tenho o identificador que está no sistema de rastreamento de tickets que uso ou uma visão geral de alto nível como a primeira linha. Depois, tenho pontos de marcador da alteração específica no commit. Então eu poderia de algo como:

MyVideoGameProject-123 OR Inventory System Improvements
Made inventory GUI drap and drap
Added ability to have multiple bag slots to expand inventory capacity

Este é o formato de confirmação mais limpo que eu gosto. É direto e direto ao ponto. Outra razão pela qual faço dessa maneira é que, se eu quiser criar um log de alterações, eu poderia pegar todas as mensagens de confirmação e analisá-las em um log de alterações com muita facilidade.

Mensagem [ticketId] [ABC] [topicId] [WIP], em que:

• ticketId - identificação de um item no repositório de tarefas
• ABC - adicionar (recurso), corrigir (correção de bug), str (estrutura), dep (dependência) rem (incompatibilidade com versões anteriores / remover), rea (legibilidade), ref (refatoração)
• topicId - pode ser um seletor de tarefas para jenkins e / ou nome da filial e / ou nome do tópico para gerrit
• WIP - trabalho em andamento / ou não (ou seja, a integração contínua pode exigir isso)
• mensagem - detalhe da modificação

Exemplos:
[# 452567] [add] [menu_item] novo item - livro de visitas
[# 452363] [correção] [banner_top] [WIP] 1024x300 pode ser usado agora
[# 452363] [fix] [banner_top] 500x200 pode ser usado agora
[ # 452713] [rem] [página] anúncio do meio esquerdo