Статьи

О коммитах и ​​коммитах


Признаюсь, я не обращаю внимания на коммит сообщений столько, сколько я бы.
Очень легко не заботиться о наших сообщениях, особенно если у вас есть привычка совершать очень маленькие приращения. Тем не менее, то, как вы выполняете коммит, влияет на восприятие вашей работы другими людьми, с переменными от сообщений до включаемых файлов и размера. Комитеты — это полароиды из нас, и мы не хотим делать плохую фотографию, верно?

КИСЛОТА совершает

Коммиты, особенно в централизованных системах контроля версий, очень похожи на транзакции реляционной базы данных 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

Ах, вот как выглядит ад … (этот последний комментарий удваивается как возможное сообщение о коммите.)