Ссылка на номер проблемы на GitHub в сообщении фиксации

739

Можно ли как-то автоматически включить в git commitсообщение ссылку на номер выпуска GitHub ?

git github git-commit

Связанный: коммиты с перекрестными ссылками в github

— Didier L

954

Просто включите #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

Ознакомьтесь с документацией в разделе справки.

— NARKOZ
источник

4

Fix issue #xxxу меня не работает, есть идеи? Он ссылается на проблему, но не закрывает ее.

— Деннис

16

@Dennis убери слово «проблема»

1

@JamesTomasino это возможно - я заметил, что это не работает для меня, когда я работаю над веткой под названием dev.

— Джон Кернс

1

В каких ситуациях будет использоваться каждая из них?

— Нильси

1

Я не собираюсь быть человеком, который переместит этот ответ с 666 голосов до 667, но это было ОЧЕНЬ полезно.

— Jakeatwork

168

Если вы хотите сослаться на проблему GitHub и закрыть проблему, вы можете указать в своем сообщении Git commit следующие строки:

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

(Любой из трех будет работать.) Обратите внимание, что это будет связано с проблемой, а также закроет ее. Вы можете узнать больше в этом сообщении в блоге (начните смотреть встроенное видео в 1:40).

Я не уверен, что подобный синтаксис будет просто ссылаться на проблему, не закрывая ее.

— mipadi
источник

31

Вы можете просто использовать номер вопроса (например, # 456), который будет связан с задачей, не закрывая ее.

— Матье Наполи

9

Я бы выбрал «gh-1» вместо «# 1» просто потому, что вы никогда не знаете, будет ли хранилище экспортировано / отражено в другое место, кроме github. Тогда «# 1» не будет иметь большого смысла.

— huyz

2

@mipadi: необходим ли .после "Closes GH-1`? Кроме того,

— учитывает ли

1

@Lekensteyn: я не верю, что период необходим. Не уверен насчет чувствительности к регистру.

— Мипади

message (closes GH-28)работает для меня, не уверен, если все без учета регистра.

— Лекенштейн

64

Вы также можете делать перекрестные ссылки на репозитории:

githubuser/repository#xxx

ххх номер выпуска

— narkeeso
источник

62

github добавляет ссылку на коммит, если он содержит #issuenbr (обнаружил это случайно).

— Хенрик Линдберг
источник

4

только что проверил, работает как шарм, спасибо ... это тот, который должен быть помечен как правильный ответ ...

— открывается как

14

им приятно написать о новых выпусках 2.0 в своем блоге https://github.blog/2011-04-09-issues-2-0-the-next-generation/

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

исправления #xxx
фиксированный #xxx
исправить #xxx
закрывается #xxx
закрыть #xxx
закрыто #xxx

использование любого из ключевых слов в сообщении о коммите сделает ваш коммит либо упомянутым, либо закроет проблему.

— ксеро
источник

Это уже было в моем списке, я не думаю, что они чувствительны к регистру.

— xero

4

В дополнение к другим ответам: Если вы даже не хотите писать сообщение о фиксации с номером проблемы и случайно используете Eclipse для разработки, вы можете установить плагины eGit и Mylyn, а также разъем GitHub для Mylyn. Затем Eclipse может автоматически отслеживать, над какой проблемой вы работаете, и автоматически заполнять сообщение о коммите , включая номер проблемы, как показано во всех остальных ответах.

Для получения дополнительной информации об этой установке см. Http://wiki.eclipse.org/EGit/GitHub/UserGuide.

— Bananeweizen
источник

4

Чтобы связать номер проблемы с вашим сообщением о коммите, вы должны добавить: #issue_numberв вашем сообщении о коммите git.

Пример сообщения коммита от Udacity Руководство по стилю сообщения Git Commit

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

— Сухас Шриватс Суббуратхинам
источник

Не имеет смысла (и на самом деле меня раздражает), что они используют «feat» в качестве аббревиатуры для «функции», особенно когда в то же время они используют «рефакторинг», который даже длиннее, чем «функция».

— Мишель Юнг

@MichelJung Вы могли бы поспорить, что featиспользуется чаще, чем refactor, также нет явного сокращения для refactor( refможет означать ссылку, rfслишком непонятно, и т. Д.).

— Крис Крашевски

3

Одним из моих первых проектов в качестве программиста был гем под названием stagecoach, который (помимо прочего) позволял автоматически добавлять номер проблемы github к каждому сообщению коммита на ветке, что является частью вопроса, на который действительно не был дан ответ ,

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

Я бы не рекомендовал его для производственного использования, так как в то время я программировал только несколько месяцев и больше не поддерживаю его, но он может быть кому-то интересен.

— omnikron
источник

Я думаю, что ваш ответ пытается ответить на точный вопрос из OP, то есть «способ автоматически добавить ссылку на проблему, добавленную в коммите». Все остальные ответы полагаются на то, что программист не забудет добавить "Исправления # ..., Решенные # ... и т. Д." Фраза для коммита, и это не будет происходить каждый раз, как мы это знаем. Upvoting.

— demisx