Один большой checkin или несколько более мелких?

Question

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

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

Answer 1

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

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

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

Это будет делать для меня .. Я не предполагаю, что-то было сделано, если я не вижу его в сообщении фиксации ...

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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