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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

Этот аргумент работает, если вы имеете дело с действительно распределенным проектом. Если вы имеете дело с распределенным проектом, вы, вероятно, работаете над проектом с открытым исходным кодом. И это, вероятно, очень большой проект, если он действительно распространен. На самом деле это возможно либо ядро ​​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 символами. При этом нынешнее время в среднем, вероятно, будет на несколько символов короче.

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

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

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

Ответ 3

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

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

Renamed the iVars and removed the common prefix.

Есть один такой:

Rename the iVars to remove the common prefix

Что говорит кому-то, что будет делать применение фиксации, а не то, что ты сделал. Кроме того, если вы посмотрите на историю своего репозитория, вы увидите что генерируемые сообщения Git также записываются в это время - "Объединить" не "Слияние", "Ребаза", а не "Восстановленный", поэтому запись в том же напряженность держит вещи последовательными. Сначала это кажется странным, но имеют смысл (отзывы доступны по заявке) и в конечном итоге становится естественным.

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

Если, однако, вы решили пойти таким образом, затем git rebase -i с помощью вариант перебора будет хорошей вещью для изучения.

Ответ 4

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

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

Ответ 5

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

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

то есть. подытожить:

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

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

Я думаю, что вы можете использовать любой из времен. Я даже иногда использую Present Continuous Adding feature X.