6

目的: アップストリーム プロジェクトの以前のリリースにカスタム パッチを作成する必要があり、それらのパッチを新しいバージョンに適用できるようにしたいと考えています。

問題: メンテナンス ブランチから新しいバージョンにリベースすると、メンテナンス ブランチで変更されていないファイルと競合が発生します。

疑い: 私が達成しようとしていることに間違ってマージまたはリベースを適用しています。

例: これは私が達成したいことの論理的な例ですが、タグ付けされたリリース v1.0 と v2.0 の間のコミット履歴は、その間に何百ものコミットになる可能性があることを理解してください。

複数のタグ付きリリース (v1.0 および v2.0) を持つアップストリーム リポジトリをフォークし、マスター コミット履歴 A から D までを使用します。B はタグ v1.0 での最後のコミットです。C は、タグ v2.0 での最後のコミットです。D は開発中です。

$ git clone git@server:repo

A<--B(v1.0)<--C(v2.0)<--D Master

以前のリリース タグ (v1.0) から分岐して、次のようないくつかのカスタム変更を行います。

$ git checkout v1.0 -b v1.1

     E<--G<--H v1.1
    /
A<--B<--C<--D Master
        \
         F v2.1

私が今やりたいことは、後のリリース タグ (v2.0) から分岐し、v1.1 ブランチ (G' および H') で行ったパッチ コミットを v2.0 ブランチに適用することです。v1.0 で行った個々のコミットを v2.0 ログに保存する必要があります。

     E<--G<--H v1.1
    /
A<--B<--C<--D Master
        \
         F<--G'<--H' v2.1

質問: これらの変更を適用して競合を回避するための正しいワークフローは何ですか? マージとリベース (--onto を含む) の多くの組み合わせを試しましたが、すべて失敗します。git rebase は、デフォルトで 3 方向のマージを行い、無関係なファイルと競合することを望んでいます。

$ git rebase v2.1 v1.1
Falling back to patching base and 3-way merge
...
Failed to merge in the changes.

$ git checkout v2.1
$ git rebase v1.1
Falling back to patching base and 3-way merge
...
Failed to merge in the changes.
4

2 に答える 2

2

リベースのような細かい制御やマージの容易さはないかもしれませんが、コミットの範囲を渡すことは、git cherry-pick古いブランチで個々の変更を取り、現在のブランチでそれらを再生するのにより適しているようです。

したがって、G と H が最後の 2 つのコミットである場合は、次のv1.1方法でチェリーピックできるはずですv2.0。

git cherry-pick v1.1~1

（またはコミットハッシュを手動で提供する）

すでにこれを試したことがあり、欠点がある場合は、お知らせください。私はまだこの種のワークフローを自分で完成させようとしています:)

于 2013-04-12T15:09:04.713 に答える