【发布时间】：2013-05-09 13:40:22
【问题描述】：
几个月来，我们一直在使用工作流，SVN 开发人员创建 SVN 修复分支，这些分支使用 git 合并到一个集成分支中，并提交回 SVN，一次合并，使用 dcommit。在这个工作流程中，只有一个 git-svn repo 完成了所有的合并工作。
这个工作流程运行良好，git 合并通常忠实地保存在原始 git-svn 存储库中。
但是，现在我们决定将合并工作负载分散到多个用户中，每个用户都有自己的 git-svn 存储库。不幸的是，我们现在发现由一个 git-svn 用户执行的合并有时（但并非总是）在另一个用户的 git-svn 存储库中看起来像单个父提交，而不是看起来像两个父合并。
丢失合并历史会对历史分析造成严重破坏，并导致不必要的合并冲突，因为 git 无法再识别正确的合并基础，如果合并父级已在所有存储库中保留，它可以做到这一点。
是否有人有任何做法可以帮助避免导致合并历史记录在一个或多个与通用 SVN 存储库同步的 git-svn 存储库中损坏的情况？
【问题讨论】：
-
我使用 git-svn 已经有一段时间了，并没有遇到这个问题。也许是因为我遵循了一个简单的工作流程。你提到的“分支”都是 git branch 吗？你可以提供更多关于你的工作流程的细节。
-
分支是SVN分支。 git 合并总是在对应于两个 SVN 分支的提示的两个 git 提交之间，并且总是在成功合并后立即 dcommit'd 到 SVN。正如我所说，当我是一个进行所有集成合并的人时，这一直运作良好。但是，现在一位同事已经开始承担一些合并工作量，我有时会失去他所做的合并的第二个父级，反之亦然 - 他有时会失去我所做的合并的第二个父级。
-
顺便说一句：我们有 341 个 SVN 标签和 560 个 SVN 分支。因此，集成分支顶端的 svn:mergeinfo 属性值非常复杂且庞大。