Одна большая регистрация или несколько меньших?
Вчера, когда я проверил последнюю версию нашего внутреннего инструмента, я занялся 30 + новые версии. Это получило меня любопытный, так как я думал, что кто-то наконец исправил те раздражающие ошибки и добавил ту опцию, я ожидал так долго..., и угадайте что? Ни одного из этого не произошло, кто-то просто думал, что будет хорошо обновить некоторые заголовки и сделать незначительную корректировку двух или трех функций. Все в отдельной фиксации.Отлично.
Это повысило обсуждение в нашей команде - это нужно рассмотреть хорошо, или мы должны запретить такое "злоупотребление"? Возможно это действительно могло поместиться в одну или две фиксации, но 30 кажется очень. Как это должно быть обработано - какова лучшая практика?
4 ответа
Вы должны фиксировать каждый раз, когда вносите изменение и собираетесь перейти к следующему.
Вы не должны фиксировать ничего, что мешает созданию проекта.
Вы должны заполнять сообщение о фиксации, чтобы люди знали, какие изменения были внесены.
Это мне подходит ... Я не думаю, что что-то было сделано, если я не увижу это в сообщении о фиксации ...
Меня не волнует количество коммитов, поскольку каждая фиксация поддерживает согласованность проекта (сборка все равно будет успешной). Это некий внутренний подсчет, который не должен вас беспокоить. Если вы хотите что-то здесь изменить, лучше скажите людям использовать какие-нибудь структурированные сообщения о фиксации (например, «[bugfix] ...», «[feature] ...», «[minorfix]»).
Кстати, если вы хотите знать, были ли исправлены ошибки или добавлены функции, использование системы отслеживания ошибок намного лучше, чем проверка коммитов в SVN-подобном инструменте.
Борьба с энтропией кода - это постоянная командная работа. Незначительные проверки, когда кто-то просто «ремонтирует разбитые окна» по ходу дела, следует поощрять, а не осуждать. Репозиторий исходных текстов - неподходящий инструмент для отслеживания исправлений - для этого и предназначен трекер ошибок - поэтому неудобства в поиске исправлений при сканировании репозитория кода, а не репозитория ошибок кажутся мне совершенно незначительными.
Я работаю в небольшой группе над большой кодовой базой (~ 1M LOC) с огромной историей (~ 20Y). Большая часть кода представляет собой груду беспорядка - прогнившая логика ветвления, устаревший API, соглашения об именах, даже случайные отступы часто затрудняют чтение. У меня появилась привычка к незначительным улучшениям читабельности, пытаясь бороться с полной гнилью кода, и я изо всех сил пытаюсь заставить товарищей по команде перенять ту же привычку.
Если ваши обстоятельства радикально не отличаются, я бы постарался положительно отнестись к любой подобной инициативе. Альтернатива (с которой я хорошо знаком) - это ужасная стагнация, которая обрекает на гниение любой код.
Вообще я считаю, что коммит должен относиться к одной логической задаче, например, исправлению ошибки #103 или добавлению новой функции печати. Это может быть один файл или несколько, так вы сможете увидеть все изменения, сделанные для конкретной задачи. Также легче откатить изменения, если это необходимо.
Если каждый файл проверяется по одному, нелегко увидеть изменения, сделанные для конкретного обновления/задачи.
Также если несколько задач выполняются в одном коммите, нелегко увидеть, какие изменения относятся к какой задаче.