3

プロジェクトを git(hub) でフォークし、フォークでいくつかのパッチを維持しながら、リリース (タグ) とリリース ブランチでそれらのパッチを再作成したいと考えています。

初期リポジトリ構造

アップストリームの構造は非常に単純です。

origin/trunk A---B---D---F---H---...
                  \
origin/0.9         C---E---G---...
                       |
                   (tag 0.9)

問題

アップストリーム プロジェクトはコミットで依存関係のバージョンを増やしましたがA、Dそれらは主に利便性のためであり、しばらくの間互換性リリースを維持できると確信しています。

機能ブランチを作成し、コミット用のパッチを作成するために使用trunk_compatし、必要に応じてパッチを作成しました。これを分岐させましたgit revert --no-commitADorigin/trunk

mine/trunk_compat              A*---D*
                              / 
origin/trunk A---B---D---F---H-...
                  \
origin/0.9         C---E---G---...
                       |
                   (tag 0.9)

origin/trunkそのため、これを公開するかどうかに応じてリベースまたはマージすることで、パッチを追跡および維持することが非常に簡単になりました。

私たちの目標は、両方のブランチ (trunkと) のこれらのパッチを維持し、 (からタグ付けされているため0.9) のリリース バージョンを再作成することです。0.9E

そして、私はこれを適切に行う方法に途方に暮れています。

  • それまでのすべてのコミットだけでなく、パッチも含む0.9_compatブランチが必要なので、それを継続的インテグレーション サーバーに入れ、それが機能するかどうかを確認できます。GA*D*
  • withとapplied 0.9_compatの状態のタグが必要です。EA*D*
    • さらに複雑にするために、コミットは実際にはブランチへのEバックポートであるため、ここにもパッチを適用する必要がありますD0.9D*
    • アップストリーム プロジェクトは SVN にあり、これはフォークしている git-svn ミラーであるため、これは適切なマージまたはリベースではありません。
  • 将来、アップストリームはブランチ0.10などになり、それらのブランチにもパッチを維持したいと考えています。

私はチェリーピッキングをたくさんするか、手動でパッチを適用するだけでこれを行うことができますが（私は思う）、それは正しくないと感じており、gitを最大限に活用していないと思います.

4

1 に答える 1

1

これを行うには 2 つの方法があり、それらを正しく取得しました。リベース (cherry-pick と patch を含み、最終的には同じ結果) またはマージです。

  1. パッチを適用する必要があるすべてのブランチをセットアップし、パッチ (origin/trunkおよびorigin/0.9_compat) を適用します。
  2. 枝にパッチを適用する
  3. 違いは、これらのブランチの(マージ) 対(リベース)である維持戦略のみです。git pullgit pull --rebase

戦略の違いは、 の場合git pull、git はリモートの変更をローカル ブランチにマージしようとし (その結果、多くの git マージ コミットが発生しますが、パッチ sha は同じままになります)、git pull --rebasegit の場合は最初にリモートの変更を取得します。そして、ローカルの変更を一番上に適用しようとします（その結果、プルするたびにパッチが変更されます）。rebase の方が適切であると主張します (リモート リポジトリが元々 git である場合、この議論はより強力です)。なぜなら、不必要なマージ コミットの混乱を招くことなく、常にプロジェクトの HEAD + パッチにとどまるからです。

于 2012-11-22T03:01:00.803 に答える