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

37

No Git, é possível definir e aplicar um bom modelo de commit.

Você pode recomendar (de preferência com argumentação) um bom modelo de compromisso / diretrizes para impor na empresa?

    
por kyrisu 01.02.2011 / 12:10
fonte

8 respostas

40

eu uso

[Abc]: Message.

Com Add, Mod (ify), Ref (ativação), Fix, Rem (ove) e Rea (dability), é fácil extrair logfile.

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, classifico-as com o mais importante primeiro.

    
por 06.10.2011 / 11:19
fonte
14

Nós usamos o seguinte:

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

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

    
por 01.02.2011 / 13:52
fonte
11

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

The first line of a commit message is a short summary, while the rest of the message contains the details.

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

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

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

    
por 06.10.2011 / 14:23
fonte
9

Pessoalmente, eu nunca vi um modelo geral de commits valendo a pena. O comentário deve dizer de forma concisa o que os commits estão relacionados a, e. qual característica / correção de bug ou uma breve declaração de porque as alterações foram feitas.

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

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

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 bugs ou descrições de tarefas para obter mais detalhes.

    
por 01.02.2011 / 13:05
fonte
4

No Git, é possível impor quase qualquer coisa com Git hooks . Verifique os exemplos em .git / hooks para ideias.

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 localizar e identificar esse commit mais tarde. Na maioria dos casos, o problema será referenciado a um número de bug (com integração adequada ao seu sistema de rastreamento de bugs). Se você tiver outros sistemas com os quais seu processo se integra (como o sistema de rastreamento de revisão de código), inclua os bits apropriados também:

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 commit inúteis.

    
por 01.02.2011 / 16:42
fonte
0

Nós usamos um modelo contendo

  • 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 a maior parte do tempo, no entanto (ocasionalmente, todos os três) por isso não é realmente um grande negócio.

    
por 01.02.2011 / 13:31
fonte
0

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. Então, eu tenho pontos "bullet" de item de linha 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 commit mais limpo que eu gosto. É direto e direto ao ponto. Outra razão pela qual eu faço desta forma é que se eu quiser criar um log de mudanças, eu poderia simplesmente pegar todas as mensagens de commit e analisá-las em um log de mudanças com muita facilidade.

    
por 06.10.2011 / 15:56
fonte
0

[ticketId] [ABC] [topicId] [WIP] Mensagem, onde:

  • ticketId - id de um item no repositório de tarefas
  • ABC - adicionar (recurso), correção (bugfix), str (estrutura), dep (dependência) rem (incompatibilidade / remoção de retrocesso), rea (legibilidade), ref (refatoração)
  • topicId - pode ser um seletor de trabalho para jenkins e / ou nome de ramificação e / ou nome de tópico para gerrit
  • WIP - trabalho em andamento / ou não (isto é, Integração Contínua pode exigir isso)
  • mensagem - detalhe da modificação

Exemplos:
[# 452567] [add] [menu_item] novo item - livro de visitas
[# 452363] [corrigir] [banner_top] [WIP] 1024x300 pode ser usado agora
[# 452363] [fix] [banner_top] 500x200 pode ser usado agora
[# 452713] [rem] [page] deixou o anúncio do meio

    
por 03.07.2013 / 00:04
fonte