Subversion rebase？

Question

我发现这种方式更容易合并分支和更少的冲突:

将trunk复制到新分支,将其与功能分支合并.完成任务后,将新分支合并回主干.这种技术非常像mercurial和git rebasing.

我过去常常将trunk中的任何变换合并到featurech/s.但后来当我将功能分支合并回主干时,来自主干的一些内容将再次合并回主干,这引起了很多冲突.有一个重新整合合并的选择,但它似乎并不适合我.

有没有人做类似的颠覆变基？我刚刚开始这样做,并没有看到任何副作用.这会导致任何不可预见的问题吗？

Answer 1

一般而言,重新定位是在将要素分支合并回上游分支之前将上游更改合并到要素分支中的行为.

在git中,该过程更加复杂,因为自创建分支以来所做的更改首先被取消并缓冲,应用上游更改,然后应用缓冲的更改.这里的内容是将主干合并到一个功能分支不是git术语中的rebase,还有更多内容.git方法有许多优点,但是在svn中不能非常干净地实现,因为所有提交都必须存储在服务器上(svn不是分布式的),但是可以在svn中完成.

'svn rebase'(git方式)可能看起来像这样

1. svn cp trunk feature
2. 承诺功能和主干
3. svn cp trunk feature-rebase
4. svn co feature-rebase
5. cd feature-rebase
6. svn merge feature
7. svn commit
8. svn rm feature
9. svn mv feature-rebase feature
10. (回到feature-rebase WC) svn switch feature

然后最终在干线的工作副本上, svn merge --reintegrate feature

您看到简单地将主干合并到功能分支的区别？在此示例中,您将从上游的最新版本trunk开始,然后将功能中的更改合并到该示例中.

想象一下,主干上的一些提交可能来自另一个功能分支合并到主干,所以我根本不提倡直接提交到主干.

Answer 2

我希望我有一个聪明的技巧告诉你如何在SVN中实现变基,但我总是避免手动刷新SVN中的主干变化的分支,这主要是因为jdehaan提到的需要手动樱桃采摘的复杂性.

我通常做的是遵循将更改从分支合并到主干,删除分支,然后从主干重新创建分支的做法.这允许我刷新/重新设置我的功能分支,但有时会产生不幸的副作用,即该分支的任何先前更改现在都是主干的一部分.出于这个原因,我只在功能分支处于稳定且可用的点时才遵循这种做法,但我仍然希望继续处理该功能以进一步完成更大的目标.

我更喜欢通过将主干更改合并回分支来刷新分支,而不会导致后续重新集成从该分支合并以在该过程中提取这些重新定义的修订.应该可以根据merge-info属性执行此操作,但根据jdehaan的说法和我担心的是,这样做仍然需要采摘樱桃.

请注意,正确的变基实现还应该能够考虑其中分支由另一个分支构成的阶梯套管示例.

更新:根据Subversion文档,当使用--reintegrate选项时,Subversion应该能够正确地重新集成在分支中完成的工作,以便考虑可能已经完成的任何可能的刷新合并以将基础更改带入科.当然,这在技术上与变基有点不同,但我认为它在使用上足够相似,可以称之为变基.

Answer 3

在我的公司，我们使用以下方法：

1. 对于问题跟踪器中的每个任务 NK-$X，我们有一个单独的分支 Branches/NK-$X
2. 我们通过 svn cp trunk Branches/NK-$X 开始执行任务
3. 我们从不直接向主干提交更改。对于每个计划的更新 UPDNK-$X，我们都有一个单独的分支/UPDNK-$X。我们在更新之前使用 svn cp trunk Branches/UPDNK-$X 创建它。
4. 当任务 NK-$X 计划更新 UPDNK-$Y 时，我们将分支/NK-$X 合并到 UPDNK-$Y 中。即 cd UPDNK-$Y; svn merge -r start:HEAD 分支/NK-$X
5. UPDNK-$Y 准备好后，我们将其合并到主干。即 cd trunk;svn merge -r start:HEAD 分支/UPDNK-$Y

如果任务 NK-$X 持续时间超过一个迭代周期，因此需要刷新，我们永远、永远、永远不会将主干合并到 NK-$X。我们有一条规则，您只能将您自己编写的内容提交给您的分支，这使一切变得更容易。相反，我们这样做：

cd NK-$X
svn log
//let L = the number of the last changeset to this branch changeset
//let F = the number of the first changeset to this branch
svn rm branches/NK-$X 
svn cp trunk branches/NK-$X 
svn up
svn merge -r F:L branches/NK-$X@L 
svn ci -m 'refereshed'

这样，每当您查看 Branches/NK-$X 的变更日志时，您只会看到开发人员实际执行的更改。

更新： 由于上述工作流程可以自动化，我在 github 上启动了一个项目：svn rebase。

Answer 4

我正在使用这种方法：

通过变基，您必须注意在再次合并时不要采用变基修订。在合并时，请进行精挑细选：仅选择功能分支上实现新内容的修订，而不是变基变更集。那么它应该可以正常工作。评论：我不记得曾使用过 reintegrate 分支来做什么。我认为它仅适用于非常简单的用例。

在您的新方法中，从描述中不清楚您如何处理从主干到功能分支的变基（如果需要）。您想完全禁止变基吗？由于 svn 中的分支是一种廉价的操作，这也可能是一种选择。