1

私はgitブランチでさまざまな機能の開発を行っています。git-svnを介してコードをSVNにチェックインする場合は、次のようにします。

git co feature_branch
git svn rebase
git co master
git svn rebase
git merge --no-ff feature_branch
git commit --amend
git svn dcommit

このプロセス中に別の開発者がSVNにコミットしない限り、これはかなりうまく機能します。その場合は、次のいずれかです。

  • feature_branchとmasterをリベースする時間の間にSVNコミットが行われると、次のようなログが表示されます。

*   4e6992a BUG-003 My SVN commit (containing cdb40ba and 3b18ea4)
|\
| * cdb40ba local commit 1
| * 3b18ea4 local commit 2
* | cf8a028 BUG-002 Another developer's SVN commit
|/
* 940c613 BUG-001 Another developer's SVN commit

  • マスターをリベースしてからの間にSVNコミットが行われるとsvn dcommit、マージの問題が原因で後者が失敗します（この場合、ハードリセットを実行して最初からやり直します）

単一の不可分操作でこれをどのように達成できますか？

4

2 に答える 2

3

この問題は、SVNの動作方法が原因で、git-svnでは解決できないと思います（各リビジョンの作成は個別のトランザクションですが、複数のリビジョンを作成するトランザクションを作成できます）。SVNロックを使用して解決できるかもしれませんが、このアプローチには欠点があります。

Pure Gitは、必要に応じて、すべての履歴をアトミック操作としてまとめます。SVNリポジトリにアクセスできる場合は、SubGitをインストールして、SVNリポジトリ用に作成するGitインターフェース（git-svnではなく純粋なGitインターフェース）を使用できます。

于 2012-06-16T09:51:59.473 に答える
0

とマージする理由については説明しません--no-ff。それは常にマージコミットを生成します、そしてあなたの最初の弾丸の私の理解はあなたがそれをしないことを望んでいるということです。

単一の不可分操作で常にそれを行う方法はありません。特に、2番目の弾丸はかなり避けられませんが、修正するために最初に戻る必要はないと思います。

これが私がそれをする方法です：

  1. Subversionにプッシュしたいコミットを含むブランチをチェックしてください：git checkout feature_branch。

  2. 何をコミットしているのか、どこにコミットしているのかを確認してくださいgit svn dcommit --dry-run。私は通常、プッシュされるコミットの数を健全性チェックし、それらが正しいSubversionブランチにコミットされていることを確認します。

  3. マージの問題が発生する可能性が高いと思われる場合は、git svn rebase。ただし、通常はこれを気にせず、手順4でエラーが発生した場合にのみ実行します。

  4. 変更をプッシュします：git svn dcommit。問題が発生した場合は、手順3に戻ります。

「マスター」ブランチは一切関与しないことに注意してください。これにより、私が行う必要のあるマージの量が大幅に削減されます。したがって、ステップ3と4の間で、他の誰かのコミットが自分のコミットの邪魔になる可能性があります。

于 2012-06-18T09:03:36.920 に答える