gitブランチをマスターと同期させる方法

gitが頭に浮かんでいる現時点では、次の最善の解決策を思い付くことができません。

masterとmobiledevicesupportの 2つのブランチがあります。mobiledevicesupportが安定している場合は常に、masterdeviceブランチとマージ/同期される継続的なブランチとしてmobiledevicesupportを保持したいと思います。これにより、mobiledevicesupportからmasterへの変更がマージされますが、masterからmobiledevicesupportへのすべての変更も反映されるため、ブランチは引き続き作業でき、機能は改善または修正されます。これは、中央リポジトリと複数の開発者と連携する必要があります。

他のユーザーが使用している同様のワークフローの例をご覧ください。または、このアイデアが愚かで他のオプションを検討する必要があるかどうかを教えてください。現時点ではワークフローは適切に思えますが、どうすればこのようにgitを機能させることができるのかわかりません。

ありがとうございます。

更新1：マスターをmobiledevicesupportにマージし、モバイルデバイスのサポートをマスターにマージする場合、両方のブランチでコミットを複製しますか？または、ブランチAからブランチBに最新の変更をプルし、マージコミットCをブランチBに追加し、ブランチBからブランチAに最新の変更をプルし、マージコミットDをブランチに追加するのに十分なgit smartです。 A？

画像を投稿するつもりでしたが、評判が足りなかったので、次のイラストでやっていこうと思います。2つのブランチが連続して実行され、マージはしばしば両方向に進みます。私が確信していない重要なことは、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

モバイルデバイスのサポートをマスターと同期させる

次に、mobiledevicesupportをマスターに入れる準備ができたら、最初に上記のようにマスターにマージし、次に...

git checkout master
git merge mobiledevicesupport
git push origin master

以上です。

ここでの前提は、mobilexxxがメインブランチに入る準備がまだ整っていない作業を含むトピックブランチであるということです。したがって、mobiledevicesupportが適切な場所にある場合にのみマスターにマージします

変更をマスターから作業ブランチに取得したいときはいつでも、を実行してください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

ええ、私はあなたのアプローチに同意します。mobiledevicesupportをマスターにマージするには、次を使用できます

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

同様に、mobiledevicesupportでマスターをマージすることもできます。

Q.クロスマージが問題かどうか。

A.ええ、それは最後に同期されたときからmobile *ブランチとmasterブランチで行われたコミットに依存します。この例を見てください：最後の同期の後、次のコミットがこれらのブランチに起こります

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.

現在、2種類のマージが可能です

1. 早送りマージ
2. 真のマージ（手作業が必要）

Gitは最初にFFをマージしようとし、競合が見つかればgitで解決できません。マージに失敗し、マージするように求められます。この場合、a.txtの競合を解決する新しいコミットが発生します。

つまり、結論としては、クロスマージは問題ではなく、最終的にはそれを行わなければならず、それが同期の意味です。本番環境で何かを行う前に、マージするブランチで手を汚してください。

git mergeを介して受け入れられた答えは仕事を完了しますが、厄介なコミットの履歴を残します、正しい方法は次の手順で「リベース」する必要があります（PRの前に最後のプッシュを行う前に、機能ブランチをsycnに保持したい場合を想定） ）。

git fetch機能ブランチから1 つ（作業中の機能ブランチが最新のものであることを確認してください）

2 git rebase origin/develop

3矛盾が生じた場合は、1つずつ解決する

4 git rebase --continueすべての競合が処理されたら使用する

5 git push --force

あなたは正しい方向に考えています。マスターをmobiledevicesupportと継続的にマージし、mobiledevicesupportが安定しているときにmobiledevicesupportをマスターとマージします。各開発者には独自のブランチがあり、その役割に応じて、masterまたはmobiledevicesupportとの間でマージできます。