Совсем недавно в очередной раз столкнулся с проблемой комитов и вообще отношения к хранилищу кода в команде. Этот вопрос очень часто поднимается в таких книжках, как Code Craft. Как показывает практика, ничего от этого не меняется. Либо книжки не читают, либо не знают, как применять на практике полученные знания.
Я уже начинаю думать, что основная причина - это лень. Или программирование в стиле "агонии". Так я называю печатание 10000 символов в час без передышки с полной самоотдачей и без коммитов. Хватаются то за одну задачу, то за другую. И на вопрос: "Почему уже 2 дня не коммитишь?", можно услышать: "Дак у меня еще не до конца функциональность готова. Вот еще немного подшлефую и закомичу".
Чтобы понять как делать хорошие коммиты, необходимо ответить на вопрос, что такое хороший комит?
Хороший комит:
- Должен быть прокомментирован. Нельзя комитить изменения в общее хранилище кода без комментария
- Содержит комментарий с информациeй о том, зачем (почему) этот комит был сделан (добавление новой функциональности, исправление бага и т.п.). Комментарий должен пояснить какие изменения были внесены в проект без необходимости просмотра кода
- Оставляет систему в стабильном рабочем состоянии
- Содержит единственное атомарное изменение. Не должен содержать изменения, которые не относятся к данному комиту. Возможно, эти изменения кода были сделаны в ходе рефакторинга или небольших багфиксов. Все эти изменения должны попасть в другой комит с соответствующим комментарием
- Отформатирован в стиле, который приняла вся команда
- Может содержать ссылку на тикет в вашей системе контроля багов. В некоторых организациях комит не принимаются без закрытия тикета
- Закомиченный код не должен содержать закомментированного кода, который "оставили на всякий случай"
Этот пост должен добавить вам аргументов в споре с коллегами по этому вопросу. По опыту могу сказать, чтобы склонить команду в правильную сторону необходимо иметь уйму терпения и действовать исключительно дипломатическими приемами. Если Вы ведущий разработчик, тогда все немного проще - можно применить свой авторитет. А вот если Вы рядовой разработчик, то вам придется вести команду к хорошим комитам методами Махатмы Ганди.
Ссылки:
The importance of commit messages
Are Detailed Log Messages Really Necessary?
Интересно, что пост начался с недовольства большими промежутками между коммитами, но большинство указанных правил лишь увеличивают эти самые промежутки (хотя правила грамотные, с этим не спорю).
ОтветитьУдалитьПожалуй, хорошим решением проблемы редких коммитов является использование распределенной системы контроля версий (как по мне, это чуть ли не единственное их реальное преимущество). Тогда программист часто коммитит в свой репозиторий, а потом, когда считает нужным, сливает изменения в условно-основной репозиторий.
А теперь представим ситуацию (из текущего опыта): каждый коммит должен:
ОтветитьУдалить1. содержать ссылку на баг
2. Должно быть проведено Code Reivew
3. Должен быть выполнен виртуальный билд (тот же CI, только именно до коммита. После коммита происходит еще и реальный билд "по живому"). Данный этап может занимать до 10-15 часов (на ферме из over 200 машин).
4. На баг должен быть получен approval (от владельца бранча, либо тимлида). К коммиту это в общем случае не относится конечно, в баге могут быть несколько коммитов, а approval всегда один на баг. Но так как коммиты делаются один на баг, то Approval нужно получать. Еще approval не получить без предыдущих шагов (владелец ветки может не участвовать в code review и вообще не знать, нафига ему этот коммит в ветке).
Поскольку обычно все изменения делаются в девелоперской ветве, они потом по одному коммиту перетаскиваются в релиз. Именно по одному коммиту, ибо должны быть проведены все теже шаги, что и при простом коммите: code reivew, virtual build, approval для релизной ветки.
В таких условиях делать кучу мелких коммитов - коллеги загрызут, особенно те, кому эти коммиты потом в другие ветки перетаскивать.
Однако закоммитить за один раз тоже не дадут - такой коммит не пройдет CR.
Вот так и живем. А, и используется perforce :)
Критерии комита противоречивы."Оставляет систему в стабильном рабочем состоянии", "Содержит единственное атомарное изменение", "В некоторых организациях комит не принимаются без закрытия тикета".
ОтветитьУдалитьОчень часто баг/фича закрывается за несколько комитов, каждый из которых есть атомарное изменение. При этом оставить систему в стабильном рабочем состоянии, порой, бывает очень непросто.Собственно этим и объясняется необходимость применения бранчей - создали бранч на баг/фичу, сделали много мелких комитов (каждый из которых НЕ оставляет систему в рабочем состоянии), а когда добились стабильной работы - замержили в родительскую ветку.
Поэтому критерии, указанные выше - перфекционизм. :-) Ты, кстати, сам придерживаешься их? :)
Сергей, я с тобой согласен. К этим критериям можно стремиться или использовать их в разных комбинациях.
ОтветитьУдалить