Как сохранить ветвь git в синхронизации с ведущим

В настоящий момент git делает мою голову, я не могу найти лучшее решение для следующего.

Есть две ветки, одна из которых называется master, а одна называется mobiledevicesupport. Я хочу сохранить mobiledevicesupport как непрерывную ветвь, которая будет объединена/синхронизирована с главной ветвью всякий раз, когда mobiledevicesupport стабилен. Это объединит изменения от mobiledevicesupport в master, но также приведет все изменения от мастера в mobiledevicesupport, чтобы ветвь продолжала работать, а функции улучшались или исправлялись. Это необходимо для работы с центральным репозиторием и несколькими разработчиками.

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

Спасибо, вся помощь очень ценится.

Обновление 1: Если бы мне пришлось объединить мастера в mobiledevicesupport и mobiledevice в master, я получаю реплицированные фиксации в обоих ветвях. Или git достаточно умный, чтобы разобраться в том, что я вытащил последние изменения из ветки А в ветвь В и добавил коммит слияния С в ветвь В. И я вытащил последние изменения из ветки В в ветвь А и добавил слияние с фиксацией D к ветки A?

Я собирался опубликовать изображение, но у меня недостаточно репутации, поэтому я думаю, что следующая иллюстрация должна будет сделать. Два ветки непрерывно работают, и слияния часто идут в обоих направлениях. Ключевая вещь, о которой я не уверен, заключается в том, как git будет разыгрывать коммиты, и она заполнит любую ветвь коммитами из другой ветки при слияниях или останется ли она чистой. Раньше я использовал rebase, но, похоже, закончил ветку и поместил все коммиты в мастера, или я сделал это неправильно. Спасибо за помощь до сих пор.

master
A--B--C-----H--I--J--M--N
       \   /    \
mobile  \ /      \
D--E--F--G--------K--L

Ответ 1

да просто сделай

git checkout master
git pull
git checkout mobiledevicesupport
git merge master

чтобы сохранить mobiledevicesupport в синхронизации с master

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

git checkout master
git merge mobiledevicesupport
git push origin master

и т.д.

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

Ответ 2

Всякий раз, когда вы хотите получить изменения от мастера в своей рабочей ветке, выполните git rebase <remote>/master. Если есть какие-либо конфликты. разрешите их.

Когда ваша рабочая ветка готова, снова переформатируйте, а затем сделайте git push <remote> HEAD:master. Это обновит ведущую ветвь на удаленном (центральное репо).

Ответ 3

Подход

concept47 - это правильный способ сделать это, но я бы посоветовал объединиться с опцией -no-ff, чтобы сохранить отчет о фиксации.

git checkout develop
git pull --rebase
git checkout NewFeatureBranch
git merge --no-ff master

Ответ 4

Да, я согласен с вашим подходом. Чтобы объединить mobiledevicesupport в master, вы можете использовать

git checkout master
git pull origin master //Get all latest commits of master branch
git merge mobiledevicesupport

Аналогичным образом вы также можете объединить master в mobiledevicesupport.

Q. Если перекрестное слияние является проблемой или нет.

а. Ну, это зависит от коммитов, сделанных в мобильной * ветки и главной ветке с момента последнего синхронизации. Возьмем следующий пример: После последней синхронизации с этими ветвями происходят следующие комманды

Master branch: A -> B -> C [where A,B,C are commits]
Mobile branch: D -> E

Теперь предположим, что commit B внес некоторые изменения в файл a.txt, а commit D также внес некоторые изменения в файл a.txt. Давайте посмотрим на влияние каждой операции слияния сейчас,

git checkout master //Switches to master branch
git pull // Get the commits you don't have. May be your fellow workers have made them.
git merge mobiledevicesupport // It will try to add D and E in master branch.

Теперь возможны два типа слияния

Быстрое слияние вперед
Истинный слияние (требуется ручное усилие)

Git сначала попытается слить FF, и если он обнаружит, что какие-либо конфликты не будут разрешены git. Это не дает слияния и просит вас объединиться. В этом случае произойдет новая фиксация, которая отвечает за разрешение конфликтов в файле .txt.

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

Ответ 5

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

Ответ 6

Принятый ответ через git merge выполнит эту работу, но оставляет беспорядочную фиксацию heotry, правильный путь должен быть "rebase" с помощью следующих шагов (при условии, что вы хотите, чтобы ваша ветвь функций в sycn была разработана до того, как вы это сделаете окончательный толчок перед PR).

1>'git fetch' from your feature branch (make sure the feature branch you are working on is update to date)
2>'git rebase origin/develop'
3>if any conflict shall arise, resolve them one by one
4>'use git rebase --continue' once all conflicts are dealt with
5>'git push --force'