3

リポジトリA：リビジョンでプロジェクトのSVNからgitに移行されましたr：SVNの履歴、タグなどのすべてを含むすべてのクローンを作成しました。その後、gitで少し開発しました。

リポジトリB：同じプロジェクトですが、リビジョンでSVNから独立して移行されましたr+small_number。最新のスナップショットのみがgitに取り込まれました。その後、多くの独立した開発が行われました。

ここで、AをBにマージしました。SVNは破棄さdevelopれ、GitHub上のプロジェクトのリポジトリのブランチで開発が続行されるという考えです。私は単純なマージを使用して仕事をしました。ありがたいことに、実際の競合はほとんどありませんでした。開発は主にさまざまな分野で行われましたが、マージ後はgitとは関係なく、多くのクリーンアップが行われました。

しかし、今、たとえばマージgit rebase -i HEAD~2された結果を実行すると、最後の2つのコミットをリベースできるはずですが、300以上のコミットのページが表示されます。これは、SVNのリビジョン1以降のプロジェクトの完全な履歴です。私はさらに混乱することを恐れてリベースを中止しました（明らかに私は完全なGit初心者です）。

その結果は期待されていますか？それは望ましいですか？そうでない場合、それを修正する方法は？

すべての単体テストなどに合格し、ファイル自体は問題ないことに注意してください。gitメタデータ/履歴に何が起こったのか理解できません。

編集：これは私が*思う*リポジトリが今のように見えるものです：

          r         A
... o --- o --- ... o 
                     \ 
               B      \    
    o --- .... o ----  o --- ... o 
   r+small_number      C         HEAD
4

1 に答える 1

8

この動作は、マージコミットをリベースしようとしているために発生すると思います。

次の答えでは、あなたの履歴は次のようになっていると思います。つまり、リポジトリAとBは完全に独立しています。

          r         A
... o --- o --- ... o

o ... o
r'    B

何を達成しようとしているのか自問する必要がありますか？したがって、AとBの両方の変更を含む新しいブランチCが必要です。ここでの優先順位は何ですか？適切な歴史を達成したいですか。r'SVN履歴を失ったという事実を修正しますか？または、AとBのgit履歴を変更しないようにすることが重要ですか？

私の答えは、あなたが前者を達成したいと思っていると仮定するつもりです。AとBはどちらもSVNリポジトリの非常に類似したバージョンから派生しているため、共通の履歴をマージする前に、共通のgitベースを提供することをお勧めします。したがって、理想的には、マージする前に次のような状況になります。

          r          A
... o --- o --- .... o
           \
            \
             o --- .... o
       r+small_number   B

現時点では、これを実現するための最善の方法はわかりませんが、試してみることができますgit rebase -p --onto r --root B。

git merge次に、AとBだけで、履歴を取得できます。

          r          A     C
... o --- o --- .... o --- o
           \              /
            \            /
             o --- .... o
       r+small_number   B

ここで、Cにはすべての変更が含まれています。私はおそらくそれをそのままにしておきます。それ以上のリベースなし。

于 2011-03-18T13:41:58.400 に答える