Итак, что, по вашему мнению, лучше и интуитивно понятнее?
Fixed the XXX bug in YYY
Fix the XXX bug in YYY
Fixes the XXX bug in YYY
Fixing the XXX bug in YYY
Пожалуйста, дайте свои объяснения. Обратите внимание: я спрашиваю с вашей общей точки зрения, то есть вы не должны пытаться связать это с вашими предпочтительными инструментами svn / cvs или языками программирования, а скорее думайте об этом как о чем-то, что должно / может быть применено к любым инструментам и языкам программирования.
Ответы:
Я думаю об этих сообщениях такими, какими они кажутся другим разработчикам. К ним еще не применены изменения, и возникает неявный вопрос: «Что будет делать этот набор изменений / патч?» Он «исправит ошибку XXX в YYY»!
Для других глаголов запись их в виде команды кажется более естественной и работает лучше, если у вас есть конкретная цель заранее - вы можете буквально написать сводку фиксации вместе с предварительными тестами, прежде чем работа будет выполнена.
Я не придаю этому большого веса, но для меня это путь наименьшего сопротивления при сохранении последовательности.
Я лично использую прошедшее время («фиксированное»), так как к тому времени, когда я доберусь до фиксации, ошибка будет исправлена (или я не буду совершать фиксацию).
Я предпочитаю видеть сообщения коммитов в настоящем времени. Таким образом, сообщение описывает, что делает diff (потому что вы можете перетащить этот diff или даже весь коммит в другую ветку). Таким образом, сообщение коммита не описывает, что он «сделал» ... Оно описывает, что делает сам коммит. Так что это должно быть в настоящем времени.
Представьте, что вы смотрите на различие изолированно и пытаетесь решить, будете ли вы его применять. Не имеет смысла иметь название в прошедшем времени.
ИМХО, если вы хотите, чтобы он был описательным, без необходимости учитывать контекст, то «Фиксированный» определенно единственный правильный вариант.
Что касается интуитивности - если я посмотрю на какой-то журнал изменений, я определенно пойму, что вы имеете в виду исправленную ошибку, поскольку я знаю контекст, в котором используется это слово, но мой мозг уловит это намного быстрее, если слово будет написано на этом языке. указание пути.
«Исправление» - наихудший выбор ИМХО, так как его можно интерпретировать не только как описание того, что делает патч (для чего), но также как статус ошибки, что означает, что над ней работают и еще не решены.
Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc
В общем: {повелительный глагол} {затронутый объект} {необязательные квалификаторы}
Императивная форма подходит для всех случаев использования, когда я рассматриваю набор исправлений.
Независимо от вашего выбора, я считаю, что согласованность очень помогает читаемости. Выберите один и придерживайтесь его.
Я думаю, что писать о текущем коммите в настоящем времени - хорошая идея, потому что это делает его более ясным, когда вы ссылаетесь на предыдущие коммиты в прошедшем времени.
Я не думаю, что это действительно важно. Целью является:
1) Сообщайте о том, что делается или делается, чтобы было легче находить ошибки, легче устранять проблемы и, как правило, было легче поддерживать проект.
2) Сообщите, какие заявки были исправлены, если таковые имеются, чтобы аудиторы (если они используются в вашей компании, могли видеть, какие изменения соответствуют каким заявкам).
Наконец, если это уже было исправлено, «Исправление» не имеет смысла, а если вы все еще работаете над этим, «Исправлено» неверно.
« Исправить ошибку X » на 2 символа короче, чем « Исправленная ошибка X ».
И на 3 короче, чем « Исправление ошибки X ».
С точки зрения написания коротких коммит-сообщений настоящее время иногда / обычно сохраняет несколько символов?
Что, на самом деле, имеет значение немного, например, с рекомендацией Git меньше 50 символов в строке сообщения первой фиксации.
Кроме того, меньше текста -> быстрее читаете?
Сообщение о фиксации описывает, почему вы написали код, который фиксируется.
«Исправленная проблема 3124» или «Исправляет проблему 3124» кажется правильным, потому что в нем говорится, что этот код исправлен | исправляет проблему 3124.
Однако грамматика также может зависеть от того, почему ошибка помечена как исправленная. Если вы можете пометить ошибку как исправленную после фиксации, тогда «Исправлено» вполне достаточно, но если ошибка будет отмечена как исправленная кем-то еще после проверки вашего кода, то «Исправления» могут быть более подходящими.
Я думаю, что наиболее важный ответ на такой вопрос: каждый должен использовать то, что работает для конкретного проекта, и поддерживать его хотя бы немного последовательным.
Хотя я вижу преимущества использования настоящего времени (и фактически наткнулся на этот пост, потому что видел некоторые сообщения настоящего времени в проектах с открытым исходным кодом), я, вероятно, никогда не буду использовать настоящее время в своих проектах. Это рекомендуемый способ для Linux и Git и, возможно, других более крупных проектов с открытым исходным кодом, но мне, честно говоря, все равно, если я не участвую в этих проектах.
Я инди-разработчик и использую первую строку сообщения о фиксации для примечаний к выпуску, а описание в следующих строках дает мне представление о деталях реализации. Это ориентированный на пользователя рабочий процесс по сравнению с нынешним временным подходом, ориентированным на разработчиков. Так я сэкономлю время. Было бы крайне неестественно давать моим пользователям инструкции в примечаниях к выпуску. Моя работа - исправлять ошибки и добавлять функции. Мне нужно экономить время, потому что я инди. В моей команде нет «писателя примечаний к выпуску».
Используйте правила проекта, если они уже установлены, но оставайтесь прагматичными и делайте все, что облегчит или ускорит вашу работу.
Если это небольшая фиксация, я использую Present Continuous:
Исправление ошибки 304
или
Добавление комментариев
Если это большая фиксация, я делаю больше журнала изменений: