コミットメッセージ内のGitHubの問題番号へのリンク


回答:


954

#xxxコミットメッセージに含めるだけで、問題を閉じずに参照できます。

新しいGitHub issue 2.0では、これらの同義語を使用して課題参照し、(コミットメッセージで)閉じることができます。

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

また、置き換えることができ#xxxgh-xxx

リポジトリ全体での問題の参照とクローズも機能します。

fixes user/repo#xxx

ヘルプセクションで利用可能なドキュメントをチェックしください。


4
Fix issue #xxx私にはうまくいきません、何かアイデアはありますか?それは問題を参照しますが、それを閉じません。
デニス

16
@Dennisが単語「issue」を削除

1
@JamesTomasino可能です-というブランチで作業しているときに、これが機能していないことに気づきましたdev
ジョンケアンズ2013年

1
それぞれをどのような状況で使用しますか?
nilsi 2013

1
私はこの答えを666票から667票に移動する人にはなりませんが、これは非常に役に立ちました。
jakeatwork

168

GitHubの問題にリンクして問題閉じる場合は、Gitコミットメッセージに次の行を含めることができます。

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

(3つのうちどれでも機能します。)これは問題にリンクし、それを閉じることにも注意してください。詳しくは、このブログ投稿をご覧ください(約1:40に埋め込まれたビデオの視聴を開始します)。

同様の構文が問題を閉じずに単純にリンクするかどうかはわかりません。


31
タスクを閉じることなくタスクにリンクする問題の番号(#456など)を使用できます。
Matthieu Napoli

9
リポジトリがgithub以外の場所にエクスポート/ミラーリングされているかどうかわからないという理由だけで、「#1」ではなく「gh-1」を選択します。その場合、「#1」はあまり意味がありません。
huyz

2
@mipadi:.「GH1を閉じる」の後は必要ですか?また、大文字と小文字は区別されますか?
Lekensteyn

1
@Lekensteyn:期間が必要だとは思いません。大文字と小文字の区別についてはわかりません。
mipadi

message (closes GH-28)すべてが大文字と小文字を区別しないかどうかはわかりません。
Lekensteyn 2012年

64

また、参照リポジトリを相互参照することもできます。

githubuser/repository#xxx

xxxは問題番号です


62

githubが#issuenbrを含む場合、コミットへの参照を追加します(これは偶然発見されました)。


4
テストしたばかりで、魅力のように動作します。ありがとう...これは正解としてマークする必要があるものです...
opensas

14

彼らは彼らのブログhttps://github.blog/2011-04-09-issues-2-0-the-next-generation/で新しい問題2.0についての良い記事を書いてい ます

同義語には

  • #xxxを修正
  • 修正済み#xxx
  • #xxxを修正
  • #xxxを閉じます
  • #xxxを閉じる
  • クローズ#xxx

コミットメッセージで任意のキーワードを使用すると、コミットが言及されるか、問題がクローズします。


それはすでに私のリストにありました、それらは大文字と小文字を区別するとは思いません。
xero

4

他の回答に加えて:問題番号を付けてコミットメッセージを書きたくなく、Eclipseを開発に使用したい場合は、eGitプラグインとMylynプラグイン、およびMylynのGitHubコネクターをインストールできます。Eclipseは、作業中の問題を自動的に追跡し、他のすべての回答に示されている問題番号を含めて、コミットメッセージ自動的に埋めます。

そのセットアップの詳細については、http: //wiki.eclipse.org/EGit/GitHub/UserGuideを参照してください


4

問題番号をコミットメッセージにリンクするに#issue_numberは、git commitメッセージに以下を追加する必要があり ます。

Udacity Gitコミットメッセージスタイルガイドからのコミットメッセージの例

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

リポジトリを参照することもできます。

githubuser/repository#issue_number

特に「feature」よりも長い「refactor」を同時に使用している場合は特に、「feature」を「feature」の略語として使用するのは意味がありません(実際には私を困らせます)。
ミシェルジョン

@MichelJung featrefactor、より頻繁に使用されると主張できます。また、明確な省略形はありませんrefactorref参照を意味する可能性rfがある、不明確すぎる、など)。
Chris Kraszewski

3

プログラマとしての私の最初のプロジェクトの一つと呼ばれる宝石だった駅馬車許可(とりわけ)という自動を本当に回答されていなかった問題の一部であるブランチ上の各コミットメッセージにgithubの発行数の追加します。

基本的に、ブランチを作成するときは、カスタムコマンド(などstagecoach -b <branch_name> -g <issue_number>)を使用し、ymlファイルでそのブランチに課題番号を割り当てます。次に、問題番号をコミットメッセージに自動的に追加するコミットフックがありました。

数か月しかプログラミングしておらず、もうメンテナンスしていないので、本番環境での使用はお勧めしませんが、誰かに興味があるかもしれません。


あなたの答えは、OPからの正確な質問、つまり「コミットに追加された問題へのリンクを自動的に設定する方法」に対処しようとしていると思います。他のすべての答えは、プログラマーが「修正#...、解決済み#...など」を追加することを覚えていることに依存しています。私たちが知っているように、これは毎回起こることはありません。賛成票。
demisx
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.