Ответы:
Инструменты контроля версий достаточно мощны, чтобы позволить человеку увидеть, какие файлы были изменены и какие методы были добавлены. Это означает, что в общем случае сообщения журнала, которые просто дублируют то, что уже существует, загрязняют журнал.
Вы добавили somefuncметод для выполнения требования, а именно:
Это означает, что ваши сообщения журнала должны скорее объяснять, какие функции / ошибки были затронуты или какова была цель рефакторинга.
Не забудьте добавить номер билета / номера .
Если у вас есть какая-либо функция или система отслеживания ошибок с тикетом # или проблемой # , обязательно укажите этот ID # в коммите. Это поможет всем, кто хочет узнать больше о функции или проблеме, над которой вы работали.
В моем последнем проекте был макрос, который был разработан, чтобы удостовериться, что первые 7 цифр комментария были действительным номером проблемы из явного квеста (наша система отслеживания проблем / функций).
Я делаю такие вещи, когда фиксирую, например, исправление дефекта, который требовал внесения изменений в несколько файлов. Это позволяет немного легче определить, что на самом деле изменилось, не глядя на отдельные файлы в наборе изменений.
Для наборов изменений одного файла это не нужно.
Первая строка - это высокоуровневое описание набора изменений, например, ссылка на дефект или пользовательская история.
Если это релевантная информация в повествовании о коммите, то да, включите его. Если единственным битом информации является само имя файла, то нет.
Например, это имеет смысл: «Переместил функцию build_foo () из fooutil.c в foobase.c, так как большинство программ, которые хотят использовать build_foo (), уже включают foobase.c»
На этот раз нет: «Обновлен build_foo () в fooutil.c, чтобы получить параметр bar».
Я хочу добавить другую точку зрения здесь.
Мой ответ - да или нет. Но обычно я бы сказал, да.
Контроль версий действительно достаточно мощный, чтобы знать, какой файл обновляется. Но когда мы делаем
$ git log
Мы видим только сообщение о коммите. Это то, что делает большинство людей.
Посмотрев в сам журнал. Это добавляет дополнительный контекст к этому. Например:
readme.md: Fix typo detected by language tool
Это лучше чем
Fix typo detected by language tool
Однако, если изменения порождают несколько файлов, то хотя бы упомяните компонент, который редактируется.
API: Fix reset password not sent email to user
Читая его, мы узнаем, что исправляемая ошибка находится в компоненте API и, вероятно, в каталоге API в базе кода.
Однако мы могли бы сделать
$ git show COMMIT_ID --name-only
но это добавляет еще один шаг, чтобы получить файлы.
Единственный раз, когда я вижу, что это полезно для регистрации одного файла, это если вы внесли изменения в функцию, используемую во многих местах в файле, в результате чего diff будет загроможден. Уже тогда я поставил бы трекер изменений # и текстовое описание изменения первым.
Я думаю, что реальный вопрос здесь - насколько ограничены ваши коммиты? Если вы ждете, чтобы зафиксировать различные несвязанные изменения в одном коммите, вам может потребоваться указать, какие файлы были изменены с какой целью.
Однако, если вы просто делаете более узкие коммиты чаще, тогда один коммит объяснит, какие файлы были изменены, и вы можете просто описать, какова была цель сообщения.
Больше коммитов, чаще. Таким образом вы можете не быть настолько многословным в своих сообщениях.