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


Respuestas:


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.


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.


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


62

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


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.


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


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

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.


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
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.