2

かなりのアクティビティを伴うプロジェクトの「マスター」ブランチに続く重要な機能ブランチに取り組んでいるとしましょう。これにより、正気を保つために、何かを機能させる方法を理解するために、「頭」から少し遅れる必要があるという状況に日常的に陥ります。

これは、多くの場合、私のブランチがマスター ブランチよりも数千コミット遅れている状況につながります。関連するモジュールのリファクタリングなど、必要なすべての楽しいことが伴います。「追いつく」ことを開始すると決めたら、これはトリッキーなタスクを残します: モノリシックなマージは問題外です:

  1. すべての「自分の」変更にすべての「マスター」の変更を同時に掛け合わせることは、事実上不可能です。これを数回試したところ、非常に多くの間違いを犯したため、最終的に取り消さなければなりませんでした。

  2. その結果、マージは非常に巨大になり、その中に隠されたすべての魔法がドキュメンテーションの悪夢となるでしょう。

その結果、私がたどり着いたアプローチは、「段階的な」マージを行うことです。マスターと直接マージする代わりに、マスターの履歴の「興味深い」ポイントと選択的にマージします。これは通常、「トリッキーな」競合が発生する可能性があるモジュールに関するコミットです。これの大きな利点は、推論してテストできる実際の構築可能な中間点があるため、プロセス全体がはるかに管理しやすくなることです。

しかし、このアプローチには欠点があるようです...つまり、マージに間違いがあった場合、後で気付くだけです。履歴に修正を押し込むために使用git rebase -i -pしてみましたが、これは背後にいる人々が想定していたような使用法ではないようであるという難しい方法が見つかりました。具体的には

  • マージの間に変更を挿入すると、多かれ少なかれ複雑な競合でリベース プロセスが救済されるようです。

  • 通常のコミットをマージコミットに押しつぶすと、新しいコミットが非マージになり、マージされたコミットへの参照が失われるようです

現在、多かれ少なかれ派手なシェルスクリプトを使用してこれらすべてを回避する途中ですが、この状況に対処するのに役立つGit機能の一部を見逃していないかどうか真剣に考えています. これまでに思いついた最良のアイデアは、 rerere を使用してすべてのマージを手動でやり直すことです。

4

3 に答える 3

1

トピック ブランチを master にリベースすると、より簡単で管理しやすいプロセスになることがわかりました。

だからこれの代わりに

A--B--C--D--E--F--M
       \         /
        X--Y--Z-

これを行う

 A--B--C--D--E--F
                 \
                  X'--Y'--Z'

参照

于 2013-01-18T19:06:26.957 に答える
0

git rebase適切に行われれば、驚くべき機能です。

あなたがあなたのケースで試したかどうかはわかりませんが、私がすることは次のとおりです。

マスターブランチをチェックアウトして、オリジンで最新であることを確認してください。機能ブランチをチェックアウトする git rebase master

コンフリクトがある場合は、進行中にコンフリクトを修正できるようになり、奇妙なことに遭遇した場合はいつでもできるようになります。git rebase --abort

問題が発生した場合、ファイルを修正してから実行すると、リベースはその仕事を続けますgit add <some file>。git rebase --continue

機能ブランチがリモートにプッシュされ、他の人が作業している場合は、リベースを使用しないようにしてください。

于 2013-01-18T19:18:33.213 に答える