Як зберегти гілку git синхронізовано з master

На даний момент git запускає голову, я не можу придумати найкращого рішення для наступного.

Є дві гілки, одна з яких називається майстер, а одна називається mobiledevicesпідтримка . Я хочу зберегти mobiledevicesupport як суцільну гілку, яка буде об'єднана / синхронізована з основною гілкою, коли mobiledevicesupport стабільний. Це дозволило б об'єднати зміни з мобільного пристрою підтримки в головний, але також внести всі зміни з головного в мобільний пристрої підтримки, щоб гілка могла продовжувати працювати, а функції покращувати чи доповнювати. Для цього потрібно працювати з центральним сховищем та кількома розробниками.

Наведіть приклад подібних робочих процесів, які використовують інші люди або просто скажіть мені, чи думка ця дурна, і я повинен розглянути інші варіанти. На даний момент робочий процес здається здоровим, але я просто не знаю, як я можу змусити Git працювати таким чином.

Дякую, всі допомагають дуже вдячні.

Оновлення 1: Якщо я мав би об'єднати master у підтримку mobiledevicesпідтримка та підтримка mobiledevice у master, чи отримуватиму тиражні коміти в обох відділеннях. Або git досить розумний, щоб розібратися, що я витягнув останні зміни з гілки A у гілку B і додав злиття C у гілку B. І я витягнув останні зміни з гілки B у гілку A і додаю комісію злиття D у гілку А?

Я збирався опублікувати зображення, але мені не вистачає репутації для нього, тому, мабуть, слід буде виконати наступну ілюстрацію. Дві гілки, що постійно працюють із злиттями, часто йдуть в обидва напрямки. Ключова річ, в якій я не впевнений, - це те, як git розіграє коміти та чи заповнить вона будь-яку гілку командами з іншої гілки при злитті чи чи залишиться вона чистою. Раніше я використовував ребауз, але, здається, закінчується гілка і передає всі комітети майстру, або я зробив це неправильно. Дякуємо за надану допомогу.

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

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

тоді, коли ви будете готові поставити mobiledevicesпідтримку в майстер, спочатку об'єднайтеся в master, як вище, потім ...

git checkout master
git merge mobiledevicesupport
git push origin master

і це все.

припущення тут полягає в тому, що mobilexxx - це тематична галузь, яка ще не готова перейти до вашої основної галузі. Тож зливайтеся в майстер лише тоді, коли мобільний пристрій підтримує в хорошому місці

Всякий раз , коли ви хочете , щоб отримати зміни від майстра у вашій робочої гілки, робити 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

Аналогічно ви також можете об'єднати майстер у мобільному пристрої підтримки.

Q. Якщо перехресне злиття є проблемою чи ні.

А. Ну, це залежить від доручень, зроблених у мобільній * гілці та головній гілці від останнього часу, коли вони були синхронізовані. Візьмемо цей приклад. Після останньої синхронізації з цими гілками трапляються наступні коміти

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

Тепер припустимо, що команда B внесла деякі зміни у файл a.txt, а команда 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. Це не дає змоги і просить вас злитися. У цьому випадку відбудеться новий коміт, який відповідає за вирішення конфліктів у a.txt.

Отже, лінія "Знизу" є крос-об'єднанням - це не проблема, і в кінцевому підсумку ви повинні це зробити, і саме це означає синхронізацію. Переконайтеся, що ви забруднили руки в об'єднанні гілок, перш ніж робити щось на виробництві.

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

1 git fetchіз вашої гілки функцій (переконайтесь, що галузь функцій, над якою ви працюєте, оновлена ​​на сьогодні)

2 git rebase origin/develop

3 якщо виникне якийсь конфлікт, вирішіть їх по черзі

4 використовуйте git rebase --continueпісля вирішення всіх конфліктів

5 git push --force

Ви думаєте в правильному напрямку. Постійно об’єднуйте майстер з мобільним пристроєм, підтримуйте мобільний пристрій і підтримуйте його, коли мобільний пристрій стабільний. Кожен розробник матиме власну філію і може зливатися на майстер або з мобільних пристроїв, що підтримуються, залежно від їх ролі.