Хороший коммит

19 ноября 2008 г.

Совсем недавно в очередной раз столкнулся с проблемой комитов и вообще отношения к хранилищу кода в команде. Этот вопрос очень часто поднимается в таких книжках, как Code Craft. Как показывает практика, ничего от этого не меняется. Либо книжки не читают, либо не знают, как применять на практике полученные знания.

Я уже начинаю думать, что основная причина - это лень. Или программирование в стиле "агонии". Так я называю печатание 10000 символов в час без передышки с полной самоотдачей и без коммитов. Хватаются то за одну задачу, то за другую. И на вопрос: "Почему уже 2 дня не коммитишь?", можно услышать: "Дак у меня еще не до конца функциональность готова. Вот еще немного подшлефую и закомичу".

Чтобы понять как делать хорошие коммиты, необходимо ответить на вопрос, что такое хороший комит?

Хороший комит:

  • Должен быть прокомментирован. Нельзя комитить изменения в общее хранилище кода без комментария
  • Содержит комментарий с информациeй о том, зачем (почему) этот комит был сделан (добавление новой функциональности, исправление бага и т.п.). Комментарий должен пояснить какие изменения были внесены в проект без необходимости просмотра кода
  • Оставляет систему в стабильном рабочем состоянии
  • Содержит единственное атомарное изменение. Не должен содержать изменения, которые не относятся к данному комиту. Возможно, эти изменения кода были сделаны в ходе рефакторинга или небольших багфиксов. Все эти изменения должны попасть в другой комит с соответствующим комментарием
  • Отформатирован в стиле, который приняла вся команда
  • Может содержать ссылку на тикет в вашей системе контроля багов. В некоторых организациях комит не принимаются без закрытия тикета
  • Закомиченный код не должен содержать закомментированного кода, который "оставили на всякий случай"

Этот пост должен добавить вам аргументов в споре с коллегами по этому вопросу. По опыту могу сказать, чтобы склонить команду в правильную сторону необходимо иметь уйму терпения и действовать исключительно дипломатическими приемами. Если Вы ведущий разработчик, тогда все немного проще - можно применить свой авторитет. А вот если Вы рядовой разработчик, то вам придется вести команду к хорошим комитам методами Махатмы Ганди.

Ссылки:

The importance of commit messages

Are Detailed Log Messages Really Necessary?

SVN Commit Policy

SVN и отсутвие мозга у кодера

Best Practices for Version Control

Everyone Commits Every Day

4 комментария:

  1. Интересно, что пост начался с недовольства большими промежутками между коммитами, но большинство указанных правил лишь увеличивают эти самые промежутки (хотя правила грамотные, с этим не спорю).

    Пожалуй, хорошим решением проблемы редких коммитов является использование распределенной системы контроля версий (как по мне, это чуть ли не единственное их реальное преимущество). Тогда программист часто коммитит в свой репозиторий, а потом, когда считает нужным, сливает изменения в условно-основной репозиторий.

    ОтветитьУдалить
  2. А теперь представим ситуацию (из текущего опыта): каждый коммит должен:
    1. содержать ссылку на баг
    2. Должно быть проведено Code Reivew
    3. Должен быть выполнен виртуальный билд (тот же CI, только именно до коммита. После коммита происходит еще и реальный билд "по живому"). Данный этап может занимать до 10-15 часов (на ферме из over 200 машин).
    4. На баг должен быть получен approval (от владельца бранча, либо тимлида). К коммиту это в общем случае не относится конечно, в баге могут быть несколько коммитов, а approval всегда один на баг. Но так как коммиты делаются один на баг, то Approval нужно получать. Еще approval не получить без предыдущих шагов (владелец ветки может не участвовать в code review и вообще не знать, нафига ему этот коммит в ветке).

    Поскольку обычно все изменения делаются в девелоперской ветве, они потом по одному коммиту перетаскиваются в релиз. Именно по одному коммиту, ибо должны быть проведены все теже шаги, что и при простом коммите: code reivew, virtual build, approval для релизной ветки.

    В таких условиях делать кучу мелких коммитов - коллеги загрызут, особенно те, кому эти коммиты потом в другие ветки перетаскивать. 

    Однако закоммитить за один раз тоже не дадут - такой коммит не пройдет CR. 

    Вот так и живем. А, и используется perforce :)

    ОтветитьУдалить
  3. Критерии комита противоречивы."Оставляет систему в стабильном рабочем состоянии", "Содержит единственное атомарное изменение", "В некоторых организациях комит не принимаются без закрытия тикета".
    Очень часто баг/фича закрывается за несколько комитов, каждый из которых есть атомарное изменение. При этом оставить систему в стабильном рабочем состоянии, порой, бывает очень непросто.Собственно этим и объясняется необходимость применения бранчей - создали бранч на баг/фичу, сделали много мелких комитов (каждый из которых НЕ оставляет систему в рабочем состоянии), а когда добились стабильной работы - замержили в родительскую ветку.
    Поэтому критерии, указанные выше - перфекционизм. :-) Ты, кстати, сам придерживаешься их? :)

    ОтветитьУдалить
  4. Сергей, я с тобой согласен. К этим критериям можно стремиться или использовать их в разных комбинациях.

    ОтветитьУдалить

Моя книга «Антихрупкость в IT»

Как достигать результатов в IT-проектах в условиях неопределённости. Подробнее...