次のシナリオで共有 git リポジトリからプルしているときに、コードの競合が繰り返されることに直面しています。
共通のsvnリポジトリがあります
git-svn ブリッジを使用して、この共通の svn リポジトリを独自のローカル git リポジトリと追跡/同期する開発者が何人かいます (git svn rebase/dcommit 経由)。
時々、git を使用するこれらの開発者は、svn リポジトリに影響を与えずに変更を共有する必要があります。この目的のために、共有 git リポジトリをセットアップし、プル/プッシュ コマンドを使用して作業を交換します。
これらの開発者は、メインの svn リポジトリとの同期に「git svn rebase」を使用しているため、競合の問題に直面する可能性があることが判明しました。これは、リベース操作によってローカル git ブランチの履歴が書き換えられ、共有 git リポジトリにプッシュできなくなり、そこからプルすると競合が発生することが多いために発生します。
同じ問題を抱えている人はいますか？
git-svn(1)言います:
簡素化と機能の劣るシステム (SVN) との相互運用のために、すべての git-svn ユーザーが SVN サーバーから直接クローン、フェッチ、dcommit し、すべての git-clone/pull/merge/push 操作を避けることをお勧めします。 git リポジトリとブランチの間。git ブランチとユーザーの間でコードを交換するための推奨される方法は、git-format-patch と git-am、または単に SVN リポジトリに 'dcommit' することです。
状況が許せば、SVN リポジトリのブランチ (つまりサブディレクトリ) を使用して、他の開発者から自分の作業を分離することができます。
私が見つけたのは、git-svn の変更をさまざまな git ブランチに、およびそれらの間でマージしてもまったく問題ないということです。git-svn の問題が始まるポイントは、これらの変更を svn (または、dcommit する git ブランチ) にマージすることです。これらの問題のほとんどは、変更を svn に手動で (たとえば によって) マージすると防ぐことができるように思えますgit diff | patch。これにより、マージしたものから履歴が削除されますが、Subversion ユーザーはこれに慣れているため、大したことではありません。