Должен ли я использовать прошедшее или настоящее время в сообщениях git commit? [закрыто]


531

Однажды я прочитал, что сообщения git commit должны быть в настоящем времени, например, «Добавить тесты для x». Я всегда использую прошедшее время, например «Добавленные тесты для x», что кажется мне более естественным.

Вот недавний коммит Джона Резига, показывающий два в одном сообщении:

Настроить еще несколько результатов набора jQuery в тестах манипуляции. Также исправлен порядок ожидаемых результатов испытаний.

Это имеет значение? Какой я должен использовать?


12
Этот вопрос необходимо закрыть как основанный на мнении . Просто посмотрите на различия во взглядах между императивом и прошедшим временем ! При этом я голосую за императивное время, потому что оно действительно помогает уточнить, что вы делаете, когда переписываете свою историю, собираете вишню, применяете патчи и т. Д.!

Похожий вопрос: stackoverflow.com/questions/1753808/...
WIP



3
@Eonil, если он закрыт за то, что он основан на мнении, он будет закрыт за то, что он тоже основан на мнении.
фрик с трещоткой

Ответы:


601

Предпочтение для сообщений о фиксации настоящего времени в императивном стиле исходит от самого Git. Из Документации / SubmittingPatches в репозитории Git:

Опишите ваши изменения в императивном настроении, например «make xyzzy do frotz» вместо «[Этот патч] заставляет xyzzy do frotz» или «[I] поменял xyzzy на frotz», как если бы вы отдавали приказы кодовой базе изменить его поведение.

Таким образом, вы увидите много сообщений Git commit, написанных в этом стиле. Если вы работаете в команде или над программным обеспечением с открытым исходным кодом, будет полезно, если все будут придерживаться этого стиля для согласованности. Даже если вы работаете над частным проектом, и вы единственный, кто когда-либо будет видеть вашу историю git, полезно использовать императивное настроение, потому что оно формирует хорошие привычки, которые будут цениться, когда вы работаете с другими.


90
Я думаю, что это отличный выбор. Подумайте о том, что такое коммит в форме сравнения: набор инструкций о том, как перейти из предыдущего состояния в новое состояние. Так же, как diff говорит: «добавьте эту строку сюда, удалите эту строку здесь», сообщение фиксации говорит в качественном выражении «внести это изменение». (Да, git хранит коммит просто как дерево с метаданными, но для человека важной частью коммита является diff.)
Cascabel

124
Вы можете увидеть коммит как набор инструкций о том, как перейти из предыдущего состояния в новое; но я вижу это скорее как контрольный пункт в эволюции кода. Для меня сообщение о коммите - это журнал того, что было сделано с кодом со времени предыдущего коммита; и для журнала прошедшее время имеет намного больше смысла. Если вы действительно думаете, что сообщение коммита должно быть набором инструкций, тогда императивное время - путь. Я просто действительно не думаю об этом таким образом.
Карадок

10
@oschrenk: в более поздних версиях файла указана причина: «Опишите ваши изменения в императивном настроении, например« make xyzzy do frotz »вместо« [Этот патч] заставляет xyzzy do frotz »или« [I] изменил xyzzy для выполнения frotz » ', как будто вы даете распоряжение кодовой базе изменить его поведение. "
Мипади

44
Сообщение коммита должно быть обязательным, в настоящем времени, потому что с git вы или кто-то еще можете в конечном итоге сделать rebaseили, cherry-pickи в этом случае, коммит может быть использован вне его первоначального контекста. В результате сообщение о фиксации должно быть написано автономно, не ожидая, что читатель увидит какие-либо окружающие сообщения фиксации. Когда вы выбираете патчи для вишни, имеет смысл применить «Исправить алгоритм быстрой сортировки» или «Сортировка: повысить производительность» вместо «Исправленная ошибка № 124» или «Измененная сортировка для повышения производительности».
Микко Ранталайнен

5
Я думаю об этом так: в сообщении должно быть указано, что изменится, если я решу применить этот коммит к моей ветке. Я не думаю о нем как о журнале, а о том, что я могу перейти и мне нужно знать, что произойдет, когда я выберу определенное состояние.
Steinybot

357

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

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

  • Письмо в настоящем времени говорит кому- то, что будет делать применение коммита , а не то, что вы делали.

Это самая правильная причина, по которой можно использовать настоящее время, но только с правильным стилем проекта. При таком способе мышления все коммиты рассматриваются как необязательные улучшения или функции, и вы можете сами выбирать, какие коммиты сохранять, а какие отклонять в вашем конкретном репозитории.

