7

2つのブランチがあるとしましょう

master -- A -   -   -   -   -  - merge
          \                    /
           \- develop -- B -- C

今、私がマージしたいのであれば、それは早送りになりますが、私はそうすべきです

git checkout develop
git merge master

また

git checkout master
git merge develop

そして、私が衝突の可能性がある場合はどうなりますか

master -- A - D -  -  -  -  -  -merge
          \                   /
           \- develop -- B -- C

私は今、開発またはマスターにマージする必要がありますか？これは少し紛らわしいので、良い説明をいただければ幸いです

4

2 に答える 2

6

不足しているワークフロータスク

まず第一に、ワークフローに欠けているものがいくつかあり、実際の方法で質問に答えることが困難になっています。例えば：

  1. ブランチをマージする前に、常にアップストリームからプルする必要があります。他の人は、あなたが説明していない方法で開発またはマスターを変更した可能性があります。

  2. どちらがあなたの長期的な開発ラインであるかを特定していません。開発を想定していますが、マージ後にブランチに何が起こるかを特定していないため、これは単なる推測です。

寿命の長いブランチをリベースするための一般的なベストプラクティス

したがって、事前にブランチを更新し、マスターと開発の両方が長寿命のブランチであり、マスターが完成したコードの「公式」ブランチであると仮定すると、これらの方針に沿って何かを行う必要があります。

  1. 開発に基づいて一時的なリベースブランチを作成します。

    git checkout -b tmp develop

  2. 作業をマスターにリベースして、クリーンな早送りマージを確実にします。私はこれをインタラクティブなリベースにするのが好きですが、好きなようにやってください。例えば：

    git rebase -i master

  3. マスターにマージします。マージを早送りにすることをお勧めしますが、自分に合った方法で実行できます。

    git checkout master
git merge --ff-only tmp

  4. マージされたブランチがきれいにプッシュすることを確認してください。

    git push origin

  5. すべてがうまくいった場合は、一時的なブランチを破棄します。

    git branch -d tmp

  6. 早送りではなく、マージコミットとして開発を使用してマスターを再マージします。これにより、開発をマスターブランチと一致させ、継続的な作業を行うことができます。

    git checkout develop
git merge master
git push origin

自然な結果

これにより、マスターブランチの履歴が比較的直線的になり、マージの競合が発生しなくなり、公開されたブランチを台無しにすることなく、必要に応じてリベースできるようになります。これはすべて前向きなことです。

ただし、マスターから開発への再マージが必ずしも早送りのマージであるとは限らないため、このプロセスでは、開発に複雑なマージ履歴が残る可能性があります。これ自体は問題ではなく、リベースを含むワークフローの自然な結果です。知っておくべきことですが、私の意見では、チームに提供する柔軟性に対して支払う価値のある価格です。

于 2012-07-19T13:57:12.177 に答える
3

2番目を実行し、マスターにいる間にマージします。

私は通常、マスターをオリジンにリベースし、開発者をマスターにリベースしてからマージします。これにより、リベース中に競合が発生します。これを行うと、マージの競合は発生しません。

于 2012-07-19T13:23:10.603 に答える