3

私はコードに取り組んでおり、このブログで説明されている状況に似ていることに気づきました。基本的に、完全に異なるコンテナーを使用する 2 つのバージョンのコードがあります。これは、異なるコンテナーを使用した場合のコードの効率を比較するために行われます。私は効率的なコンテナー メンバー関数に依存しているため、コンテナーに関してコードをジェネリックにすることはできません。そのため、最適化されたコード用と最適化されていないコード用の 2 つの git ブランチを持つアプローチを選択しました。

問題は、コードの一部を最適化した後、分岐している 2 つのブランチで共通の作業を行う必要があることです。「上流」(最適化されていない) ブランチで作業を行い、多くの競合を解決することなく、最適化されたブランチへの一般的なコミットを選択することは可能ですか?

オンラインで見つかったチュートリアルに従い、単一のファイル (競合をテストするため) といくつかのブランチを含むダミー リポジトリを作成しました。

このgit リポジトリの例では、競合を解決せずに、ブランチ「second」のコミット「02 second」を master ブランチにチェリーピックすることは可能ですか? 私は紛争の解決に反対するものは何もありませんが、それを回避できるかどうかに興味があります.

この状況での正しいワークフローは何ですか? 一般的な変更、コミット、チェリーピック + 競合の解決を適用する必要がありますか?

4

1 に答える 1

4

コミットはパッチ セットです

チェリーピッキングは本質的に競合を引き起こしません。コミットのアトミック性に大きく関係しています。コミットは、ツリーに適用される一連のパッチと考えてください。パッチが重複していない場合は、免責でチェリー ピッキングを行うことができます。一方、広範囲、重複、または複雑なコミットがある場合、チェリーピックには通常、スムーズに適用できるよりも多くの変更が含まれます。

このことを考慮：

# Patch A
Line one
Line two
Line three

# Patch B
Line one
Line 2
Line three

# Current HEAD
First line
Second line
Third line

この不自然な例 (注: テストはしていません。ポイントを説明するために使用しているだけです) では、A と B の両方を HEAD にチェリーピックしようとしても、変更が重複するため、おそらくきれいに適用されません。一方、次のようなチェリーピッキング：

# Cherry-pick me from another branch!
First line
Second line
Third line
Fourth line

重複がないため、HEAD に競合は発生しません。

明らかに、特定のユースケースは異なる場合がありますが、一般的な経験則では、小規模でアトミックなコミットはチェリーピッキングの機が熟していますが、「泥の大きなボール」コミットは通常問題があります。YMMV。

関連項目

于 2012-08-01T13:26:30.610 に答える