2個團隊的git-svn bridge的常規工作流程

Question

最近，我讀了很多有關GIT-SVN橋的東西，我自己嘗試了一下，但是當事情變得艱難時，我以某種方式失敗了。

環境我們有2個團隊：一個使用SVN，另一個是反叛者並使用GIT。 為了同步，我在兩個倉庫之間建立了一座橋梁。 SVN團隊有x個開發人員，一天要推送10次，並且大部分都是紅色版本，GIT團隊有6個開發人員，他們只想每周獲取一次，或者在有東西要提交的時候，只獲取一次，以便使構建大部分保持綠色。

用例： “網橋”不是自動化的（還），因此它在我的計算機上，因此我有責任合並分支並正確地提交它們。 因此，GIT團隊分為2個團隊：其中一些在“ branch1”分支工作，其余的在“ branch2”分支工作。 它們始終成對工作，因此當完成“ branch1”時，我們將為下一個任務創建另一個分支。

我試圖做的事情：為了保持清晰，我從master創建了一個分支，稱為“ 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個星期的工作后事情變得很艱難……然后我的工作流失敗了。 取消提交后，相同的提交在master和“ masterSpace”上具有不同的ID，因此下次我嘗試取消提交時，遇到了很多沖突。 即使我將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周更改一次分支。 完成后，我們可以丟棄使用過的分支，並從主分支創建另一個分支。

問題2：如何自動制作所有內容？ 在不久的將來，我計划在詹金斯上移動我的“橋梁”。 是否有可能找到使它自動運行的解決方案？ 類似於在“ jenkinsbranch”上合並分支。 Jenkins自動構建此分支，如果綠色則放棄提交，如果沒有，則等待另一次修復構建的推送

在我的初始方案中，我計划將jenkins上的“ masterSpace”作為“ master”。 開發人員會將其分支合並到“ masterSpace”中，詹金斯將創建一個svn-rebase並自動構建它，如果它為綠色，則放棄所有更改。 否則，它等待開發人員修復構建。 但是...似乎我錯了。

TL：DR如果一個團隊在2個不同的分支上工作幾個星期並希望在SVN中將其提交（並與SVN同步），那么正常的工作流程是什么？

Answer 1

我曾在git-svn的環境中工作過，可以說當雙方的變更/沖突率很高時，很難使同步變得平滑。 在您的設置中，我將嘗試查看SubGit是否像他們聲稱的那樣好。

如果您堅持使用git-svn，可能會使用以下兩項技術使您的生活更輕松：

• 盡量避免合並，並在各處使用rebase。 包括工作分支。 回答第3季度-根據masterSpace或master定期調整工作分支的masterSpace 。
• 為了方便同步，我會將masterSpace分開。 在我的情況下，我稱它為master ，其中svn分支將使用svn前綴，例如svn/trunk 。 對於其他鏡像的svn分支類似。 我將進一步使用我的命名。
• 我不會將master svn/trunk 。 相反，我會先將svn/trunk更改重新設置為master （如果有）。 在這一點上，我將svn/trunk技術合並為master 。 這些修訂的狀態應該是相等的（您可以檢查git diff svn/trunk master ），以防萬一發生合並沖突-只需與-s ours合並，盡管我認為git的最新版本在這種情況下足夠聰明。 現在， master等於svn/trunk和git知道這個通過技術融合，我想變基被合並到頂部從工作分支的變化master ，攜帶master對這些變化（ git push . HEAD:master ） ，從結果master獲取一個分離的HEAD，然后對svn/trunk進行dcommit。 在這一階段，我們將再次獲得svn/trunk和master ，它們具有相同的內容，但由於svn dcommit而具有不同的修訂版。 再次，我將svn/trunk技術合並到master來標記一個平等點。