私たちの Git プロセスでは、「マスター」は現在のリリース サイクルのトピックおよび修正ブランチの統合ブランチですが、マスターで既に正常にテストされた修正の一部を慎重にバックポートする必要がある「安定した」ブランチも維持しています。
すべての問題は、ブランチがすでに「マスター」にマージされていることです (そうでない場合は、リベース --onto を使用すると非常に簡単です)
- 他の方法でプロセスを変更したくない理由は、a) "stable" ブランチのすべてを修正したくないため、b) "stable" ブランチに変更を加えなければならない場合があるからです。 「マスター」にマージしたい。
- 明らかに、修正を「安定版」ブランチにマージすることはできません。これにより、多くの不要な機能がバックポートされるからです。
私が説明する初期状況のグラフ：
I--J (stable)
/
/
/
- A - B - C - D - E - F - G (master)
\ /
X -- Y (fix/123)
到達したい状況のグラフ:
I--J (stable)
/ \
/ X'- Y' (fix/123-stable)
/
- A - B - C - D - E - F - G (master)
\ /
X -- Y (fix/123)
修正を完了するための複数のマージなど、より複雑なケースも考えられます。
- A - B - C - D - E - F - G - H (master)
\ / /
X - Y ----- Z (fix/123)
ただし、修正ブランチへのマージは許可されていないため、次のようなものは決してありません。
- A - B - C - D - E - F - G (master)
\ \ /
X - Y - Z (fix/123)
これを達成するために、修正ブランチをチェリーピックまたはリベースできます。
1）cherry-pick（通常、gitでコミットをバックポートするにはどうすればよいですか？）：
git checkout -b fix/123-stable stable
git cherry-pick X Y
これは簡単に思えますが、実際の例を扱う場合はそうではありません。いくつかのコミットを忘れたり、間違ったコミットを選択したりするリスクは常にあります!
2) リベース --onto ( https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html ) :
2.a) 「動かない」方法:
git rebase --onto stable master fix/123
fix/123 はすでに master にマージされているため、これは何もしません! 2.b）「チェリーピックよりもはるかに優れていない」方法：
git rebase --onto stable D fix/123
DのSHAを取得する必要があるため（たとえば、Xではなく）、これはまだ危険です。
2.c) 「一時的な開始参照を使用する」方法:
git tag begin D
git rebase --onto stable begin fix/123
git tag -d begin
これにより、以前の状況は改善されます。タグを使用すると、グラフィカル ツールで簡単に実行したりイメージしたりできるようになりますが、依然として多くの手作業が必要です。
3.d) 「マージ前にハード マスターをリセットする」(最初の分岐点まで) うーん、説明するのも実行するのも難しいようです。
したがって、私が探しているのは、git の移植可能な(bash/grep/cut/sed を暗示しない) 方法です。
1）すでに「マスター」にマージされたブランチ（ここではXとY、「マルチマージ」の場合はZ）で行われたすべてのコミットを一覧表示して、簡単にチェリーピックします
2) すでに「マスター」にマージされたブランチの最初のブランチ ポイントのコミットを取得する
2.a) マージは既に (複数回でも) 行われているため、「git merge-base」コマンドではこれを実行できません。
2.b) ここで見つけました Git で分岐点を見つけますか? 次の bash コマンドを少し調整しました。
git rev-list --boundary --date-order --reverse fix/123..master | grep -m 1 - | cut -c2-
しかし、彼はgit easyでも移植可能なコマンドでもありません（つまり、BashまたはCygwinツールなしでは機能しません）
