Git チェリーピック: コミットを別のブランチにコピーして競合を修正する

Git チェリーピックは、コミットによって導入された変更を現在のブランチに適用し、通常は新しいコミットを記録します。 修正を受け取るブランチに切り替え、ソース コミットを検査してから、git cherry-pick <commit> を実行します。ソースブランチはそのまま残ります。パッチが競合する場合は、ファイルを解決して続行するか、操作を中止します。

feature/checkout で支払いのバグが修正されたが、リリース ブランチではその修正だけが必要であると想像してください。機能全体をマージすると、作業が未完成になる可能性があります。このガイドでは、Git と、macOS、Windows、および Linux 用に構築したクライアントである GitTree を使用して修正だけをコピーする方法を説明します。ビジュアル ルートの追加の価値は、変更を適用する前に宛先ブランチとソースの差分をチェックすることです。

チェリーピック vs マージ vs リベース: 操作を選択してください

チェリーピックは、バックポートや、間違ったブランチにコミットされた小さな修正に役立ちます。これは、すべての作業を共有する必要がある 2 つのブランチを繰り返しマージする代わりとしては不十分です。コピーされた変更の追跡が困難になる可能性があります。ブランチ全体のワークフローについては、interactive rebase および コミット グラフ ガイド を参照してください。

コミットを別のブランチにチェリーピックする方法

クリーンな作業ツリーから始めます。未完成の編集をコミットまたは隠します。 stash ガイド では、一時停止と再開のワークフローについて説明しています。修正がリモートにある場合はフェッチし、ソース履歴を検査します。以下のブランチ名とハッシュは例です。既存の宛先ブランチ、ソース ブランチ、および実際の修正ハッシュに置き換えてください。

git status
git fetch origin
git log --oneline origin/feature/checkout
git show abc1234
git switch release/2.x
git status
git cherry-pick -x abc1234
git show --stat HEAD
git status

-x は、クリーンなチェリーピックのメッセージにソース コミット参照を追加します。これは、パブリック バックポートのトレースに役立ちます。リモート追跡参照を更新してフェッチします。チェックアウトしたリリース ブランチは自動的には更新されません。宛先がチームが期待するリビジョンであることを確認します。新しいコミットを確認し、プッシュする前にリリース ブランチのテストを実行します。

親と他のコミットのメタデータが異なるため、選択されたコミットは通常、異なるハッシュを持ちます。オリジナルはソース ブランチに残ります。修正をコピーしても、間違ったブランチから修正が削除されるわけではありません。そのブランチをクリーンアップする方法を決定することは、特に他の人がすでにそのブランチを使用している場合には、別の履歴決定になります。

GitTree をダウンロード して、視覚的なグラフと競合エディターを使用してこのワークフローを実行します。 Cherry-pick は、プライベート リポジトリを含む無料プランに含まれています。現在の公式アプリにサインインし、既存のリポジトリを開いて、既に持っているものと同じ Git 履歴を使用します。

複数のコミットと範囲を厳選する

git cherry-pick abc1234 def5678
# A linear range, including the first commit:
git cherry-pick "abc1234^..def5678"

これらは代替例です。明示的なリストでは、指定された順序でコミットが選択されます。前提条件となる変更を最初に置きます。範囲は、グラフ内で偶然表示された行を選択するのではなく、リビジョン セットのルールに従います。 A..B は A を除外します。 A に親がある場合、A^..B には単純な線形シーケンスの A が含まれます。初心者のバックポートの場合は、マージをまたがる範囲よりも明示的にレビューされたリストを優先します。

チェリーピックの競合を解決して続行する

Git はパッチを適用できない場合、一時停止します。 git status を実行して操作と競合するパスを特定し、目的の結果を編集します。マーカーの例と GitTree の 3 方向エディターについては、競合解決ガイド を使用してください。構文的にクリーンな解決にはまだテストが必要です。宛先では異なる API が使用されている可能性があります。

git status
git diff --name-only --diff-filter=U
# Resolve the file, then check and stage it:
git diff --check
git add -- src/payment.ts
git diff --cached
git cherry-pick --continue

シーケンスは、問題のあるコミットごとに 1 回ずつ、複数回一時停止できます。 Git がピックが空であると言う場合は、変更がすでに存在しているか、または解決策によって変更が削除されているかどうかを調べてください。 git cherry-pick --skip は、そのコミットを意図的に省略する場合にのみ使用してください。これは一般的な競合の修正ではありません。

Git チェリーピックの中止、終了、スキップの比較

コミットのマージ、依存関係の欠落、選択の取り消し

マージ コミットは複数の親に関連する変更を表すため、メインラインの親が必要です。 git cherry-pick -m 1 <merge> を検討する前に、git show --no-patch --pretty=raw <merge> を使用して検査してください。親 1 は普遍的に正しいわけではありません。 GitTree は親を選択するよう求めます。習慣ではなく、比較したい履歴に基づいて選択してください。多くの場合、元の通常の修正コミットを選択する方が簡単です。

コピーされた修正が正しくビルドされない場合は、その前提条件を調べてください。ヘルパー、スキーマ変更、または構成が以前のコミットに存在している可能性があります。 Git 操作が成功した場合は、パッチが適用されたことだけが証明されます。受信ブランチをテストします。共有履歴の完了した選択を元に戻すには、元のソース ハッシュではなく、宛先ブランチで作成された新しいコミットを元に戻します。未公開の作業については、ブランチ履歴を移動する前に、Git の間違いを元に戻す でリセットとリカバリの選択肢を確認してください。