Когда я использую Git, должен ли я выполнить ребазинг перед слиянием?

Question

Я работаю над масштабным проектом Rails, и команда, с которой я работаю, использует Github для управления проектом.Хотя многие изменения обрабатываются локально, а затем передаются непосредственно в нашу ветку разработки, мы создаем ветку, когда собираемся работать над очень большими изменениями.Когда приходит время объединить эту ветвь с разработкой, я часто пытаюсь перераспределить разработку обратно в свою функциональную ветвь, прежде чем объединить свою функциональную ветку с разработкой (чтобы предотвратить перезапись чужих работ).Я обнаружил, что когда я делаю это, я, кажется, сталкиваюсь с одним и тем же конфликтом слияния дважды.Я сталкиваюсь с целым списком конфликтов при перебазировании, затем снова сталкиваюсь с тем же списком конфликтов при слиянии.Должен ли я перераспределить разработку в свою ветку возможностей перед тем, как объединить свою функцию с разработкой, или я должен просто объединить свою функцию в разработку?

Допустим, моя ветка функции называется "new_feature".Мой процесс слияния с ветвью "разработка" выглядит следующим образом:

git checkout develop 

git pull (this is set up on our rig to always pull rebase)

git checkout new_feature 

git rebase develop 

(lots of merge conflicts ensue) 

git checkout develop  

git merge -no-ff new_feature 

(same set of merge conflicts again)

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

Answer 1

ОК, это слишком долго для комментария.

Перефразируя руководство (git help rebase)

   Assume the following history exists and the current branch is "new_feature":

                 A---B---C new_feature
                /
           D---E---F---G develop


   From this point, the result of either of the following commands:

       git rebase develop
       git rebase develop new_feature

   would be:

                         A'--B'--C' <new_feature
                        /
           D---E---F---G <develop

Теперь, если у вас возникли конфликты, фактическое состояние после первоговыполнение rebase будет

              A'--B'--C'--[local state]
             /        ^
D---E---F---G          new_feature
            ^ develop

, где [local state] - конфликтующее слияние, которое вам еще предстоит исправить.После того, как вы разрешите конфликты слияния и добавите разрешенные файлы в индекс, вы запустите git rebase --continue: теперь ваше состояние будет

              A'--B'--C'--H <new_feature
             /
D---E---F---G <develop

Очевидно, что в этот момент слияние new_feature обратно в development может быть быстрым.отправлено так:

              A'--B'--C'--H <new_feature  <develop
             /
D---E---F---G

но если это не так, вы получите это вместо

              A'--B'--C'--H <new_feature
             /             \
D---E---F---G---------------I <develop

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

Answer 2

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

Я бы перебазировал ветвь функции на development, а затем (на разработке) сделал быgit merge --ff-only feature.

Answer 3

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

Использование --no-ff в слияниях отлично подходит для сохранения исходной точки ветвления.Я поддерживаю его использование.