这是我使用git-svn的正常工作流程：
我的目标是让我的历史保持一条直线，并尽量减少合并的麻烦。
有没有办法用更少的步骤来做到这一点？
答案 0 :(得分：1)
这里有2件事情。要将历史记录保持在一条直线上，您需要重新定义。但是，变基意味着您必须在不同的代码库之上重新应用更改。这可以引发一系列冲突解决方案，您可能需要为每次提交的提交执行。
我可以添加的唯一帮助你的是，如果你已经重新定位，你知道你将有一个快进合并。在这种情况下，您无需签出该分支即可将其向前移动。因此，要更新参考，您可以：
git push . my-branch:master
这将更新master以指向my-branch所指向的位置，并且只有在它可快速转发时才会起作用。不幸的是，它不会帮助你，因为你需要在分支机构上做你需要的行动。
回到工作流程的问题，与简单合并相比，冲突会遇到更多问题。
答案 1 :(得分：1)
没有必要在中间做你的rebase，当然也不需要交换到master分支这样做。我的工作流程实现了相同的目标，因此：
为问题创建分支：git checkout -b issue remotes/trunk（如果我已经在我感兴趣的分支机构上，remotes/trunk可以省略。）
做一些工作并提交。
将其直接推送到Subversion存储库：git svn dcommit。只有在您编辑过的文件发生更改后，才会失败。如果有，则会收到错误，所以git svn rebase然后再次尝试git svn dcommit。
请注意，无需先将其合并到主分支中。
签出主分支：git checkout master。
重新启动主分支：git svn rebase。
（可选）删除问题分支;主人和问题分支现在应该是相同的，因为git svn dcommit之后会立即git svn rebase。
您可以从任何分支机构执行git svn命令;系统将根据父Subversion分支计算出提交或重新绑定的位置。如果您想查看它感兴趣的Subversion分支，请运行git svn dcommit --dry-run
特别是，主分支并没有什么特别之处。实际上，我经常忽略它并跳过上面的步骤4-5。我只是从一个问题分支交换到另一个问题分支，并且从不打扰将主分支引入Subversion技巧。
答案 2 :(得分：1)
您可以尝试使用SubGit代替git-svn。
SubGit是服务器端解决方案。它使Git能够访问您的Subversion存储库以及Subversion访问Git存储库。一个人必须将SubGit安装到Subversion存储库中，即基本上添加必要的钩子，在每次推送和提交时都进行转换：
$ subgit configure $SVN_REPOS
$ # Adjust $SVN_REPOS/conf/subgit.conf
$ # to specify your branches and tags
$ # Adjust $SVN_REPOS/conf/authors.txt
$ # to introduce svn author names to their git counterparts
$ subgit install $SVN_REPOS
之后，在$ SVN_REPOS / .git上有一个Git存储库，它与Subversion版本不断同步。当为此Git存储库配置远程访问时（例如，通过git-http-backend），可以使用任何Git工作流和任何Git客户端与现有的Subversion存储库。
对于你的情况，它看起来像这样：
$ git checkout -b foo
$ git commit
$ git checkout master
$ git merge foo or git rebase foo
$ git push
更多细节：