Этот аргумент работает, если вы имеете дело с действительно распределенным проектом. Если вы имеете дело с распределенным проектом, вы, вероятно, работаете над проектом с открытым исходным кодом. И это, вероятно, очень большой проект, если он действительно распространяется. На самом деле, это, вероятно, ядро ​​Linux или Git. Поскольку Linux, вероятно, стал причиной распространения и роста популярности Git, легко понять, почему люди считают его стиль авторитетом. Да, стиль имеет смысл с этими двумя проектами. Или вообще работает с большими, с открытым исходным кодом, распределенными проектами.

При этом большинство проектов в системе контроля версий не работают так. Обычно это неверно для большинства репозиториев. Это современный подход к коммитам: репозитории Subversion (SVN) и CVS едва ли поддерживают этот стиль регистрации репозитория. Обычно ветвь интеграции обрабатывает фильтрацию неудачных заездов, но обычно они не считаются «необязательными» или «полезными функциями».

В большинстве сценариев, когда вы делаете коммиты в исходном репозитории, вы пишете запись в журнале, которая описывает, что изменилось с этим обновлением, чтобы другим было проще в будущем понять, почему было сделано изменение. Как правило, это необязательное изменение - другие люди в проекте должны либо слить, либо перебазировать его. Вы не пишете запись в дневнике , такие как «Дорогой дневник, сегодня я встретиться с мальчиком , и он говорит мне привет.», Но вместо того, чтобы писать «Я встретил мальчика , и он сказал мне привет.»

Наконец, для таких нераспределенных проектов 99,99% времени, когда человек будет читать сообщение коммита, предназначено для чтения истории - история читается в прошедшем времени. В 0,01% случаев будет решаться, следует ли им применять этот коммит или интегрировать его в свой филиал / репозиторий.

  • Согласованность. Так обстоит дело во многих проектах (включая сам git). Также это делают инструменты git, которые генерируют коммиты (например, git merge или git revert).

Нет, я гарантирую вам, что большинство проектов, когда-либо зарегистрированных в системе управления версиями, имели свою историю в прошедшем времени (у меня нет ссылок, но это, вероятно, правильно, учитывая, что аргумент настоящего времени является новым со времен Git). Сообщения «ревизии» или сообщения о фиксации в настоящем времени стали понятны только в действительно распределенных проектах - см. Первый пункт выше.

  • Люди не только читают историю, чтобы узнать «что случилось с этой кодовой базой», но и отвечают на вопросы типа «что происходит, когда я выбираю этот коммит» или «какие новые вещи будут происходить с моей кодовой базой из-за этих коммитов» Я могу или не могу слиться в будущем ".

Смотрите первый пункт. 99,99% времени, когда человек будет читать сообщение коммита, предназначено для чтения истории - история читается в прошедшем времени. В 0,01% случаев будет решаться, следует ли им применять этот коммит или интегрировать его в свой филиал / репозиторий. 99,99% бьет 0,01%.

  • Обычно короче

Я никогда не видел хороший аргумент, который говорит использовать неправильное время / грамматику, потому что это короче. Вы, вероятно, в среднем сохраните только 3 символа для стандартного 50-символьного сообщения. При этом нынешнее время в среднем, вероятно, будет на несколько символов короче.

  • Вы можете назначать коммиты более согласованно с названиями заявок в вашем трекере проблем / функций (которые не используют прошедшее время, хотя иногда и будущее)

Билеты пишутся либо как что-то, что происходит в данный момент (например, приложение показывает неправильное поведение при нажатии этой кнопки), либо как что-то, что необходимо сделать в будущем (например, текст будет нуждаться в редакторе).

История (т.е. сообщения коммита) записывается как то, что было сделано в прошлом (например, проблема была исправлена).


79
Я впервые услышал сегодня о предполагаемом предпочтении обязательных стилей. Для меня это звучало настолько неестественно и странно, что я решил поискать еще несколько мнений. Я рад видеть, что я не единственный, кто думает, что прошедшее время более естественно для коммитов. :)
Карадок

57
Автоматически сгенерированные git сообщения о слиянии и перебазировании являются обязательными и имеют текущее время («Слияние», а не «Слияние»; «Перебазирование», а не «Перебазирование»), так что вы можете захотеть сопоставить это в ваших собственных сообщениях о коммитах для согласованности.
MJS

13
Кажется, что разница заключается в фокусировке на изменении в программном обеспечении - «Фиксированный X с помощью Y» - или в репозитории - «Делаем Y, чтобы исправить X». +1 для хорошего аргумента, но я думаю, что репо, как правило, должно сосредоточиться на себе, а не на конечном программном обеспечении.
10

