Question

我正在使用严格的签入策略处理subversion存储库中的项目，其中包括：每次提交到trunk都必须由另一个开发人员审核，这必须在提交消息中提及。

在使用git-svn时，我正在进行许多未经审核的增量git签到。他们的git commit消息反映了这一点。

使用git-svn但遵循svn存储库规则的最佳方法是什么？我应该将所有提交压缩成单个svn提交吗？我可以使用审阅者信息重写每个修订的提交消息吗？在执行git-svn dcommit之前，我可以“手动”将每个单独的更改移动到git master分支并修改每个更改的提交消息吗？

Answer 1

我在git的分支上工作，然后检查主人，git svn rebase，最后将分支合并到主人。

此时，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

Answer 2

您可以使用Subversion跟踪分支以交互方式为本地分支重新绑定，从而为您提供压缩和修改提交的机会。

下次你提交时，dcommit会一次重播一次提交的历史记录，这将是Subversion的提交。

假设：

本地分支是主人
Master已签出
远程跟踪分支名为git-svn
git-svn是最新的

怎么做：

$ git rebase -i git-svn

您的默认编辑器将打开一个master中的提交列表，以反对git-svn。您可以选择，编辑或压缩提交（如果需要，可以混合和匹配）。

完成选择后，将打开另一个临时文件，显示您正在重写的每个提交的提交消息。这是修改提交消息的地方。

注意事项：

您正在重写存储库的历史记录，请谨慎操作。在感到自信之前，尝试这种行为可能是值得的。

Answer 3

是的，您可以重写提交消息。是的，你可以将它们全部压缩到一次提交中。这可能取决于审核流程以及您一次做多少。

“手动”将每个更改移动到主分支与在某个级别重写提交消息没有什么不同，但是许多不同的分支和樱桃选择可能会派上用场。

总的来说，答案是“它取决于”和“Git足够灵活，可以随心所欲地做任何事情。”

Answer 4

这可能值得一试，我是一个相对新手，但这就是我现在正在做的事情：

创建远程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，但请注意工作存储库会保留完整的完整历史记录（它对壁球免疫）但是你发送上游被压缩成一个干净的提交，这是在这种情况下所需要的。我认为这是一个合理的妥协。

在执行git-svn dcommit之前压缩或编辑一些提交？

4 个答案: