私の典型的なのgit-svnのワークフローは次のとおりです。この時点でなぜgit-svn dcommitは私のgitリポジトリに重複したコミットを残していますか?それを止めることはできますか?
git checkout -b story-xyz
git commit -a -m "work"
git commit -a -m "more work"
git checkout master
git svn fetch
git merge remotes/trunk
git checkout story-xyz
git rebase master (sometimes with -i)
git checkout master
git merge story-xyz
が、私は私のmaster
とstory-xyz
枝が一つ以上が先にremotes/trunk
のコミット、同じコミットを指しています。 remotes/trunk
以降のすべてが1つの線形履歴にあります。
last svn commit [remotes/trunk] <--- work <--- more work [master, story-xyz]
私はその後、私はすべての最新指しremotes/trunk
、master
とstory-xyz
でremotes/trunk
とmaster
間のコミットはSubversionのリビジョンになり、単一の線形の歴史で終わる見込ま
git svn dcommit
を実行しますリビジョンは次のようになります。
last svn commit <--- work <--- more work [master, story-xyz, remotes/trunk]
私のSubversionリビジョンは次のとおりです私は2分岐構造になってしまいます。ブランチの共通ルートは、コミットする前のSubversion HEADです。両方のブランチには、同じdiffが含まれているという意味で、一連のコミットが含まれています。 gitのは、私がgit svn dcommit
を実行する前に持っていたことをコミットし
last svn commit <--- work <--- more work [master, remotes/trunk]
|
\- work <--- more work [story-xyz]
がメッセージをコミット私はgitで、下枝(story-xyz
)にあり、gitの:ブランチstory-xyz
は、他の1つのブランチ、remotes/trunk
とmaster
の頭にありますユーザー名と電子メール、gitコミットタイムスタンプ。上のブランチ上のコミットは新しいgitコミットです。彼らは私のSubversionユーザー名、dcommit
を実行した時のタイムスタンプを使用し、コミットメッセージにはgit-svn-id
フィールドが追加されています。
これはすべて問題なく、作業を続けることができます。問題は、私がgitk
を見て、マージされていないブランチのように見えることです。story-xyz
私がmaster
に合併した物語枝と、私が持っていない物語の違いを伝えるのはかなり難しいです。それを見つける最も明白な方法は、重複コミットメッセージです。私はstory-xyz
ブランチを削除することができましたが、gitを正しく使用していないように感じ、履歴を失ってしまいました。
git-svn
はこれを停止するようなものがありません。あるいはこれは、Subversionとのやりとりがgitの力と自由を薄める方法のほんの一例ですか?
ありがとう、私は今日これを試します。これがマスターの必要性を完全に取り除くように見えるので、リモーツ/トランクの歴史は現在私たちの歴史のメインラインになると思っていますか? –
あなたの場合でも、リモート/トランクの履歴は「メインライン」です。あなたの最後のグラフを見てください。マスターの歴史は、リモート/トランクの歴史と同じです。両方とも "メインライン"としても同じように有効です - リモートはそれが_shared_メインラインであるためです。 完全にマスターを削除する必要はありません。あなたはそれを歴史のいくつかの早い時点でぶら下げておくことができます。その後、たとえばあなたがする必要がある場合。 1つのコミット、あなたはマスターとsvnをチェックアウトすることができます現在の日にそれをrebaseします。 –
はい、それは理にかなっています。私はあまりにも特別なことである「マスター」というアイデアに縛られていたと思う。まだあなたのワークフローを試してみる機会はありませんでしたが、期待どおりに動くなら答えを受け入れるでしょう。 –