28
Дело в том, что при использовании императивов настоящее время работает для огромных проектов (например, Linux), поэтому оно явно масштабируется. Кроме того, он требует почти нулевого усилия, используя прошедшее время. В результате я не вижу причин (кроме «старые люди используют для написания сообщений коммита в прошедшем времени») использовать что-либо еще, кроме императивного настоящего времени. Если вы можете выучить набор команд git, вы можете научиться писать в настоящем времени.
Микко Ранталайнен

35
Императив не "новый, так как мерзавец". ChangeLog существовал задолго до git, и использование императива всегда было рекомендуемым стилем в проекте GNU. gnu.org/prep/standards/html_node/Style-of-Change-Logs.html
adl

81

Я написал более полное описание на 365git .

Использование императива, настоящего времени - это то, к чему нужно немного привыкнуть. Когда я начал это упоминать, это встретило сопротивление. Обычно по принципу «Сообщение коммита записывает, что я сделал». Но Git - это распределенная система контроля версий, в которой есть много мест, где можно получить изменения. Вместо того, чтобы писать сообщения, которые говорят, что вы сделали; рассмотрите эти сообщения как инструкции для того, что будет делать применение коммита. Вместо того, чтобы иметь коммит с названием:

Renamed the iVars and removed the common prefix.

Иметь такой:

Rename the iVars to remove the common prefix

Что говорит кому-то, что будет делать применение коммита, а не то, что вы сделали. Кроме того, если вы посмотрите на историю своего репозитория, то увидите, что сгенерированные Git сообщения также пишутся в этом времени - «Объединить», а не «Объединить», «Перебазировать», а не «Перебазировать», поэтому запись в том же времени сохраняет согласованность. Поначалу это кажется странным, но оно имеет смысл (отзывы доступны по заявке) и в конце концов становится естественным.

Сказав все это - это ваш код, ваш репозиторий: так что установите свои собственные рекомендации и придерживайтесь их.

Однако, если вы решите пойти по этому пути, то git rebase -iс опцией reword было бы неплохо разобраться.


7
Итак, вы перепутали два разных принципа: проект с открытым исходным кодом Git и регулярное использование Git. Приведенная ссылка не упоминает время вообще . Официальный Git Doc упоминает только ограничение в 50 символов. Git - это распределенная VCS, в которой есть много мест, где можно получить изменения ... рассматривайте эти сообщения как инструкции к тому, что будет делать применение коммита. Это относится только к нескольким проектам, которые фактически являются распределенными проектами. 99,999% коммитов Git никогда не будут применены таким образом вручную. В большинстве проектов история представляет собой журнал изменений, который должен быть в прошедшем времени.
Мэтт Куигли

4
«и должен пропустить полную остановку»
принимает

30

Придерживайтесь императива настоящего времени, потому что

  • хорошо иметь стандарт
  • он соответствует тикетам в трекере ошибок, которые, естественно, имеют форму «реализовать что-то», «исправить что-то» или «проверить что-то».

16

Для кого вы пишете сообщение? И этот читатель обычно читает сообщение до или после владения самим коммитом?

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

т.е. подвести итог:

  • Является ли сообщение преимущественно для других людей, обычно читающих в какой-то момент до того, как они предполагают изменение: предложение того, что принятие изменения сделает с существующим кодом.

  • Является ли сообщение преимущественно журналом / записью для вас (или для вашей команды), но обычно читается с точки зрения принятия изменений и поиска, чтобы узнать, что произошло.

Возможно, это приведет к мотивации вашей команды / проекта, в любом случае.


10

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


27
Для некоторых людей подобные вещи имеют большое значение.
Уэсли Мёрч

2
@mog ссылка не делает никаких заявлений о настоящем и прошлом.
празднование

2
Если проект действительно масштабируется, люди, занимающиеся анализом кода и поиском ошибок, увидят так много коммитов, что им понадобится вся помощь, которую вы и я можем предоставить. Сейчас нет смысла экономить пару секунд, чтобы в будущем вызвать сильную головную боль из-за неправильного написания сообщения о коммите.
Микко Ранталайнен

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

1
Откуда вы знаете, что человек, неспособный интерпретировать ваше сообщение о коммите, является причиной того, что этот человек недостаточно способен или вы недостаточно способны написать хорошее сообщение о коммите?
Харис

7

Это тебе решать. Просто используйте сообщение о коммите, как хотите. Но это проще, если вы не переключаетесь между временем и языками.

И если вы развиваетесь в команде - это следует обсудить и установить исправлено.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.