Link para o número do problema no GitHub em uma mensagem de confirmação

739

De alguma forma, é possível ter automaticamente um link para o número do problema do GitHub na git commitmensagem?

git github git-commit

— Mika Tuupola
fonte

Relacionado: Referências cruzadas confirmadas no github

— Didier L

954

Basta incluir #xxxna sua mensagem de confirmação para fazer referência a um problema sem fechá-lo.

Com os novos problemas do GitHub 2.0, você pode usar esses sinônimos para referenciar um problema e fechá- lo (na sua mensagem de confirmação):

fix #xxx
fixes #xxx
fixed #xxx
close #xxx
closes #xxx
closed #xxx
resolve #xxx
resolves #xxx
resolved #xxx

Você também pode substituir #xxxcom gh-xxx.

Referenciar e fechar problemas nos repositórios também funciona:

fixes user/repo#xxx

Confira a documentação disponível na seção de Ajuda.

— NARKOZ
fonte

4

Fix issue #xxxnão funciona para mim, alguma idéia? Ele faz referência ao problema, mas não o fecha.

— Dennis

16

@Dennis remove a palavra "issue"

1

@ JamesTomasino isso é possível - notei que isso não está funcionando para mim quando estou trabalhando em um ramo chamado dev.

— Jon Cairns

1

Em que situações cada uma deve ser usada?

— Nilsi

1

Eu não serei a pessoa que move essa resposta de 666 votos para 667, mas isso foi MUITO útil.

— jakeatwork

168

Se você deseja vincular a um problema do GitHub e encerrá-lo, pode fornecer as seguintes linhas na sua mensagem de confirmação do Git:

Closes #1.
Closes GH-1.
Closes gh-1.

(Qualquer um dos três funcionará.) Observe que isso vincula o problema e também o fecha . Você pode descobrir mais nesta postagem do blog (comece a assistir o vídeo incorporado aproximadamente às 1:40).

Não tenho certeza se uma sintaxe semelhante simplesmente vinculará a um problema sem fechá-lo.

— mipadi
fonte

31

Você pode simplesmente usar o número do problema (por exemplo, nº 456) que será vinculado à tarefa sem fechá-lo.

— Matthieu Napoli

9

Eu escolheria "gh-1" em vez de "# 1" simplesmente porque você nunca sabe se o repositório é exportado / espelhado para outro lugar que não o github. Então, o "# 1" não fará muito sentido.

— huyz

2

@mipadi: é necessário o .seguinte "Fecha o GH-1`? Além disso, faz

— distinção entre

1

@Lekensteyn: Não acredito que o período seja necessário. Não tenho certeza sobre a distinção entre maiúsculas e minúsculas.

— Mipadi

message (closes GH-28)funciona para mim, não tenho certeza se tudo faz distinção entre maiúsculas e minúsculas.

— precisa saber é o seguinte

64

Você também pode cruzar repositórios de referência:

githubuser/repository#xxx

xxx sendo o número da edição

— narkeeso
fonte

62

O github adiciona uma referência ao commit se ele contém #issuenbr (descoberto por acaso).

— Henrik Lindberg
fonte

4

apenas testado, funciona como um encanto, graças ... este é o único que deve ser marcado como resposta correta ...

— opensas

14

eles escrevem bem sobre as novas edições 2.0 em seu blog https://github.blog/2011-04-09-issues-2-0-the-next-generation/

sinônimos incluem

correções #xxx
Fixed #xxx
fix #xxx
fecha #xxx
fechar #xxx
fechado #xxx

o uso de qualquer uma das palavras-chave em uma mensagem de confirmação fará com que o seu commit seja mencionado ou encerre um problema.

— xero
fonte

Isso já estava na minha lista, acho que eles não diferenciam maiúsculas de minúsculas.

— Xero

4

Além das outras respostas: se você não deseja nem mesmo escrever a mensagem de confirmação com o número do problema e usar o Eclipse para desenvolvimento, pode instalar os plugins eGit e Mylyn, bem como o conector GitHub para Mylyn. O Eclipse pode rastrear automaticamente em qual problema você está trabalhando e preencher automaticamente a mensagem de confirmação , incluindo o número do problema, conforme mostrado em todas as outras respostas.

Para mais detalhes sobre essa configuração, consulte http://wiki.eclipse.org/EGit/GitHub/UserGuide

— Bananeweizen
fonte

4

Para vincular o número do problema à sua mensagem de confirmação, você deve adicionar: #issue_number na sua mensagem de confirmação do git.

Exemplo de mensagem de confirmação do Udacity Git Guia de estilo de mensagem de confirmação

feat: Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequenses of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

Você também pode fazer referência aos repositórios:

githubuser/repository#issue_number

— Suhas Srivats Subburathinam
fonte

Não faz sentido (e realmente me irrita) que eles usem "talento" como uma abreviação de "recurso", especialmente quando, ao mesmo tempo, usam "refatorar", que é ainda mais longo que "recurso".

— Michel Jung

@MichelJung, você poderia argumentar que featé usado com mais frequência do que refactortambém não há abreviação óbvia para refactor( refpode significar referência, rfé muito claro etc.).

— Chris Kraszewski

3

Um dos meus primeiros projetos como programador foi uma jóia chamada diligência que (entre outras coisas) permitiu a adição automática de um número de problema do github a todas as mensagens de confirmação em um ramo, o que é parte da pergunta que realmente não foi respondida. .

Essencialmente, ao criar uma ramificação, você usaria um comando personalizado (algo como stagecoach -b <branch_name> -g <issue_number>), e o número do problema seria atribuído a essa ramificação em um arquivo yml. Havia um gancho de confirmação que anexava o número do problema à mensagem de confirmação automaticamente.

Eu não o recomendaria para uso em produção, pois na época eu só programava por alguns meses e não o mantenho mais, mas pode ser do interesse de alguém.

— omnikron
fonte

Acho que sua resposta está tentando resolver a pergunta exata do OP, ou seja, "uma maneira de automaticamente ter um link para o problema adicionado no commit". Todas as outras respostas dependem do programador lembrando-se de adicionar "Correções # ..., Resolvido # ... etc." frase para o commit e isso não vai acontecer sempre que o conhecemos. Voto a favor.

— precisa saber é o seguinte