Итак, что вы думаете лучше и интуитивно понятнее?
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 или даже весь этот commit в другую ветку). Таким образом, сообщение фиксации не описывает то, что оно "делало"... Оно описывает то, что делает сам commit. Так что это должно быть в настоящем времени.
Представьте, что вы смотрите на разницу в изоляции и пытаетесь решить, будете ли вы ее применять. Для него нет никакого смысла иметь титул в прошедшем времени.
IMHO, если вы хотите, чтобы он был описательным без необходимости рассматривать контекст, тогда "Исправлено", безусловно, является единственным правильным вариантом.
Что касается интуитивности - если я посмотрю на какой-то журнал изменений, я определенно пойму, что вы имеете в виду исправленную ошибку, поскольку я знаю контекст, в котором используется это слово, но мой мозг поймает его гораздо быстрее, если это слово написано в этот способ самоопределения.
"Фиксация" - худший вариант ИМХО, поскольку его можно интерпретировать не только как описание того, что делает патч (для), а как статус ошибки, что означает, что он работает и еще не решен.
Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc
В целом: {императивный глагол} {затронутый объект} {необязательные квалификаторы}
Императивная форма подходит для всех случаев использования, когда я рассматриваю патч-набор.
Независимо от вашего выбора, я нахожу, что согласованность очень удобна для чтения. Выберите один и придерживайтесь его.
Я думаю, что писать о текущей фиксации в настоящем времени - хорошая идея, потому что это делает ее более ясной, когда вы ссылаетесь на предыдущие фиксации в прошедшем времени.
Я не думаю, что это действительно имеет значение. Цель состоит в следующем:
1) Передайте то, что было или было сделано, поэтому ошибки могут быть найдены легче, проблемы могут быть легко устранены и, как правило, легче поддерживать проект.
2) Сообщите, какие билеты были исправлены, если таковые имеются, поэтому аудиторы (если они используются в вашей компании, могут видеть, какие изменения соответствуют тем билетам).
Наконец, если он уже исправлен, "Исправление" не имеет смысла, и если вы все еще работаете над ним, "Исправлено" неверно.
"Исправить ошибку X" на 2 символа короче, чем "Исправлена ошибка X".
И 3 короче, чем "Исправление ошибки X".
С точки зрения писем-short-commit-сообщений текущее время иногда/обычно сохраняет несколько символов?
На самом деле, я думаю, что это немного немного, например. с рекомендацией Git для строки менее 50-символов-на-первом-commit-сообщении.
Кроме того, меньше текста → чтение быстрее?
Сообщение о фиксации описывает, почему вы написали код, который выполняется.
"Исправлена проблема 3124" или "Исправлена проблема 3124", кажется правильным, потому что он говорит, что этот код исправлен | исправляет проблему 3124.
Тем не менее, грамматика также может зависеть от того, почему эта ошибка является фиксированной. Если вы можете пометить ошибку как фиксированную после фиксации, то "Исправлено" просто отлично, но если ошибка будет отмечена как исправленная кем-то еще после проверки вашего кода, тогда "Исправления" могут быть более подходящими.
Я думаю, что самый важный ответ на такой вопрос: каждый должен использовать то, что работает для конкретного проекта, и держать его по крайней мере на небольшом согласованном уровне.
Пока я вижу преимущества использования настоящего времени (и на самом деле наткнулся на этот пост, потому что я видел некоторые текущие сообщения в проектах с открытым исходным кодом), я, вероятно, никогда не буду использовать настоящее время для своих проектов. Его рекомендуемый способ для Linux и Git и, возможно, других крупных проектов с открытым исходным кодом, но я честно не забочусь, пока Im не является частью этих проектов.
Im ande dev и я использую первую строку сообщения фиксации для примечаний к выпуску, в то время как описание в следующих строках дает мне представление о деталях реализации. Его ориентированный на пользователя рабочий процесс по сравнению с нынешним временем, основанным на разработчике. Я могу сэкономить время. Было бы крайне неестественно давать указания моим пользователям в примечаниях к выпуску. Его задача исправлять ошибки и добавлять функции. Мне нужно сэкономить время, потому что я инди. У меня нет "писателя заметок" в моей команде.
Используйте правила проекта, если они уже созданы, но сохраняйте прагматичность и делайте все, что сделает вашу работу проще или быстрее.
Я думаю, что "Fixes XXX bug" имеет больше смысла, чем "Fix XXX bug", если причина использования нынешнего времени заключается в том, чтобы "сделать его более описательным из того, что совершает", а не то, что сделал коммиттер.
Если это небольшая фиксация, я использую текущую непрерывную:
Исправление ошибки 304
или
Добавление комментариев
Если это большая фиксация, я делаю больше журнала изменений: