Ваш проект должен почти всегда использовать прошедшее время . В любом случае, проект должен всегда использовать одно и то же время для последовательности и ясности.
Я понимаю некоторые другие аргументы в пользу использования настоящего времени, но они обычно не применяются. Следующие пункты являются общими аргументами для написания настоящего времени и моего ответа.
- Письмо в настоящем времени говорит кому- то, что будет делать применение коммита , а не то, что вы делали.
Это самая правильная причина, по которой можно использовать настоящее время, но только с правильным стилем проекта. При таком способе мышления все коммиты рассматриваются как необязательные улучшения или функции, и вы можете сами выбирать, какие коммиты сохранять, а какие отклонять в вашем конкретном репозитории.
Этот аргумент работает, если вы имеете дело с действительно распределенным проектом. Если вы имеете дело с распределенным проектом, вы, вероятно, работаете над проектом с открытым исходным кодом. И это, вероятно, очень большой проект, если он действительно распространяется. На самом деле, это, вероятно, ядро 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-символьного сообщения. При этом нынешнее время в среднем, вероятно, будет на несколько символов короче.
- Вы можете назначать коммиты более согласованно с названиями заявок в вашем трекере проблем / функций (которые не используют прошедшее время, хотя иногда и будущее)
Билеты пишутся либо как что-то, что происходит в данный момент (например, приложение показывает неправильное поведение при нажатии этой кнопки), либо как что-то, что необходимо сделать в будущем (например, текст будет нуждаться в редакторе).
История (т.е. сообщения коммита) записывается как то, что было сделано в прошлом (например, проблема была исправлена).