Признаюсь, я не обращаю внимания на коммит сообщений столько, сколько я бы. Очень легко не заботиться о наших сообщениях, особенно если у вас есть привычка совершать очень маленькие приращения. Тем не менее, то, как вы выполняете коммит, влияет на восприятие вашей работы другими людьми, с переменными от сообщений до включаемых файлов и размера. Комитеты — это полароиды из нас, и мы не хотим делать плохую фотографию, верно?
КИСЛОТА совершает
Коммиты, особенно в централизованных системах контроля версий, очень похожи на транзакции реляционной базы данных ACID:
- Атомные : они должны быть нанесены за один выстрел или полностью отменены.
- Согласованно : сборка должна быть зеленой до и после коммита (по крайней мере после опубликованных коммитов, если вы работаете с Git или Mercurial).
- Изолированный : никаких эффектов на билде не видно, пока мы не нажмем большую кнопку.
- Прочный : я не хочу терять коммиты, которые я сделал час назад.
Небольшие коммиты ACID важны как для простоты их отката в случае сбоя, так и для независимого применения при объединении или переносе.
Но это еще не все: они мне нравятся еще и потому, что проще писать их сообщения:
- Вы не забудете то, что сделали 45 минут назад, или как быстрый рефакторинг.
- Вы не включаете ненужные файлы , так как их всего 4-5, и злоумышленник может быть легко обнаружен со статусом git.
- Вам не нужно делать git add -i, чтобы выбрать только файлы, которые должны были быть включены, или даже отдельные строки файла (как вы тестируете этот частичный коммит, не нарушая сборку? Stash, run and stash поп? я думаю это уже слишком сложно). Например, в Subversion даже нет возможности выбора файлов для фиксации.
Может быть, мы должны опубликовать несколько строк в сообщениях коммитов, которые считаются вредными ?
DRY
Однако моя проблема связана также с сообщениями о коммитах, а не только с их содержанием. Но давайте посмотрим правде в глаза, сообщения коммитов являются частью кода, так же как и имена файлов: никто не собирается компилировать или тестировать ваш код, не переходя из системы контроля версий.
Я думаю, что статус сообщений коммитов аналогичен статусу докоблоков : большинство из нас пишут по несколько раз в час, но без особого представления об их важности.
Первое предложение, которому я без труда следил, — это не повторять вещи, уже сохраненные в VCS, такие как автор коммита или дату и время, когда он был сделан. Вместо этого я борюсь с семантикой.
Сообщение фиксации обычно пишется один раз, но читайте его везде и всегда, когда кто-то просматривает журнал или хочет объединить ваши изменения. Вы даже не можете переписать его так, как вы бы сделали с проблемной, уродливой строкой кода в сеансе рефакторинга.
Таким образом, сообщения коммитов являются своего рода CD-R , но почему мы должны заботиться о них? Они оказываются полезными в некоторые другие моменты дня:
- в то время как поиск изменений, внесенных много лет назад в класс X или компонент Y, сообщения о фиксации — единственное поле, по которому мы можем фильтровать. Другие поля слишком мягкие (автор) или не читаются человеком (ревизия или UUID).
- Читая git log или svn log, вы узнаете, что сделали наши коллеги.
- При создании журналов изменений и других отчетов или статистики, также следя за тегами, такими как [1.1] или [feature_name].
Руководство и стандарты проекта
Вам не нужно изобретать стиль сообщения коммита; возможно, в стандартах кодирования вашего проекта уже есть некоторые соглашения:
- форматирование: прописные и строчные, и какие слова следует трактовать иначе, чем обычные существительные (например, имена шаблонов обычно обозначаются как декоратор , а не декоратор ).
- глаголы времен, существительные формы для уважения.
- Состав: сколько файлов и папок.
- теги: [1.0] и аналогичные текстовые метаданные.
Смысл всех этих правил заключается просто в ограничении степеней свободы сообщения коммита, которое в противном случае было бы свободным текстом формы . Так же, как мы предпочитаем хорошо отформатированный код с 4 пробелами (или 8 или 2 или любым другим непротиворечивым значением, который вам нравится) в качестве отступа, то же самое относится и к стилю наших сообщений. Поиск набора последовательно написанных сообщений коммита становится удовольствием.
Возможно, вы захотите создать эти рекомендации, если они еще не включены в ваш проект, и у вас есть право сделать это. Это не микроуправление, это просто расширение стандартов кодирования.
Последнее слово
Наконец, вот инструмент для случаев, когда вы действительно не знаете, что написать в сообщении (юмор предназначен). Это замечательный генератор бессмысленных коммитов :
Refactored configuration. Fixed unnecessary bug. I must sleep... it's working... in just three hours... add actual words fix bug, for realz more ignored words Don't push this commit
Ах, вот как выглядит ад … (этот последний комментарий удваивается как возможное сообщение о коммите.)