синхронизация мерзавца переоснованных ответвлений
Мне недавно ответили на вопрос о мультикомпьютерной установке разработки мерзавца, и решение, которое я получил, там решало мою ситуацию с 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
Скажем, та переоснова имела несколько конфликтов, которые должны были быть вручную зафиксированы, прежде чем переоснова была окончательной. Если я продвигаю те изменения в удаленном репозитории и теперь хочу раскрыть изменения на другую систему разработки, которая имеет исходную установку все еще, что лучший способ состоит в том, чтобы сделать так? git pull --rebase выполнит переоснову снова, и я должен буду вручную пройти конфликты, которые я прошел в первый раз, правильно? И если я сделаю небольшую ошибку при прохождении через конфликтов снова, такой, что E1-H1 немного отличается в этой новой системе, то я получу репозиторий еще больше из синхронизации.
Как я беру локальный репозиторий в исходном состоянии и удаленный репозиторий в третьем состоянии, и имею локальный репозиторий быть обновленным для точного соответствия удаленному репозиторию (повреждающий изменения E-H и двигающий ГОЛОВОЙ BUG_37 к новому местоположению)?
3 ответа
Я бы вообще не делал перебазирование на ветку, которая уже используется совместно. Хотя это приводит к самой чистой истории, он изменит хэши всех коммитов в BUG_37 . Таким образом, на целевых машинах вам нужно будет полностью удалить BUG_37 и вытащить его снова. Это нормально сделать один или два раза, но не так хорошо, как обычный рабочий процесс.
Будет намного проще объединить мастер в BUG_37 ; тогда фиксация слияния (где вы устранили конфликты) может быть перенесена на другие машины, и ветви не нужно будет удалять.
Удалите ветку, затем вытащите обе ветки из удаленного репозитория.
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
Я использую тот же рабочий процесс, в основном переключаюсь между ноутбуком и настольным компьютером. Я держу свое основное репо на настольном компьютере, а ноутбук клонирует репозиторий настольного компьютера. В конце концов, они рассинхронизируются, потому что я хочу перебазировать свои тематические ветки после обновления master .
Простой ответ - просто не используйте git, а используйте rsync для синхронизации репозиториев. Если вы знаете, что работаете над этим только вы, тогда это имеет смысл.
Что ж, я тоже не большой поклонник этого решения. Итак, это могло бы быть немного «чище». На портативном компьютере при извлечении перебазированных ветвей из репозитория рабочего стола:
git co topic
git fetch origin/topic
git reset --hard origin/topic
Это приведет к удалению всех коммитов, не относящихся к репозиторию рабочего стола, поэтому убедитесь, что вы действительно хотите это сделать.
Кроме того, вы, вероятно, можете просто git pull ветку master портативного компьютера, так как это всегда должна быть перемотка вперед, потому что вам, скорее всего, не потребуется ее переустанавливать. Я думаю, что имеет смысл переставлять тематические ветки, потому что в противном случае попытка слить их обратно в мастер в самом конце - это боль.