將具有多個活動分支的SVN存儲庫轉換為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存儲庫已經很舊，並且不同的分支都從主干分支。 但是我的開發需要我修復v1中的錯誤，也將其合並到v2中， 並將所有內容提交回SVN。

所以我的問題是獲取干凈（可合並/可重新設置基准）GIT分支的最佳方法是什么？ 與此相關的工作流程應該如何？ 我是否應該為GIT中的每個版本添加一個新分支，例如svn_v1 ，將v1重新建立到該分支中 ，然后從那里進行提交 ？ 還是將提交回SVN的最佳方法是什么？

編輯 ：

我已經嘗試根據上游合並變基不同的分支（例如重建基礎V2到V1和軀干到V2），但這個搞砸了我的歷史和嘗試dcommit時，要提交所有的，我已經衍合上提交當前歷史的頂部。 由於這些提交已在Repo中，因此這會使SVN歷史變得混亂。

編輯2：

使問題更清楚。 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進行選擇。 這不是git的合並或變基操作。 如果您要在v1進行更改，然后將其合並到master ，然后將其合並或重新設置到v2 。

不過，在您的描述之后，我承認我不太確定問題出在哪里。 在我看來，這聽起來像是工作流程問題，然后是git-svn問題？ 如果您的svn分支是好的（即，不是一團糟），則git init應該以與往常一樣的方式對其進行了轉移。 如果它們在svn方面已經降級很多，那么它就不能“修復”那堆爛攤子。

編輯：為了響應您的第二次編輯：您描述的內容（在所有分支中分布一個修補程序/補丁）在git中稱為“櫻桃挑選”，而不是合並。 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不需要知道如何挑選櫻桃。 這些東西在您的文件內，它將看到（或看不到）文本差異，如果運氣好的話，一切都會很好。

Answer 2

好的，我終於設法自己解決了這個問題。 我分兩步解決了這個問題：首先，由於v1和v2代碼基礎很好（構建並正常工作，並且都修復了已知的錯誤），因此我記錄了v1分支到v2分支的合並和v2進入svn trunk 。 現在，我可以在git合並分支了。 然后，我在git-svn文檔中找到了這一段：

配置密鑰：svn.pushmergeinfo

該選項將使git-svn嘗試在可能的情況下自動填充SVN信息庫中的svn：mergeinfo屬性。 當前，僅當取消提交非快進合並時（除第一個以外的所有父母都已被推送到SVN中），才能執行此操作。

所以我啟用了這個配置值

git config svn.pushmergeinfo true

現在，如果發現了一個新的錯誤，我將其修復在具有此錯誤的最低版本中， dcommit其提交給svn ，然后使用--no-ff選項將其合並到下一個版本中。 如果我現在從那里dcommit ，則svn的mergeinfos將得到更新，一切正常。