將多個活動分支轉換爲GIT存儲庫到GIT

Question

我試圖將我的SVN存儲庫轉換爲GIT存儲庫。 問題在於，在SVN中有幾個並行維護的不同軟件版本的活動分支。 所以SVN安裝的財產以後看起來像這樣：

SVN ROOT 
|- trunk 
|- branches 
| |- v1 
| |- v2 
| |- v3 
|- tags 
| |- v1 
| | |- 0 
| | |- 1 
| |- v2 
... 

現在我想創建一個爲每個 的SVN分支中的一個分支Git倉庫。創建存儲庫並移植標籤根本不是問題。 我做了

git svn init -s --tags=tags/v1 --tags=tags/v2 <REPO_URL> 
# modified .git/config to use tags/v1/* for the tags of the different versions 
git svn fetch 

並在此之後，我得到所期望的樹枝，我能夠通過使用

git checkout -b v1 origin/v1 

存在的問題，以檢查出不同的軟件版本爲SVN存儲是非常古老的，不同分支的所有分支從中繼。但是我的開發需要我修復一個bug，將其合併到v2以及dcommit一切都返回到SVN。

所以我的問題是什麼是得到清潔（mergable/rebaseable）GIT分支的最佳方式？與此有關的工作流程應該如何？ 我應該添加一個新的分支在GIT每個版本，比方說svn_v1，重訂的V1這個，然後dcommit從那裏？或者什麼是將提交回SVN的最佳方式？

EDIT：

我已經嘗試過根據上游合併變基不同的分支（例如重訂V2到V1和軀幹到V2），但這弄亂 我的歷史和當試圖dcommit它想要提交所有提交我在當前歷史上重新提交的提交。這會使SVN歷史混亂，因爲這些提交已經在回購。

EDIT2：

爲了使問題更加清晰。 Imageine以下病史：

 D--E--F v1 K--L--M v2 
    /  /
A--B--C--G--H--I--J--N trunk 
^
    | 
    introduced a bug 

由於犯B引入了錯誤，所有分支v1，v2，並且trunk受到影響。我們公司的政策現在（在SVN中）在受影響最小的分支（本例中爲v1）中解決此問題，然後通過 分支合併提交至trunk。 工作流如何看起來像在GIT中做同樣的事情，例如在SVN中，v1中的提交被標記爲合併到v2？

Answer 1

好的，我終於自己解決了這個問題。 我已經解決了這兩個步驟：首先，因爲我們的代碼基地爲v1和v2是好的（建設和工作，都與已知的錯誤修復），我已經記錄合併的v1分支到v2分支和v2分成trunk的svn。 現在我可以合併分支git。然後我在git-svn文檔中發現了這段文字：

config key：svn。pushmergeinfo

此選項將導致git-svn在可能的情況下嘗試自動填充SVN存儲庫中的svn：mergeinfo屬性。目前，只有在提交非快進合併的情況下，只有第一個父母已經被推入SVN的情況下才能完成此操作。

所以我已經啓用了該配置值

git config svn.pushmergeinfo true 

現在，如果一個新的bug被發現，我在那有這個bug，dcommit它svn最低版本修復它，然後使用--no-ff選項將其合併到下一個版本中。如果我現在從這裏開始dcommit，那麼svn中的mergeinfos會更新並且一切正常。

Answer 2

聽起來像你想在v1做你的錯誤修正，然後在提交之前挑選。這不是git條款中的合併或轉化操作。如果您想在v1中進行更改，那麼將其合併到master中，然後合併或重新合併爲v2。

我承認我不太清楚問題出在你的描述之後。這聽起來更像是一個工作流問題，然後是我的git-svn問題？如果你的svn分支是好的（即不是一團糟），那麼git init應該已經轉移它們，你可以像往常一樣使用它們。如果他們已經在svn方面已經退化很多，那麼它真的不能「修復」那個爛攤子。

編輯：爲了響應你的第二個編輯：你描述的（在所有分支上分發修補程序/補丁）在git中稱爲「cherry-picking」，而不是合併。 git沒有（也不需要）跟蹤你是否挑選了某物;你只需要做就可以了。你絕對不想在你的場景中進行任何合併或重組。

所以，這裏是你可以做什麼：

1. 你的情況

    D--E--F v1 K--L--M v2 
       /  /
   A--B--C--G--H--I--J--N trunk 
   ^
       | 
       introduced a bug 
   

2. 修復您的錯誤，並承諾在v1，如果這是你的政策。

   git checkout v1 
   # fix bug 
   git add ; git commit 
   # note the commit hash you just created, let's call it a1b2c3d4 
   

3. 分發到其他部門

   git checkout v2 
   git cherry-pick a1b2c3d4 
   
   git checkout trunk 
   git cherry-pick a1b2c3d4 
   

4. 新形勢

    D--E--F--a1b2c3d4 v1 K--L--M--abcde123 v2 
       /     /
   A--B--C--G--H-------------I--J--N--bca123123 trunk 
   ^
       | 
       introduced a bug 
   

就是這樣。 git cherry-pick會自動將差異/補丁用於該單一提交，將其應用於您當前的HEAD，並創建一個新的提交。有（設計上）「後臺」沒有什麼，這是一個非常簡單的過程。像往常一樣可能會有衝突，你可能需要手動修復，但git會告訴你做什麼或多或少清楚。

當您以後繼續正常工作併合並/重新綁定這些分支時，git不需要了解櫻桃採摘。這些東西在你的文件裏面，它會看到（或看不到）文本上的差異，而運氣一點都沒問題。