Одна большая регистрация или несколько меньших?

Question

Вчера, когда я проверил последнюю версию нашего внутреннего инструмента, я увидел около 30+ новых версий.Это меня заинтересовало, так как я подумал, что кто-то наконец-то исправил эти надоедливые ошибки и добавил функцию, которую я так долго ждал ...Ничего из этого не произошло, кто-то просто подумал, что было бы неплохо обновить некоторые заголовки и выполнить небольшую настройку двух или трех функций.Все в отдельном коммите.Отлично.

Это вызвало дискуссию в нашей команде - должно ли это считаться нормальным, или мы должны запретить такие "злоупотребления"?Возможно, это действительно может вписаться в один или два коммита, но 30 кажется многим.Как с этим обращаться - каков наилучший метод?

Answer 1

Вы должны совершать изменения каждый раз, когда вносите изменения и собираетесь перейти к следующему.

Вы не должны совершать ничего, что мешало бы проекту построить.

Вы должны заполнить сообщение о коммите, чтобы люди знали, какие изменения были внесены.

Это подойдет мне ... Я не думаю, что что-то было сделано, если я не увижу это в сообщении коммита ...

Answer 2

Обычно я думаю, что коммит должен относиться к одной логической задаче, например, исправление ошибки # 103 или добавление новой функции печати. Это может быть один файл или несколько, так что вы можете увидеть все изменения, сделанные для конкретной задачи. Также легче откатить изменения, если это необходимо.

Если каждый файл проверяется один за другим, непросто увидеть изменения, внесенные для определенного обновления / задачи.

Также, если несколько задач выполнены за один коммит, непросто увидеть, какие изменения принадлежат какой-либо задаче.

Answer 3

Меня не волнует количество коммитов, так как каждый коммит сохраняет согласованность проекта (сборка все равно будет успешной). Это какой-то внутренний счет, который не должен вас беспокоить. Если вы хотите что-то здесь изменить, лучше попросите людей использовать некоторые структурированные коммит-сообщения (например, «[bugfix] ...», «[feature] ...», «[minorfix]»).

Кстати, если вы хотите знать, были ли исправлены ошибки или добавлены функции, использовать систему отслеживания ошибок гораздо лучше, чем проверять коммиты в SVN-подобном инструменте.

Answer 4

Борьба с энтропией кода - это постоянное командное усилие. Следует поощрять мелкие проверки, когда кто-то просто «чинит разбитые окна», а не осуждать. Исходный репозиторий - это неправильный инструмент для отслеживания исправлений ошибок - вот для чего предназначен баг-трекер - поэтому неудобство при поиске исправлений при сканировании репозитория кода, а не репозитория ошибок , кажется мне совершенно незначительным.

Я работаю в команде среднего размера на большой базе кода (~ 1M LOC) с огромной историей (~ 20Y). Большая часть кода представляет собой кучу беспорядочной логики ветвей, устаревшего API, соглашений об именах, даже случайные отступы часто делают чтение трудным. У меня появилась привычка к небольшим улучшениям читабельности «за рулем», чтобы попытаться бороться с полным гниением кода, и я очень стараюсь заставить товарищей по команде принять ту же привычку.

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