git-subtree
プロジェクトからディレクトリを抽出するために使用しています。
git subtree split --prefix=src/SubProject --branch=SubProject origin/master
これが最初にプロジェクトを開始したい方法であるとすれば(具体的には no ) 、連続した実行でからへ--rejoin
の変更のみを分割するにはどうすればよいですか?origin/master
SubProject
小規模なプロジェクトの場合、これはうまく機能しています。プロジェクトを分割するのに 5 秒ほどかかります。ただし、大規模なリポジトリでは、これにはかなりの時間がかかる場合があります。分割ごとに最大5分かかることがわかりました。私が取り組みたいプロジェクトの中には、1 つのリポジトリに 45 以上のサブプロジェクトがあるものがあります。
うまくいくかもしれないと思った多くのことを試しましたが、それぞれが何らかの形で失敗しました。私の要件は次のとおりです。
- 決していじって
origin/master
はいけません(そのため、ほとんどの場合--rejoin
、問題外です) - 余分なマージ コミットを追加してはなりません (考えてみてください:
--ff-only
から新しい変更を取得するときorigin/master
) 。 SubProject
リポジトリには安定したコミット ID が必要です。への 1 つまたは複数の増分更新の後SubProject
、この投稿の上部にある元のコマンドを再実行した場合に取得されるのと同じコミット ID が履歴に含まれている必要があります。- 自動化する必要があり、手動による介入は必要ありません
複雑なソリューションを恐れていませんが、自動化する必要があります。履歴の変更による失敗は問題ありません。その時点で、スクリプトはフォールバックして全体をゼロから構築できます。その場合、ユーザーは自分が何をしたかを知っているので、最初から再構築するという非常に長いプロセスを経なければなりません。:)
--再参加
によって追加された変更された履歴のコンテナーになるように、 around--rejoin
の余分なコピーを使用して保持しようとしました。ここで私が遭遇した問題は、介入することも介入することもできなかったことです。自動化された方法でこれを行う必要があるため、これは受け入れられませんでした。origin/master
--rejoin
git rebase origin/master
git merge --ff-only origin/master
マージコミット
思い通りに動作させることができましgit merge origin/master
たが、マージコミットが発生しました。このマージ コミットは上流に行くことはないので、今後の履歴を予測することは不可能git subtree split
であり、元の環境での新しいものは同じ正確な履歴を再現することはできません。私はこれについて間違っている可能性があります。もしそうなら、これがどのように安全になるかを私に説明してください. :)
コミット範囲
コミット範囲を使用して実験したSubProject
ところ、特定の時点からHEAD
. これは、コミット ID の新しいセットを生成するように見える場合を除いて、おそらく機能するため、これはオプションではないと思います。