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

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

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

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

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

Обновление 1: если я должен был объединить мастер с поддержкой мобильных устройств и поддержку мобильных устройств с мастером, получу ли я реплицированные коммиты в обеих ветвях. Или git достаточно умен, чтобы понять, что я перенес последние изменения из ветви A в ветку B и добавил коммит слияния C в ветку B. И я вытащил последние изменения из ветви B в ветвь A и добавил коммит слияния D в ветку A?

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

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

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

git checkout master
git pull
git checkout mobiledevicesupport
git merge master

поддерживать мобильную поддержку устройств в синхронизации с мастером

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

git checkout master
git merge mobiledevicesupport
git push origin master

и это все.

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

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

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

Подход concept47 - верный способ сделать это, но я бы посоветовал объединить его с параметром --no-ff, чтобы сохранить историю ваших изменений.

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

Да, я согласен с вашим подходом. Для объединения поддержки мобильных устройств в мастер вы можете использовать

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

Точно так же вы можете также объединить мастер в поддержке мобильных устройств.

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

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

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.

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

1. Ускоренное слияние
2. Истинное слияние (требует ручного усилия)

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

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

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

1 git fetchиз вашей ветки функций (убедитесь, что ветка функций, над которой вы работаете, обновлена ​​до даты)

2 git rebase origin/develop

3 если возникнет конфликт, разрешите их один за другим

4 используйте, как git rebase --continueтолько все конфликты разрешены

5 git push --force

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