![](https://habrastorage.org/webt/9m/cc/xu/9mccxujzxvko1w3tewtarvqazza.png)
Есть два непримиримых лагеря. Одни говорят: ты должен качественно и грамотно описывать свои коммиты. Каждый коммит — это законченный, осмысленный кусочек работы. Если ты не можешь сделать понятное и простое описания коммита, значит у тебя неправильные коммиты.
Другие считают — ты делаешь коммиты как хочешь, это часть твоего личного рабочего процесса. А вот пул реквесты описываются детально: что сделано, как сделано, зачем сделано. Как протестировано, какую проблему решает, на что стоит обратить внимание.
Я убежденный сторонник второго подхода — мне неудобно бить свою работу на микрокусочки. Я беру небольшую задачу и хаотично мечусь по кодовой базе, экспериментируя и внося изменения в том порядке, в котором получается. Если бы я мог нажать на кнопку, и моя работа переструктурировалась бы на хорошие коммиты — я бы на неё нажал. Но кнопки нет, а ломать себя мне не хочется. В то же время я достиг определенного мастерства в описании пул реквестов. Мне довелось фигачить код в майкрософт (через аутстаф, не считается), и там я почерпнул топовые стандарты оформления пул реквестов. С годами работы я только развивал эту практику. Обычно мне удавалось убеждать команду использовать именно такой подход.
Но на последней работе мне достался девлид — убежденный сторонник детальных коммитов. О, мы долго спорили. Моё подчиненное положение сыграло свою роль, совковскую привычку соглашаться с главным нелегко заткнуть. Я не был так категоричен, как обычно бываю, и был уложен на обе лопатки. Уложен, но не убежден.