0

最近、GIT-SVN ブリッジについて多くのことを読んで、自分で試してみましたが、どういうわけか、物事が荒くなると失敗します。

環境 私たちは 2 つのチームです。一方は SVN を使用し、もう一方は Rebel で GIT を使用します。同期するために、2 つのリポジトリ間にブリッジを作成しました。SVN チームには x 人の開発者が 1 日に 10 回プッシュし、ほとんどが赤いビルドを持っています。GIT チームには 6 人の開発者がいて、週に 1 回だけフェッチするか、コミットするものがあるときにビルドをほとんどグリーンに保ちたいと考えています。

ユースケース: 「ブリッジ」は (まだ) 自動化されていないため、自分のコンピューター上にあるため、ブランチをマージして正しくコミットする責任があります。そのため、GIT チームは 2 つに分かれています。一部はブランチ「branch1」で作業し、残りは「branch2」で作業しています。それらは常にペアで機能するため、「branch1」が完了すると、次のタスクのために別のブランチを作成します。

私がやろうとしたこと: 明確にするために、「masterSpace」というマスターからブランチを作成しました。私は毎朝 master で git-svn rebase を実行し、変更を masterSpace にマージします。開発者は、必要に応じて、開発者が何かをコミットする場所で、masterSpace の「branch1」から作成します。それらが完了したら、SVN ですべてをコミットする必要があります。私はこのようにしてみました

merge "branch1" into "masterSpace".
checkout master
git svn rebase
git rebase masterSpace
git dcommit
git checkout masterSpace
merge "master" into "masterSpace".

次に、開発者はこの masterSpace からすべてを最新の状態にして新しいブランチを作成し、プロセスを繰り返します。

問題: 単一のコミットを持つブランチでこれを試してみましたが、うまく機能しましたが、2 週間ほどの作業の後、状況が悪化し、ワークフローが失敗しました。私が decommit した後、同じコミットが master と "masterSpace" で異なる ID を持っていたので、次に decommit しようとしたときに、多くの競合が発生しました。master を masterSpace にマージした後でも。次のような簡単なシナリオも試しました。

 I have a "branchX" with changes
 I merge them on "masterSpace"
 rebase them on master and finally dcommit them.
 Then I made a single change on "masterSpace" 
 I rebased it into "master"

この後、私は 10 コミット先のようでした (前のコミットの ID のためだと思います)。だから...行き止まり

Q1: 解決策は? GIT チームと SVN チームの両方が同期して平和的に作業できるように、環境とユースケースの正しいワークフローは何でしょうか? 「masterSpace」は冗長で、思ったように動作しないと判断しました。それでも、チームが時間やコードを無駄にしないように、dcommit の迅速な解決策を見つけなければなりません。役立つ情報: ブランチは約 2 週間ごとに変更されます。終了したら、使用したブランチを破棄して、マスターから別のブランチを作成できます

Q2: すべてを自動的に作成する方法は? 近い将来、「橋」を Jenkins に移す予定です。自動的に機能させるための解決策を見つけることは可能でしょうか? 「jenkinsbranch」のブランチをマージするようなもの。Jenkins はこのブランチを自動的にビルドします。緑色の場合はコミットしません。そうでない場合は、ビルドを修正する別のプッシュを待ちます。

私の最初のシナリオでは、「masterSpace」をジェンキンの「マスター」として使用する予定でした。開発者は自分のブランチを「masterSpace」にマージし、jenkins は svn-rebase を作成して自動的にビルドし、緑色の場合はすべての変更を dcommit します。それ以外の場合は、開発者がビルドを修正するのを待ちます。でも…どうやら私が間違っていたようです。

TL:DR チームが 2 つの異なるブランチで数週間作業し、SVN でコミットを解除したい (そして SVN と同期したい) 場合、通常のワークフローはどうなりますか?

4

1 に答える 1

0

私はそのような環境で git-svn を使用して作業しましたが、変更/競合の割合が両側で高い場合、同期をスムーズにするのは難しいと言えます。あなたのセットアップでは、 SubGitが彼らが主張するほど優れているかどうかを調べようとします。

git-svn に固執する場合、作業を楽にする可能性のあるいくつかのテクニックを以下に示します。

  • マージを避け、どこでもリベースを使用するようにしてください。ワーキングブランチを含む。masterSpaceQ3 への回答 - orに対して作業ブランチの定期的なリベースを行いますmaster。
  • masterSpace同期の便宜上、あなたを分けておきます。私の場合master、svnブランチがsvnプレフィックスを使用する場所で呼び出しましたsvn/trunk。他のミラー化された svn ブランチについても同様です。私は自分のネーミングをさらに使用します。
  • masterにリベースしませんsvn/trunk。svn/trunk代わりに、変更がある場合は、まず to から変更をリベースしmasterます。この時点で、 を に技術的にマージsvn/trunkしmasterます。これらのリビジョンの状態は同じである必要があります ( をチェックしてくださいgit diff svn/trunk master)。したがって、マージの競合が発生した場合に備えて-s ours、 とマージしてください。これmasterは に等しくなりsvn/trunk、git はテクニカル マージを介してこれを認識します。マージされる作業ブランチからの変更を の先頭にリベースし、それらの変更 ( ) をmaster実行し、結果の HEAD を分離して、次のことを行います。にコミットします。この段階で、mastergit push . HEAD:mastermastersvn/trunksvn/trunkmastersvn dcommit により、内容は同じですがリビジョンが異なります。ここでも、対等点を示すために tosvn/trunkの技術的なマージを行います。master
于 2015-03-24T18:42:31.493 に答える