这个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分支。

我刚注意到你在另一个问题中直接链接到了我的答案。所以也许我应该解释一下。 ：）

如果我预计会发生一些冲突，我有时会在主题分支中进行冲突解决。否则，如果我不期望很多冲突，我可能会在执行git svn rebase之前先合并为master。没关系。

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

Answer 2

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

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（使用第三方）
6. (topic-branch) $ git checkout master
7. (master) $ git rebase topic-branch（解决冲突）
8. (master) $ git svn rebase（解决冲突，如果有的话）
9. (master) $ git svn dcommit（小心在这里阅读）
10. GOTO 3（如果不再需要再修改，则为4）

我正在使用 master 分支，只是为了与SVN集成并完成 topic-branch 的所有工作，就像我相信你一样。我希望这更有意义，因为我不能按照它的方式使用你的工作流程，即使它基本上是我想要的 - 显然！ ： - ）

有关所做调整的更多详情：

• 在第4步注意资本 -B ，它将重置主题分支，因此它始终是当前SVN的新功能。如果没有它，循环就会中断，给出错误“branch already exists”。
• 第7步使用rebase而不是merge。是的，它可能是一个快速合并，但它比抱歉更安全。如果在步骤6和7之间完成某事，则说明图片。
• 循环到3而不是4.另外，只是为了安全起见。似乎使用svn rebase永远不会被滥用，因为它总是在master上完成，所以总是将分支作为备份。

Answer 3

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