这个 git-svn 工作流程会起作用吗？

Question

我正在试验git-svn，并试图提出一个相对不易出错的工作流程。我认为以下应该可以工作，而且很简单，但我见过people using far more complicated workflows，所以我想看看为什么。

1. (master) $ git svn init <path>
2. (master) $ git svn fetch
3. (master) $ git svn rebase
4. (master) $ git checkout -b topic-branch
5. (topic-branch) $ # HACK HACK COMMIT HACK HACK HACK COMMIT HACK COMMIT
6. (topic-branch) $ git checkout master
7. (master) $ git merge topic-branch -- 这是一个快进合并，所以没有合并提交
8. (master) $ git svn rebase
9. (master) $ # fix conflicts
10. (master) $ git svn dcommit
11. GOTO 4

Answer 1

是的，这基本上就是我在使用 Subversion 存储库时所做的。这样做的简单性的关键是将 Git 分支保持在本地，而不是尝试将它们映射到 Subversion 分支。

我刚刚注意到您直接链接到我在另一个问题中的回答。所以也许我应该解释更多。 :)

如果我期望一些冲突工作，我有时会在主题分支中解决冲突。否则，如果我不希望有很多冲突，我可能会先合并到 master，然后再执行git svn rebase。没关系。

关键是 Git 非常灵活，最小 工作流程非常简单。您已向其中添加了一个主题分支；我在主题分支上添加了变基。

Answer 2

根据我的简短经验，我对您的工作流程进行了细微调整并添加了 cmets：

1. (master) $ git svn init <path>（或(master) git svn clone <url>）
2. (master) $ git svn fetch
3. (master) $ git svn rebase（开始循环，解决冲突）
4. (master) $ git checkout -B topic-branch（在此之前小心）
5. (topic-branch) ## HACK HACK COMMIT HACK COMMIT（使用第 3 方）
6. (topic-branch) $ git checkout master
7. (master) $ git rebase topic-branch（解决冲突）
8. (master) $ git svn rebase（解决冲突，如果有的话）
9. (master) $ git svn dcommit（小心在这里阅读）
10. 转到 3（如果不需要再次变基，则转到 4）

我使用 ma​​ster 分支只是为了与 SVN 集成并在 topic-branch 上完成所有工作，就像我相信你一样。我希望这更有意义，因为我无法按照原来的方式使用您的工作流程，即使它基本上是我想要的 - 显然！ :-)

有关所做调整的更多详细信息：

• 注意第 4 步的大写 -B，它将重置主题分支，因此它始终是当前 SVN 的新内容。没有它，循环会中断，给出错误“分支已存在”。
• 第 7 步使用rebase 而不是merge。是的，这可能是一个快进合并，但它比抱歉更安全。图片是否在第 6 步和第 7 步之间完成了某些操作。
• 循环到 3 而不是 4。另外，只是为了安全起见。似乎使用 svn rebase 绝不是一种滥用，因为它总是在 master 上完成，所以总是有分支作为备份。

Answer 3

如果您在执行第 5 步时从不切换到 master 并执行“git svn rebase”是安全的。否则我建议在第 5 步和第 6 步之间做一个“git rebase master”。