13

概要: 一連のローカル変更を維持したいアップストリーム リポジトリの長時間実行追跡を処理するためのベスト プラクティスは何ですか?

アップストリームで github のフォークを最新の状態に保ちながら、フォークに固有の変更を明確に追跡できるようにしたい。upstream(この説明では、 がメインのプロジェクト リポジトリをorigin指し、 がリポジトリのフォークを参照していると仮定します)

アップストリーム/マスターがEにあったときにリポジトリをフォークしたこのようなものがあると想像してください.

Upstream:
A-B-C-D-E-F


Fork:    
A-B-C-D-E ----- P ------T
         \-L-M-/ \-Q-R-/

リポジトリをフォークした後、必要な新しい機能を追加するために 2 つの機能ブランチ (LM と QR) を作成し、それらを元のマスターにマージしました。だから今、私のブランチには上流に存在しない改善があります。

アップストリームに興味深い修正がいくつかあることがわかったので、アップストリームと同期を取り戻したいと考えています。私が見つけたほとんどの参照 ( git hub fork )に基づいて、これを行うための推奨される方法は、upstream/master を origin/master にマージし、そのまま続行することです。したがって、次のようなコマンドを発行します。

git checkout master
git fetch upstream
git git merge upstream/master
git push

次に、次のようなリポジトリになります。

Upstream:
A-B-C-D-E-F


Fork:    
A-B-C-D-E ----- P ------T-F'
         \-L-M-/ \-Q-R-/

ただし、これにはいくつかの問題があります。

  1. 私は実際にレポにコミット F を持っていません。同じコンテンツを持つ F' がありますが、ハッシュは異なります。そのため、2 つのリポジトリ間でコミットを簡単に参照できず、変更があることを知ることができません。(アップストリームにおそらく複数の変更があり、マージされた独自の機能ブランチのセットがあることを考慮すると、さらに複雑になります)

  2. 先に進み、これを続けていくと、アップストリームにあるものを超えて、自分のリポジトリにどのような変更があるかを知ることがますます難しくなります。たとえば、これらの変更の一部をアップストリームに送信し、独自の改良を加え続ける場合があります。これを何度か繰り返した後、私のリポジトリを見ている人は、上流との違いをどのように知っていますか? (これらの変更を見つけるための git コマンドはありますか?)

  3. #2 と同様に、アップストリームで修正を見つけて、フォークに修正が含まれているかどうかを確認するにはどうすればよいでしょうか?

問題の根本は、コードとハッシュが同じではないため、リポジトリが特定の時点でアップストリームと「同期」していることを保証する方法がないことだと思います。では、変更を正確に追跡し、物事を同期させようとして気が狂わないようにするにはどうすればよいでしょうか?

注: リベースを使用してリポジトリをアップストリームからリベースし続けることを検討しましたが、これにはまったく異なる一連の問題があります。たとえば、誰かがサブモジュールやブランチなどを介して私のリポジトリを参照すると、履歴の書き換えによって参照が壊れます。さらに、ブランチの履歴がリベース後に存続するとは思わないため、作成したすべての機能ブランチと関連する履歴を完全に把握することはできません。

他の人はこれをどのように処理しますか？検討すべきベストプラクティスは何ですか?

アップデート：

Seth からのフィードバックに基づいて、私が話していることと、それが彼の言うようにどのように機能するかを示すために、一連のテスト リポジトリを作成しました。

リポジトリは次のとおりです。

ローカルの変更もある場合、アップストリームからのマージがどのように見えるかをより明確に示す必要があります。

4

1 に答える 1

13

あなたの仮定は間違っています。git mergeテキストの例で、コマンドを実行すると言いました。あなたが本当にこれを意味していて、そうではない場合git cherry-pick(記録として、git-merge がこの状況でのベスト プラクティスです)、ブランチで F` を取得しない場合、F が取得されます。おそらく画像:

フェッチ後、マージ前のリポジトリは次のようになります。

Upstream:
A-B-C-D-E-F  [master]


Fork:    /-F                  [upstream/master]
A-B-C-D-E ----- P ------T     [master]
         \-L-M-/ \-Q-R-/      [Other branches]

マージ後、リポジトリは次のようになります。

Fork:    /-F-------------\    [upstream/master]
A-B-C-D-E ----- P ------T-U   [master]
         \-L-M-/ \-Q-R-/      [Other branches]

リポジトリの新しいコミット「U」は、コミット「P」および「T」と同様に、マージ コミットになります。

git cherry-pickあなたの例で示したように、「F '」を作成します。そうしないでください。 git rebaseブランチのリベースをサポートできる場合もありますgit rebase -pが、常に機能するとは限りません。また、それは公開履歴を書き換えることであり、これは悪い考えです。

Gitのベスト プラクティスに関するドキュメントが あります。

于 2012-07-13T00:21:51.370 に答える