Должен ли я использовать git rebase вместо git merge, когда я работаю только над двумя ветками?

Question

Скажем, в ребазе участвуют две ветви A и B. Я единственный, кто вносит изменения в эти ветви, но есть другие люди, которые потянули эти ветви только для того, чтобы посмотреть, что происходит (обзор). Они не делали / не будут вносить никаких изменений в эти ветви вообще. Учитывая плюсы и минусы перебазирования против слияния, перебазирование, безусловно, является лучшим вариантом для

Теперь, В документе git по rebase упоминается золотое правило о перебазировании

Золотое правило git rebase - никогда не использовать его в публичных ветках.

и объясняет, почему это может быть опасно.

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

Стоит ли этого избегать, даже когда Я единственный разработчик в этих двух ветках, связанных с перебазированием ? Что может пойти не так после того, как я произвожу толчок после перебазирования, и другие члены команды попытаются вытянуть эти ветви (опять же, просто чтобы просмотреть их, они не внесли никаких изменений)?

Answer 1

Что может пойти не так после того, как я произвожу толчок после перебазировки, и другие члены команды попытаются вытянуть эти ветви (опять же, просто чтобы посмотреть их, они не внесли никаких изменений)?

Ничто не может пойти "не так". Худшее, что может случиться, это то, что у «зрителей» возникнут лишние проблемы со слиянием, поскольку ваши новые принудительно сделанные коммиты могут выглядеть совершенно по-другому, и теперь их извлечение (то есть извлечение и слияние) приводит к конфликтам слияния .

Стоит ли этого избегать, даже когда я являюсь единственным разработчиком в этих двух ветках, связанных с перебазированием?

Хотя перебазирование позволяет вам иметь аккуратную и линейную историю мерзавцев и определенно имеет свои преимущества, вот некоторые мысли о том, почему «слияние» иногда может быть предпочтительнее, чем «перебазирование», даже если вы находитесь в "напиши" -контроль над вашими ветками:

1) Чтобы избежать необратимого удаления кода в результате неправильных решений во время конфликтов слияния.

Пример. Допустим, вы работали над своей веткой функций A в течение двух недель, а теперь вы перестаете работать над ней и вместо этого продолжаете работу над веткой B в течение двух недель. Теперь, спустя некоторое время, вы чувствуете, что пришло время снова поработать с веткой A, и по какой-то причине вам нужны изменения, содержащиеся в B, включенном в A, поэтому вы решили перенести ветку A на B. В ходе этой перезагрузки возникает несколько конфликтов слияния. Из-за неправильного суждения или по чистой случайности вы удаляете части своего кода в A, чтобы разрешить конфликты в пользу входящих изменений. Теперь вы продолжаете и завершаете ребазинг и принудительно отправляете свой код на origin/A вашего пульта. Внезапно вы понимаете, что вы удалили части своего кода в ветке A, которые были важны и не должны были быть удалены. Однако, поскольку rebase переписывает историю, в отличие от слияния, вы не можете просто отменить восстановление, и ваш код потерян.

Ситуация, описанная выше, особенно проблематична, если вы говорите младшим в вашей команде, что они всегда предпочитают rebase, а не merge, и они случайно удаляют свой код, принимая неправильные решения в ходе конфликтов слияния, особенно когда ребас переходит на * 1031. *.

Конечно, решением этой проблемы, кроме использования git merge, было бы создание резервной ветви перед выполнением ребазинга.

2) Чтобы избежать решения слишком большого количества конфликтов при интерактивной перебазировке.

Когда ваша ветвь функций содержит несколько коммитов, то есть вы перемещали код совсем немного и, возможно, даже назад и вперед, тогда перебазировка может занять намного больше времени, чем слияние, потому что перебазировка будет идти в последовательности ( !) через коммиты вашей ветки один за другим и останавливается на каждом обнаруженном конфликте. При слиянии вы будете сравнивать только текущее состояние, то есть HEAD вашей функциональной ветви, с HEAD ветви, на которую вы перебазируете (например, master), и, возможно, конфликты отсутствуют вообще при выполнении слияния, хотя могут быть некоторые конфликты при выполнении ребазирования. Так что в этом смысле слияние потенциально экономит ваше время.

Answer 2

Проблема может возникнуть, когда рецензенты извлекают ваш код.

Git извлечет перебазированные коммиты и попытается объединить их с веткой рецензента.

Это либо создаст коммит слияния - если все пойдет хорошо или это приведет к конфликту слияния.

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

Answer 3

Существует расширенная версия вашего "золотого правила" при перебазировании:

Золотое правило git rebase - никогда не использовать его в публичных ветках.

Расширенная версия выглядит следующим образом: Используйте только rebase или другие движения типа принудительного толчка для имен ветвей, где все пользователи с таким именем ожидают поведения, которое в результате . Это связано с тем, что каждому такому пользователю может потребоваться предпринять какое-то действие для восстановления после такой операции («перебазирование в восходящем направлении»), а именно: ему или ей может потребоваться «спасти» свои коммиты. Если все пользователи готовы к этому и знают, как искать такие случаи, они не будут удивлены этой проблемой.

Другими словами, если у вас есть команда, скажем, из пяти программистов, и все пять из вас согласны с тем, что "pu" (ветвь "предлагаемое обновление" или "раскладка") постоянно перебазируется, хорошо перебазируем ветку пу. Если кто-то из вас согласен с перебазировкой "развернуть", но четыре из них не , то не ОК, чтобы перебазировать ветку "развернуть".

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

Answer 4

Чтобы определить, использовать ли rebase или слияние, сначала нужно понять, как они работают.

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

C1<-C2<-C3<-C4

Когда две ветви объединяются, создается новый коммит слияния (представлен ниже как M1)

C1<-C2<-C3
 \        \
  \       M1
   \      /
   C4<-C5

, в котором есть ссылка для коммитов, которые объединяются. Здесь история больше не является связанным списком . Он стал ориентированным ациклическим графом.

Rebase работает немного по-другому

C1<-C2<-C3 branch1
  \  
       C4<-C5 branch2

#On branch2
git rebase branch1

  C1<-C2<-C3<-C4'<-C5'

Rebase создал два новых коммита C4 'и C5' вместо C4 и C5 и переместил указатель ветвления на C5 '. Здесь history - чистый связанный список (поскольку ваши коммиты ветки воссоздаются и применяются к ветке, с которой выполняется ребазинг), но создаются два новых коммита, значит история изменилась для branch2 ( ранее, который был C1 <-C4 <-C5). Таким образом, вы должны делать принудительный толчок каждый раз, когда делаете ребаз. </p>

Теперь, чтобы ответить на ваш вопрос:

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

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

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