Git-svn合并两个SVN分支

Question

我已经阅读了很多关于git-svn 和合并的 SO 问题和博客。其中一些（尤其是git-svn 手册页）警告反对在我计划从dcommit 的分支附近使用合并。

其他人，如SO answer，表示只要我使用在dcommitting 之前删除的一次性 功能分支，合并就可以了。

我有两个长期存在的 SVN（和 git）分支：

• trunk (git-svn: svn/trunk, git: master) - 稳定分支
• branches/devel (git-svn: svn/devel, git: devel) - 我从中分叉功能分支的主要开发分支（我可以忍受将它们重新定位回devel而不是合并）。

在上图中，(1) 显示了过去的 SVN 历史，其中branches/devel 已合并到trunk。

(2) 表明我已经成功dcommitted 我目前的开发回到了 SVN。

问题：我可以使用git-svn 来合并两个SVN 分支，以便历史记录显示合并点（就像SVN 本身一样）？换句话说：如果我从master 到dcommit 会发生什么，如(3) 所示？

这会弄乱我的 SVN（或 git）历史吗？或者这会完全忘记devel 被合并到master 吗？

编辑：如果git 只是忘记了devel 被合并到master 中，那么dcommiting 从点(3) 和将所有提交应用为单个 patch？

Answer 1

深入了解一下，我发现git支持在dcommit'ing时在SVN分支上设置svn:mergeinfo属性：

git svn dcommit --mergeinfo "/branches/somebranch:1-3"

注意！svn:mergeinfo 被覆盖命令行中给出的任何内容，因此请注意列出以前的合并 .

虽然较新的 git 版本添加了 config 参数以自动设置此属性：

config key: svn.pushmergeinfo

我在使用自动合并信息时遇到了一些问题 - 由于某种原因或其他 GIT 计算错误，我无法让它工作。

解决方案：git-merge-svn

为了自动化该过程，我编写了一个 shell 脚本 git-merge-svn，它可用于合并两个 SVN 分支，并在 dcommit 上设置了正确的 svn:mergeinfo。

脚本处理这两种情况：

• 分支未在 git 中合并 - 将预先执行 git merge
• 分支已在 git 中合并（但未在 SVN 中）- 将遍历直到合并提交修订的上一个祖先。

使用这个脚本，我能够仅在 git 端生成这些合并并保留合并信息，以便 GIT 图表很好地显示日志：

使用示例：

1. 在 devel6 上进行一些提交
2. dcommit devel6 到 SVN（需要获取提交的 SVN 修订号）
3. 查看 testtunk6 - 是的，我知道我的名字打错了 ;-)
4. git merge-svn devel6

最后一条命令输出：

% git merge-svn devel6
About to do an SVN merge: devel6 -> testtunk6

* NEW MERGE COMMIT
|\
| * devel6 [7b71187] (r102)
* | testtunk6 [0682a45] (r101)
 \|
  * [273d6d6] (r100)


STEP 1: GIT merge
Executing:
  git merge devel6

Continue? (y/n) [n]: y
Merge made by the 'recursive' strategy.
 testfile | 1 +
 1 file changed, 1 insertion(+)

STEP 2: SVN dcommit

executing:
git svn dcommit --mergeinfo
/idp/branches/devel:9-32,35-41 /idp/branches/devel6:89 /idp/branches/devel6:94 /idp/branches/devel6:93 /idp/branches/devel6:96 /idp/branches/devel6:97 /idp/branches/devel6:99 /idp/branches/devel6:100 /idp/branches/devel6:102

Continue? (y/n) [n]: y
Committing to https://my.svn.host/svn/auth/idp/branches/testtunk6 ...
  M testfile
Committed r103
  M testfile
Found merge parent (svn:mergeinfo prop): 7b71187fc371d3f86658c5850009e63be88157ac
r103 = 87759323cbadd38bac78087d57b6870a926287e7 (refs/remotes/svn/testtunk6)
No changes between 3fb2168cfbbe605fbd810d76513443203a85a549 and refs/remotes/svn/testtunk6
Resetting to the latest refs/remotes/svn/testtunk6

Answer 2

Git 和 Svn 有不同的数据结构来保存历史记录。

Svn 使用一个简单的树。 IE。每个提交只有一个父级，但一个提交可以有多个子级（分支）。所以，Svn 不支持合并。他们称之为“合并”的东西实际上是变更集移植，在 git 中最接近的类比是 rebase 或者可能是 cherry-pick。从 1.5 版开始，Svn 支持元信息属性svn:mergeinfo，它有助于以某种方式跟踪“合并”的内容，但它看起来主要是一种解决方法，这解释了为什么 Svn 中的分支如此难以使用。合并点是一种提交，它将所有合并的变更集和冲突解决方案压缩到一个变更集中，可能使用 svn:mergeinfo 属性进行注释。

Git 使用Directed acyclic graph，这是描述历史合并和分支的非常自然的方式。合并点只是具有两个（或更多！）父母的另一个提交。因此，图片上的 (3) 是合并提交。所以，所有的历史看起来都很自然，它在历史图表上从当前点可以访问所有提交。

Git-Svn 桥尽量处理 Svn 设计的缺陷，在做 dcommit 之前，它通常将所有合并的提交重新设置在当前 Svn 分支的顶部。 Asof ~2 年前，git-svn 无法提供svn:mergeinfo，所以你问的事情是不可能的。此外，当您在dcommiting 时，git 创建一个“几乎”链接到 svn 提交的“孪生”提交，因此它会重写原始提交。