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

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

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

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)

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

Ответ 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 обратно на разработку можно быстро перенаправить следующим образом:

              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 будет жаловаться на это.

Ответ 2

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

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

Ответ 3

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

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