Посилання на номер проблеми в GitHub в повідомленні про фіксацію

Чи можливо автоматично мати посилання на номер випуску GitHub в повідомленні git commit ?

607
06 нояб. заданий Mika Tuupola 06 нояб. 2009-11-06 15:27 '09 о 15:27 2009-11-06 15:27
@ 8 відповідей

Просто включите #xxx в повідомлення фіксації, щоб посилатися на проблему, не закриваючи її.

З новим GitHub видає 2.0 ви можете використовувати ці синоніми в посилання на видати і закрити його (в повідомленні про фіксацію):

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

Ви також можете замінити #xxx на gh-xxx .

Реферування та проблеми закриття в репозиторіях також працюють:

 fixes user/repo#xxx 

Перегляньте документацію , доступну в розділі довідки.

752
19 июля '11 в 8:36 2011-07-19 08:36 відповідь дан NARKOZ 19 липня '11 о 8:36 2011-07-19 8:36

Якщо ви хочете встановити зв'язок з проблемою GitHub і закрити проблему, ви можете вказати наступні рядки в повідомленні Git commit:

 Closes #1. Closes GH-1. Closes gh-1. 
border=0

(Будь-який з трьох буде працювати.) Зверніть увагу, що це зв'яжеться з проблемою і закриє її. Ви можете дізнатися більше в цьому повідомленні в блозі (почніть перегляд вбудованого відео приблизно о 1:40).

Я не впевнений, що подібний синтаксис буде просто посилатися на проблему, не закриваючи її.

157
06 нояб. відповідь дан mipadi 06 нояб. 2009-11-06 22:12 '09 о 22:12 2009-11-06 22:12

Ви також можете перехресно посилатися на репозиції:

 githubuser/repository#xxx 

xxx - номер проблеми

56
11 окт. відповідь дан narkeeso 11 Жовтня. 2012-10-11 02:38 '12 о 2:38 2012-10-11 2:38

github додає посилання на фіксацію, якщо вона містить #issuenbr (це випадково виявлено).

47
14 апр. відповідь дан Henrik Lindberg 14 Квітня. 2011-04-14 04:32 '11 о 4:32 2011-04-14 4:32

у них хороша запис про нові проблеми 2.0 в їх блозі https://github.com/blog/831-issues-2-0-the-next-generation

синоніми включають

  • виправлення #xxx
  • виправлено #xxx
  • fix #xxx
  • закриває #xxx
  • закрити #xxx
  • закрито #xxx

використовуючи будь-який з ключових слів в повідомленні фіксації, ви зробите фіксацію або згаданої, або закриєте проблему.

11
21 дек. відповідь дан xero 21 дек. 2012-12-21 00:01 '12 в 0:01 2012-12-21 00:01

Як доповнення до інших відповідей: якщо ви навіть не хочете писати повідомлення фіксації з номером проблеми і використовувати для розробки Eclipse, то ви можете встановити eGit і Mylyn плагіни, а також роз'єм GitHub для Mylyn. Eclipse може автоматично відстежувати, на яку проблему ви працюєте, і автоматично заповнювати повідомлення фіксації, включаючи номер проблеми, як показано в усіх інших відповідях.

Детальніше про цю установці см. Http://wiki.eclipse.org/EGit/GitHub/UserGuide

4
26 дек. відповідь дан Bananeweizen 26 дек. 2011-12-26 11:24 '12 о 11:24 2011-12-26 11:24

Одним з моїх перших проектів в якості програміста був коштовний камінь, званий stagecoach , який (серед іншого) дозволяв автоматичне додавання github номер випуску для кожного повідомлення фіксації на гілці, яка є частиною питання, на який насправді не було дано відповіді.

По суті при створенні гілки ви використовуєте для користувача команду (щось на зразок stagecoach -b <branch_name> -g <issue_number> ), а номер проблеми буде призначений цій гілці в yml файлі. Потім був фіксація фіксації , яка автоматично додала номер проблеми в повідомлення фіксації.

Я б не рекомендував його для використання на виробництві, як в той час, коли я тільки програмував протягом декількох місяців, і я більше не підтримую його, але це може бути цікаво комусь.

3
22 апр. відповідь дан omnikron 22 Квітня. 2013-04-22 14:38 '13 о 14:38 2013-04-22 14:38

Щоб зв'язати номер проблеми з повідомленням про фіксацію, ви повинні додати: #issue_number в повідомленні git commit.

Приклад Commit Message з 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 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 the text as the body 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 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 is critical 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 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 two together 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 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 of this 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 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 the bullet 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 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 
1
19 окт. відповідь дан Suhas Srivats Subburathinam 19 Жовтня. 2016-10-19 21:47 '16 о 21:47 2016-10-19 21:47

Інші питання по мітках або Задайте питання