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

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

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.

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.

También puede cruzar los repositorios de referencia:

githubuser/repository#xxx

xxx es el número de problema

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

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.

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

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

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.