Question Lien vers le numéro de problème sur GitHub dans un message de validation


Est-il en quelque sorte possible de automatiquement avoir un lien vers le numéro de problème GitHub dans le git commit message?


646
2017-11-06 12:27


origine


Réponses:


Juste inclure #xxx dans votre message de validation pour référencer un problème sans le fermer.

Avec de nouvelles Problèmes GitHub 2.0 vous pouvez utiliser ces synonymes pour référencer un problème et fermer il (dans votre message de validation):

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

Vous pouvez également substituer #xxx avec gh-xxx.

Référencement et les problèmes de clôture à travers les repos fonctionne aussi:

fixes user/repo#xxx

Check-out La documentation disponible dans leur section d'aide.


809
2017-07-19 05:36



Si vous souhaitez créer un lien vers un problème GitHub et fermez le problème, vous pouvez fournir les lignes suivantes dans votre message de validation Git:

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

(L'un des trois fonctionnera.) Notez que cela sera lié à la question et aussi Fermer il. Vous pouvez en savoir plus dans ce article de blog (commencez à regarder la vidéo intégrée à environ 1:40).

Je ne suis pas sûr si une syntaxe similaire va simplement lier à un problème sans le fermer.


160
2017-11-06 19:12



Vous pouvez également faire des recoupements de référence:

githubuser/repository#xxx

xxx étant le numéro de problème


60
2017-10-10 23:38



github ajoute une référence au commit s'il contient #issuenbr (découvert par hasard).


52
2018-04-14 01:32



ils ont un bon article sur les nouveaux problèmes 2.0 sur leur blog https://github.com/blog/831-issues-2-0-the-next-generation

les synonymes comprennent

  • corrige #xxx
  • #xxx fixe
  • réparer #xxx
  • ferme #xxx
  • fermer #xxx
  • #xxx fermé

l'utilisation de l'un des mots-clés dans un message de validation rendra votre commit mentionné ou fermera un problème.


11
2017-12-20 21:01



Juste comme addition aux autres réponses: Si vous ne voulez même pas écrire le message de commit avec le numéro de problème et arriver à utiliser Éclipse Pour le développement, vous pouvez installer les plugins eGit et Mylyn ainsi que le connecteur GitHub pour Mylyn. Eclipse peut ensuite suivre automatiquement le problème sur lequel vous travaillez et remplir automatiquement le message de validation, y compris le numéro d'émission comme indiqué dans toutes les autres réponses.

Pour plus de détails sur cette configuration, voir http://wiki.eclipse.org/EGit/GitHub/UserGuide


4
2017-12-26 08:24



Un de mes premiers projets en tant que programmeur était un bijou appelé diligence que (entre autres choses) a permis automatique ajout d'un numéro de problème github à chaque message de commit sur une branche, ce qui fait partie de la question qui n'a pas vraiment reçu de réponse.

Essentiellement, lorsque vous créez une branche, vous utilisez une commande personnalisée (quelque chose comme stagecoach -b <branch_name> -g <issue_number>), et le numéro d'émission serait alors assigné à cette branche dans un fichier yml. Il y avait alors un commettre un crochet qui a ajouté le numéro de problème au message de validation automatiquement.

Je ne le recommanderais pas pour la production, car je n'avais programmé que depuis quelques mois et je ne le maintiens plus, mais cela pourrait intéresser quelqu'un.


3
2018-04-22 11:38



Pour lier le numéro de problème à votre message de validation, vous devez ajouter: #issue_number dans votre message de commit git.

Exemple de message de validation de  Udacity Git Commit Message Guide de style 

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

Vous pouvez également référencer les référentiels:

githubuser/repository#issue_number

1
2017-10-19 18:47