Git синхронизация переустановленных ветвей

Недавно у меня был вопрос о настройке разработки для нескольких компьютеров git, и решение, которое я получил там, решило мою ситуацию с ветвью master, но не боковые ветки, основанные от мастера.

Здесь моя текущая настройка:

A--B--C--D  master
          \
           E--F--G--H  BUG_37

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

A--B--C--D--I--J--K  master
          \
           E--F--G--H  BUG_37

Затем я пересобил ветвь BUG_37 на master, чтобы убедиться, что она работает как усовершенствование самых текущих изменений:

A--B--C--D--I--J--K  master
                   \
                    E1--F1--G1--H1  BUG_37

Скажем, что у rebase было несколько конфликтов, которые необходимо было зафиксировать вручную до того, как rebase станет окончательным. Если я вытащил эти изменения в удаленный репозиторий и теперь хочу потянуть изменения на другую систему разработки, у которой есть первоначальная настройка, какой лучший способ сделать это? git pull --rebase снова запустит rebase, и мне придется вручную пройти через конфликты, которые я прошел в первый раз, не так ли? И если я сделаю небольшую ошибку, повторю конфликты снова, так что E1-H1 немного отличаются в этой новой системе, я получу репозиторий еще больше из-за синхронизации.

Как взять локальный репозиторий в исходном состоянии и удаленный репозиторий в третьем состоянии и обновить локальный репозиторий, чтобы точно соответствовать удаленному репозиторию (trashing меняет EH и перемещает HEAD из BUG_37 в новое местоположение)?

Ответ 1

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

Намного проще объединить master в BUG_37; то фиксация слияния (где вы исправили конфликты) может быть перенесена на другие машины, и ветки не нужно будет удалять.

Ответ 2

Удалите ветку, затем вытащите обе ветки из удаленного репозитория.

git branch -D BUG_37
git pull origin master
git pull origin BUG_37:BUG_37

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

git pull origin BUG_37:NEW_BUG_37

Ответ 3

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

Простой ответ, просто не используйте git, вместо этого используйте rsync, чтобы синхронизировать ваши репозитории. Если вы знаете, что вы единственный, кто работает над этим, тогда это имеет смысл.

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

git co topic
git fetch origin/topic
git reset --hard origin/topic

Это выкинет любые коммиты не на рабочем столе, поэтому убедитесь, что вы действительно хотите это сделать.

Кроме того, вы, вероятно, можете просто git pull ветки ноутбука master, поскольку он всегда должен быть быстрым, потому что вам, скорее всего, не понадобится его переустанавливать. Я думаю, что имеет смысл переустанавливать ветки темы, потому что в противном случае попытка слить его обратно в мастера в самом конце - это боль.

Ответ 4

Я только что экспериментировал с ним, и использование git pull --rebase работает, когда вытаскивается из переустановленной ветки. Без флага --rebase коммиты будут дублироваться, но с --rebase коммиты не дублируются.