Enlace al número de problema en GitHub dentro de un mensaje de confirmación

739

¿De alguna manera es posible tener automáticamente un enlace al número de problema de GitHub en el git commitmensaje?

git github git-commit

— Mika tuupola
fuente

Relacionado: Compromisos de referencias cruzadas en github

— Didier L

954

Simplemente incluya #xxxen su mensaje de confirmación para hacer referencia a un problema sin cerrarlo.

Con los nuevos problemas 2.0 de GitHub, puede usar estos sinónimos para hacer referencia a un problema y cerrarlo (en su mensaje de confirmación):

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

También puedes sustituir #xxxcon gh-xxx.

Las referencias y los problemas de cierre en los repos también funcionan:

fixes user/repo#xxx

Consulte la documentación disponible en su sección de Ayuda.

— NARKOZ
fuente

44

Fix issue #xxxno funciona para mí, alguna idea? Hace referencia al problema, pero no lo cierra.

— Dennis

16

@Dennis elimina la palabra "problema"

1

@JamesTomasino eso es posible: me di cuenta de que esto no me ha funcionado cuando estoy trabajando en una sucursal llamada dev.

— Jon Cairns

1

¿En qué situaciones se utilizará cada uno?

— nilsi

1

No voy a ser la persona que mueva esta respuesta de 666 votos a 667, pero esto fue MUY útil.

— jakeatwork

168

Si desea vincular a un problema de GitHub y cerrar el problema, puede proporcionar las siguientes líneas en su mensaje de confirmación de Git:

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

(Cualquiera de los tres funcionará). Tenga en cuenta que esto vinculará el problema y también lo cerrará . Puede encontrar más información en esta publicación de blog (comience a ver el video incrustado aproximadamente a las 1:40).

No estoy seguro de si una sintaxis similar simplemente se vinculará a un problema sin cerrarlo.

— mipadi
fuente

31

Simplemente puede usar el número del problema (por ejemplo, # 456) que vinculará a la tarea sin cerrarla.

— Matthieu Napoli

99

Elegiría "gh-1" sobre "# 1" simplemente porque nunca se sabe si el repositorio se exporta / duplica a otro lugar que no sea github. Entonces, el "# 1" no tendrá mucho sentido.

— huyz

2

@mipadi: es el .después "se cierra GH-1` necesario también, que es entre mayúsculas y minúsculas??

— Lekensteyn

1

@Lekensteyn: No creo que el período sea necesario. No estoy seguro acerca de mayúsculas y minúsculas.

— mipadi

message (closes GH-28)funciona para mí, no estoy seguro si todo distingue entre mayúsculas y minúsculas.

— Lekensteyn el

64

También puede cruzar los repositorios de referencia:

githubuser/repository#xxx

xxx es el número de problema

— narkeeso
fuente

62

github agrega una referencia al commit si contiene #issuenbr (descubierto esto por casualidad).

— Henrik Lindberg
fuente

44

acabo de probarlo, funciona como un encanto, gracias ... este es el que debe marcarse como respuesta correcta ...

— abre el

14

tienen una buena redacción sobre los nuevos números 2.0 en su blog https://github.blog/2011-04-09-issues-2-0-the-next-generation/

los sinónimos incluyen

arreglos #xxx
fijo #xxx
arreglar #xxx
cierra #xxx
cerrar #xxx
cerrado #xxx

el uso de cualquiera de las palabras clave en un mensaje de confirmación hará que su confirmación sea mencionada o cierre un problema.

— xero
fuente

Eso ya estaba en mi lista, no creo que distingan entre mayúsculas y minúsculas.

— xero

4

Además de las otras respuestas: si ni siquiera desea escribir el mensaje de confirmación con el número de problema y utiliza Eclipse para el desarrollo, puede instalar los complementos eGit y Mylyn, así como el conector GitHub para Mylyn. Eclipse puede rastrear automáticamente en qué problema está trabajando y completar automáticamente el mensaje de confirmación , incluido el número de problema como se muestra en todas las otras respuestas.

Para obtener más detalles sobre esa configuración, consulte http://wiki.eclipse.org/EGit/GitHub/UserGuide

— Bananeweizen
fuente

4

Para vincular el número de problema a su mensaje de confirmación, debe agregar: #issue_numberen su mensaje de confirmación de git.

Ejemplo de confirmación de mensaje de Udacity Git Guía de estilo de confirmación de mensaje

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

También puede hacer referencia a los repositorios:

githubuser/repository#issue_number

— Suhas Srivats Subburathinam
fuente

No tiene sentido (y en realidad me molesta) que usen "feat" como abreviatura de "feature", especialmente cuando al mismo tiempo usan "refactor", que es incluso más largo que "feature".

— Michel Jung

@MichelJung podría argumentar que featse usa con más frecuencia que refactor, además, no hay una abreviatura obvia para refactor( refpodría significar referencia, no rfestá claro, etc.).

— Chris Kraszewski

3

Uno de mis primeros proyectos como programador fue una gema llamada diligencia que (entre otras cosas) permitió la adición automática de un número de problema de github a cada mensaje de confirmación en una rama, que es parte de la pregunta que realmente no ha sido respondida .

Esencialmente, al crear una rama, usaría un comando personalizado (algo así como stagecoach -b <branch_name> -g <issue_number>), y el número de problema se asignaría a esa rama en un archivo yml. Luego había un enlace de confirmación que agregaba el número de problema al mensaje de confirmación automáticamente.

No lo recomendaría para uso en producción ya que en ese momento solo había estado programando durante unos meses y ya no lo mantengo, pero puede ser de interés para alguien.

— omnikron
fuente

Creo que su respuesta está tratando de abordar la pregunta exacta del OP, es decir, "una forma de tener automáticamente un enlace al problema agregado en el commit". Todas las demás respuestas dependen de que el programador recuerde agregar "Correcciones # ..., Resolvió # ... etc." frase para el compromiso y esto no va a suceder cada vez que lo sabemos. Votación a favor.

— demisx