git-svn を試してみようと思ったのは、マージとブランチが簡単にできるからです。そこで、man git-svn(1) に次のように書かれていることに気付きました。
dcommit を実行する予定のブランチで git-merge または git-pull を実行することは推奨されません。Subversion はマージを合理的または有用な方法で表さないため、Subversion を使用するユーザーは、行ったマージを確認できません。さらに、SVN ブランチのミラーである git ブランチからマージまたはプルすると、dcommit が間違ったブランチにコミットする可能性があります。
これは、svn/trunk (またはブランチ) からローカル ブランチを作成し、ハックして svn/trunk にマージし、その後 dcommit することができないことを意味しますか? svn ユーザーは、svn 1.5.x 以前のマージで常に発生していたのと同じ混乱を経験することになるのは理解していますが、他に欠点はありますか? 最後の文も心配です。人々は日常的にこのようなことを行っているのでしょうか?
ベストアンサー1
実際、git merge のオプションを使用してさらに優れた方法を見つけました--no-ff。以前使用していたこの squash テクニックはすべて不要になりました。
新しいワークフローは次のようになります。
私が dcommit し、SVN リポジトリをクローンする唯一のブランチである「master」ブランチがあります (
-sリポジトリに標準の SVN レイアウトtrunk/、、branches/およびがあると仮定しますtags/)。git svn clone [-s] <svn-url>私はローカルブランチ「work」で作業します（
-bブランチ「work」を作成します）git checkout -b work「作業」ブランチにローカルでコミットします（
-sコミットメッセージを承認するため）。この後、3つのローカルコミットを行ったと仮定します。... (work)$> git commit -s -m "msg 1" ... (work)$> git commit -s -m "msg 2" ... (work)$> git commit -s -m "msg 3"
SVNサーバーにコミットしたい場合
[最終的には] SVN サーバーにコミットしたくない変更を隠します (コンパイルを高速化し、特定の機能に集中したいという理由だけで、メイン ファイルのコードにコメントを付けることがよくあります)
(work)$> git stashマスターブランチをSVNリポジトリでリベースする（SVNサーバーから更新するため）
(work)$> git checkout master (master)$> git svn rebase作業ブランチに戻り、マスターでリベースする
(master)$> git checkout work (work)$> git rebase masterたとえば、次のものを使用してすべてが正常であることを確認します。
(work)$> git log --graph --oneline --decorate--no-ffさて、この素晴らしいオプションを使用して、「work」ブランチの3つのコミットすべてを「master」にマージします。(work)$> git checkout master (master)$> git merge --no-ff workログのステータスを確認できます:
(master)$> git log --graph --oneline --decorate * 56a779b (work, master) Merge branch 'work' |\ | * af6f7ae msg 3 | * 8750643 msg 2 | * 08464ae msg 1 |/ * 21e20fa (git-svn) last svn commitここで、おそらく
amendSVNの担当者のために最後のコミットを編集する（ ）必要があるでしょう（そうしないと、「ブランチ 'work' をマージ」というメッセージを含む単一のコミットしか表示されません）。(master)$> git commit --amend最後にSVNサーバーにコミットします
(master)$> git svn dcommit仕事に戻り、最終的に保存したファイルを回復します。
(master)$> git checkout work (work)$> git stash pop