Если мы наберем sh коммитов в единицу в Git и перебазируем, действительно ли имеет значение, что мы перебазируем или объединяем?

Question

Причина, по которой мы перебазируем это то, что история все линейная. Но если мы примем sh коммитов в один, имеет ли значение, если мы просто слимся, а затем проигнорируем какую-либо ветвь?

Я говорил с коллегой о возможности выполнять бинарный поиск, если история линейна и если один разработчик имеет 7 коммитов и 1 коммит из 7 коммитов внес ошибку, мы можем точно определить, какой коммит это использует, используя автоматический бинарный поиск (и автоматический тест). Но он сказал, что если некоторые промежуточные коммиты на самом деле еще не годятся, и это может нарушить сборку или сломать тест. Затем он упомянул возможность собрать все коммиты sh в один и просто перебазировать, тогда не было бы такой проблемы с перехватом не готового коммита.

Если бы мы действительно могли использовать бинарный поиск найти, какая фиксация внесла новую ошибку, это хорошо, и нам не нужно беспокоиться о том, что история имеет в 7 раз больше коммитов, потому что O (log n) не проблема, когда n увеличивается в 7 раз - это просто значит еще 3 билда и тест. Но действительно ли мы делаем бинарный поиск, чтобы найти новую ошибку, используя автоматическую сборку и автоматизированный тест на практике? Это кажется действительно трудоемким.

Если мы просто слимся, а потом вообще проигнорируем какую-либо ветку, разве это не будет то же самое, что squa sh и rebase? Один дополнительный коммит слияния имеет ту же форму, когда мы игнорируем любую ветвь (просто прямую линию), по сравнению с тем, что мы просто скваем sh все коммиты в один и перебазируем.

Answer 1

Если ваш рабочий процесс состоит в том, чтобы объединить sh в один коммит и затем перебазировать, вы можете просто объединить вместо этого, чтобы сохранить разрешение. В представлении «первый родитель» (которое является формальным названием того, что вы называете «игнорировать любую ветвь») различия между каждым коммитом слияния должны быть идентичны истории сквоша / перебазирования. Сохранение предпочтительной истории коммитов разработчиков из их ветвей функций особенно полезно, если ваш рабочий процесс удаляет ветви функций после их объединения в главную (или разработку). Конечно, вам не нужны дополнительные коммиты, но иногда приятно иметь возможность следить за ходом процесса разработки.

Как правило, ошибки чаще встречаются при сломанных строка кода , а не commit , поэтому я бы не стал ценить дополнительные коммиты с единственной целью поиска ошибок, если только они не автоматизированы. Если вы намереваетесь автоматизировать git bisect (или другой бинарный поиск) путем проверки и построения определенных c коммитов, тогда ранжирование от самого простого к сложному для автоматизации будет следующим: лучше будет выполнить перебазирование без squa sh, слияние будет на втором месте, а squash / rebase будет наихудшим (потому что каждый коммит будет содержать много изменений без разрешения на отдельные коммиты). Обратите внимание, что вы все еще можете автоматизировать изоляцию отдельного коммита с помощью слияния, за исключением того, что это более сложно, поскольку вы перемещаетесь по первому родителю до тех пор, пока не найдете нарушающий коммит слияния, а затем проследите за вторым родителем до тех пор, пока не найдете указанный c неработающий commit.

Я лично предпочитаю слияние, а не ребаз, но с небольшим поворотом. Один недостаток слияния, хотя и редкий, заключается в том, что, возможно, в ветви функций нет ошибок, и на самом деле фиксация слияния вносит эту ошибку, даже без конфликтов при слиянии. Чтобы предотвратить это, я советую своей команде всегда сначала перемещать свою ветвь функций на цель, а затем объединяться с --no-ff для принудительного принятия коммита слияния. (Это иногда называют полулинейным слиянием.)

Answer 2

Если вы коммит sh, это не имеет большого значения, перебазируете ли вы или объединяете. Они будут производить идентичные деревья, потому что изменения будут одинаковыми. Если вы используете полнофункциональный сервер Git, такой как GitHub, вы обнаружите, что рабочий процесс squa sh называется "squa sh and merge", но его поведение идентично.

Как вы заметили, вы не можете раздавить преимущество, заключающееся в том, что вы можете с большой точностью разделить изменения, которые привели к ошибке. Тем не менее, вы также можете сделать это с обычным рабочим процессом слияния, который не равно sh, потому что git bisect прекрасно знает, как обрабатывать коммиты слияния.

Для того, чтобы получить реальную выгоду от этого дополнительного история, как правило, вы должны иметь рабочий процесс, который имеет здравые, логичные, делимые на коммиты коммиты. Если у вас есть много того, что мы называем «фиксацией коммитов», которые исправляют синтаксические ошибки или другие ошибки и не применяют вменяемые, логические коммиты, тогда git bisect будет сложнее отследить проблемный c коммит, потому что некоторые коммиты даже не будет строить. Таким образом, вы должны применять эту политику при проверке кода и, возможно, даже в CI, если хотите принять ее. Вместо этого преимущество сжатия заключается в том, что разработчики могут быть ленивыми, но за счет потенциально огромных, непостижимых дампов кода в виде отдельных коммитов.

При работе с Git мы действительно часто используем git bisect для отслеживания вниз проблемат c фиксирует. Я также использовал его на прежнем рабочем месте, чтобы отследить, где мы ввели регрессии, так что это широко используемый подход. Тем не менее, некоторые проекты не заботятся о том, где что-то сломалось, и не используют возвраты, поэтому они не используют git bisect. Это зависит от вашего проекта и рабочего процесса, а также от культуры вашей команды.

После того, как я увидел подход, работа должна требовать либо вменяемых, логических, делимых коммитов, либо раздавливания. Если вы осторожный, методичный разработчик, который готов сделать ребаз и получить коммиты прямо перед слиянием, то вы можете слить их сразу; если ты хочешь быть ленивым, тогда тебе нужно набраться sh. Это сохраняет возможность деления на ветви, облегчая работу менее требовательным разработчикам. Этот подход также может быть реализован с помощью rebase, если вы предпочитаете.

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

Answer 3

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

Это не так действительно имеет большое значение, используете ли вы рабочий процесс типа слияния или ребазирования, с точки зрения обнаружения ошибки. В любом случае, скорее всего, многие коммиты уже были сделаны с момента появления коммита ошибки. В любом рабочем процессе вы бы исправили ошибку, сделав один или несколько коммитов, которые решают проблему. Преимущество rebase, как вы правильно указали, заключается в том, что git bisect может использоваться для детализации до точного коммита, который привел к ошибке. В случае рабочего процесса слияния git bisect все равно сообщит вам, какой коммит привел к ошибке. Тем не менее, вы можете потерять много разрешения в этом случае. Вместо небольшого функционального коммита с относительно небольшим набором изменений вы могли бы иметь большой коммит слияния, который был сгенерирован веткой объектов, содержащей много коммитов. Таким образом, может быть сложнее сразу точно определить , что в том коммите слияния вызвало проблему.

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