3

この内部プロジェクトは、内部 Git-repositoryAにあり、外部 Git-repository の外部ライブラリのコードの大部分を追加して適応させる必要がありましたB。B の全履歴は追加しませんでした。現在のすべてのコード ( と呼びましょうB3) を 1 つのコミット ( と呼びましょう) に追加し、A5_B3'明示的に を参照するコミット メッセージを追加しましたB3。次に、追加のコミットで不要なものをすべて削除し、次のコミットで必要に応じてコードを調整しました。

A1 - A2 - A3 - A4 - A5_B3' - A6 - A7
                    /*
        B1 - B2 - B3

"/*" = copy/cherry-pick/... (no 'real' reference/merge-point)

数か月後 (および への多くのコミットA)、外部の Git-repository からの更新が必要ですB。私はリモート B を追加しましたが、B は途中で履歴なしで追加されたため、もちろん共通の祖先は検出されませんでした。しかし、 を使用して 2 つの SHA を並べる記述graftを見つけたので、コードBが「等しい」(B3とA5_B3') であるポイントを並べることができました。Bからへの変更をAローカル リポジトリにマージすることもできました( A18_B6'):

A1 - A2 - A3 - A4 - A5_B3' - A6 - A7 - ... - A17 - A18_B6'
                    /*                            /
        B1 - B2 - B3     -  B4     -  B5     -  B6

しかし、このマージを自分のリモート リポジトリにプッシュできないことが判明しましたA。（編集：私が得たエラーは でした[remote rejected] master -> master (n/a (unpacker error))。）考えてみると、それはもっともらしいかもしれません。なぜなら、私のリモートリモートリポジトリは について知らないので、おそらく、およびBを見つける/追加する方法/場所を知らないからです。B4B5B6

B( B4, B5, )から変更を選択して、B6に追加することもできA17ます。しかし、そうすれば、からの明示的なマージはありませんがB、もちろん、コミット メッセージを適応させることはできます。（私が始めたところから明示的なマージはありませんでしB3た。それに戻ります。）

A1 - A2 - A3 - A4 - A5_B3' - A6 - A7 - ... - A17 - A18_B4' - A19_B5' - A20_B6'
                    /*                             /*        /*        /*
        B1 - B2 - B3                          -  B4     -  B5      -  B6

私が今思いつくことができる唯一の「解決策」は、別の「A_B-branch 」を追加することですA5（明示的に を参照するブランチ名を使用）、そのブランチの（、、B）からの変更をチェリーピックし、そのブランチをマージします時々入ります。BB4B5B6A

A1 - A2 - A3 - A4 - A5_B3' - A6 - A7 - ... - A17 - A18_B6'
                      /                             /
                    AB3'  -  AB4'   -  AB5'    -  AB6'
                   /*        /*        /*        /*
        B1 - B2 - B3     -  B4     -  B5     -  B6

その間、別の外部 Git-repository から別の外部ライブラリのコードの小さな部分も追加しましたC。これはおそらくバグ修正を取得するため、問題が2倍になる可能性さえあります...

私の質問は次のとおりです。

  • 最初からやり直すことができる場合、B (および C) (の一部) を追加するためのベスト プラクティスは何でしたか
  • A_B現在の状況を考えると、チェリーピックを使用したこの「-branch」以外の/より良い解決策はありますか

（これが重複していたらすみません。似たようなものを探してみました。「完全な」共通の歴史を持つプロジェクト/フォークをマージすることについて多くの回答を見つけました。そして、単一のマージが必要な同様のプロジェクトについていくつかの回答を見つけました。しかし、私は推測します後でバグ修正を追加する必要があるかもしれませんが、検索する適切な Git 用語/キーワードが不足している可能性があります。)

4

1 に答える 1

0

まず、エラーはマージとは関係ありません。私はそのようなエラーは一度もありませんでした。これ以上のコンテキストがなければ、これは私が見つけることができる最高のものです: git: can't push (unpacker error) related to permission issues

履歴の書き換えが原因で、または履歴がサーバーよりも古い場合、「サーバー」にプッシュすることはできません (git には実際にはサーバーがありません) 。それで全部です。serverからプルし、マージに成功し、すべて「アトミックに」(他の誰もserverに触れていない) プッシュした場合、問題なく動作します。

ですから、もし私があなたの立場にあり、その問題を押し付けていたら、最初からやり直すときに、その問題が何であるかを確認して先に進みます。合併戦略に問題はありません。

また、チェリーピッキングは避けてください。私の経験からすると、それがどこから来たのか参照を保存しないため、通常は悪いことです (おそらく、私が知らない方法があるかもしれません)。しかし、まれに、それが役立つ場合もあります。次に、そのコミットに「チェリーピック」を書き込むか、どこから来たかを追加します（繰り返しますが、より良いアプローチがあるかもしれませんが、とにかくめったにしないので、それほど気にしません）。1 つ確かなことは、チェリー ピッキングをやりすぎている場合は、git のやり方が間違っているということです。基本に戻る。

于 2013-07-23T16:39:34.870 に答える