我正在使用严格签入策略处理Subversion存储库中的项目，其中包括：每次对干线的提交都必须由其他开发人员进行审阅，并且必须在提交消息中提及。在做git-svn dcommit之前压缩或编辑一些提交？
在使用git-svn时，我正在制作很多未经审查的增量git签入。他们的git提交消息反映了这一点。
什么是最好的方式来使用git-svn，但遵循svn存储库的规则？我应该只是将所有提交压缩为单个svn提交？我能否使用审阅者信息重写每个修订版的提交消息？我可以“手动”将每个单独的更改移动到git master分支，并在执行git-svn dcommit之前修改每个分支的提交消息吗？
可以交互变基对Subversion的跟踪分支，它为您提供了一个机会，壁球和修改提交当地分行。
下一次你dcommit，dcommit将一次重放你的历史一次提交，这将是提交给Subversion的。
假设：
怎么办：
$ git rebase -i git-svn
你的默认编辑器将会打开一个主对象的提交列表，以对抗git-svn。您可以选择，编辑或挤压提交（如果需要，混合和匹配）。
做出选择后，另一个临时文件将打开显示每个您正在改写的提交的提交消息。这是您修改提交消息的地方。
注意事项：
你重写你的资料库的历史，谨慎操作。对这种行为进行实验可能是值得的，直到感到自信。
是的，你可以重写提交消息。是的，你可以将它们压缩到一个提交。这可能取决于审查过程以及您一次做多少。
“手动”将每个更改移动到主分支与在某个级别重写提交消息没有什么特别不同，但许多分歧的分支和樱桃选择可能派上用场。总的来说，答案是“取决于”，“Git足够灵活，可以随心所欲地做任何事情”。
我在git上的一个分支上工作，然后签出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
这可能是值得一试，我是一个相对的新手，但是这是我在做什么现在：
创建远程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但要注意的是，工作仓库保留了完整的完整历史记录（这是免疫的南瓜），但您的上游送什么压扁成一个单一的清洁提交这是在这种情况下需要的。我相信这是一个合理的妥协。
为了确保我明白了：在这种方法中`master`用于提交`svn`，所有的开发和中间提交都在`branch`中。对？ – Dror 2014-08-22 14:24:44
如果您在“合并”步骤中提供了“良好”提交消息，则不需要“修改”它。 – Dror 2014-08-22 15:21:36