我正在使用严格的签入策略在 subversion 存储库中开发一个项目，其中包括：对主干的每个提交都必须由另一个开发人员审查，并且必须在提交消息中提及。
在使用 git-svn 时，我正在做许多未经审查的增量 git 签入。他们的 git commit 消息反映了这一点。
使用 git-svn 但遵循 svn 存储库规则的最佳方式是什么？我应该将所有提交压缩成一个 svn 提交吗？我可以用审阅者信息重写每个修订的提交消息吗？我可以“手动”将每个单独的更改移动到 git master 分支并在执行 git-svn dcommit 之前修改每个更改的提交消息吗？
我在 git 上的一个分支工作，然后 checkout master，git svn rebase最后将分支合并到 master。
在这一点上，git svn dcommit将所有临时提交与它们的原始消息一起放入 svn 中——这不是我们想要的！但是，如果我使用git commit --amend将合并的提交消息从标准合并消息更改为符合我们的 svn 提交策略的内容，则 dcommit 会将它们作为一个新消息集中在一起。赢。
我发现如果 master 在分支的生命周期内没有更改，这似乎不起作用——提交只是快速转发，没有“合并分支”消息——所以最好将 --no-ff标志添加到git merge.
概括：
git checkout branch
<do work>
git checkout master
git svn rebase
git merge --no-ff branch
git commit --amend
<policy-compliant commit message>
git svn dcommit
您可以根据 Subversion 跟踪分支交互式地重新定位本地分支，这为您提供了压缩和修改提交的机会。
下次你 dcommit 时，dcommit 将一次重放你的历史提交，这就是提交给 Subversion 的内容。
假设：
该怎么办：
$ git rebase -i git-svn
您的默认编辑器将打开 master 中的提交列表，以针对 git-svn 进行 rebase。您可以选择、编辑或压缩提交（如果需要，可以混合和匹配）。
做出选择后，将打开另一个临时文件，显示您正在重写的每个提交的提交消息。这是您修改提交消息的地方。
注意事项：
您正在重写存储库的历史记录，请谨慎行事。在感到自信之前，可能值得尝试这种行为。
是的，您可以重写提交消息。是的，您可以将它们全部压缩到一个提交中。这可能取决于审核过程以及您一次完成的工作量。
“手动”将每个更改移动到主分支与在某个级别重写您的提交消息并没有特别的不同，但是许多不同的分支和樱桃选择可能会派上用场。
总的来说，答案是“视情况而定”和“Git 足够灵活，可以做任何你需要的事情”。
这可能值得一试，我是一个相对新手，但这就是我现在正在做的事情：
创建远程 svn 存储库的克隆：
# clone svn repository
git svn clone ....
创建一个普通的 git 存储库（克隆的克隆）：
# clone the clone :)
git clone /path/to/original/clone
git checkout -b working
您现在可以在第二个克隆中工作，就好像它是一个普通的 git 存储库（本质上是这样）：
# commit changes, whatever you like
git ci
...
要将您的更改推送回中央 SVN 存储库，请返回第一个克隆并：
# pull and flatten changes
git pull --squash /path/to/working/clone
该--squash参数表示将拉入的所有提交合并为一个提交。该提交不会立即提交，因此您可以：
git ci
git svn dcommit
然后最后一步将所有内容作为一个提交推送。
编辑-我通常不建议--squash在其他情况下使用，但请注意，工作存储库保留了完整的完整历史记录（它不受壁球的影响），但是您向上游发送的内容被压缩成一个干净的提交，这是在这种情况下所需要的. 我认为这是一个合理的妥协。