颠覆变基? [英] Subversion rebase?

问题描述

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

I find this way easier to merge branches and less conflicts:

将中继复制到新分支，并将其与功能分支合并.完成后，将新分支合并回主干.这项技术很像汞和git变基.

Copy trunk to a new branch, merge it with feature branch/s. When things done, merge the new branch back to the trunk. This technique is quite like the mercurial and git rebasing.

我曾经合并过从主干到功能分支的所有更改.但是稍后，当我将功能分支合并回主干时，主干中的某些内容将再次合并回主干，这引起了很多冲突.重新整合有很多选择，但对我来说似乎并不奏效.

I used to merge whatever changs from trunk to feature branche/s. But later when I merged the feature branch back to trunk, some of the stuff from trunk would be merged back again to the trunk, which caused a lot of conflicts. There is a choise of reintegrate merge, but it didn't seem to work for me.

有人对类似的Subversion进行基础调整吗?我最近才开始这样做，还没有看到任何副作用.这会引起任何无法预见的问题吗?

Does anyone do similiar subversion rebasing? I just started doing this recently, and haven't seen any side effects. Would this cause any unforseen problems?

推荐答案

通常，重新定基是在将功能分支合并回到上游分支之前，将上游更改合并到功能分支中的行为.

Generally speaking, rebasing is the act of incorporating upstream changes into a feature branch, before merging the feature branch back into the upstream branch.

在git中，该过程更加复杂，因为自从创建分支以来所做的更改首先被删除并进行缓冲，先应用上游的更改，然后再应用缓冲的更改.这里的要点是将主干合并到功能分支中，这不是git的基础，它还有更多. git方法具有许多优点，但是由于所有提交都必须存储在服务器上(svn不分发)，因此无法在svn中非常干净地实现，但是 可以在svn中完成.

In git, the process is even more sophisticated, because the changes that have been made since the branch was created are first taken off and buffered, the upstream changes are applied, then the buffered changes are applied. The takeaway here is merging trunk into a feature branch is not a rebase in git terms, there's more to it. The git approach has a number of advantages, but can't be implemented very cleanly in svn since all commits must be stored on the server (svn is not distributed), however it can be done in svn.

"svn rebase"(git方法)可能看起来像这样

An 'svn rebase' (the git way) might look something like this

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. (返回功能库WC)svn switch feature

1. svn cp trunk feature
2. commits to feature & trunk
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. (back on feature-rebase WC) svn switch feature

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

Then eventually on a working copy of trunk, svn merge --reintegrate feature

您看到从简单合并主干到功能分支的区别吗?在本例中，从上游的最新数据开始，然后是主干，然后将功能部件上的更改合并到此.

You see the difference from simply merging trunk to the feature branch? You start with the latest from upstream, trunk in this example, then merge the changes from feature onto that.

想象一下，在主干上的某些提交可能来自另一个功能分支到主干的合并，因此我根本不主张直接在主干上进行提交.

Imagine some of the commits on trunk could come from a merge of another feature branch into trunk, so I am not at all advocating committing directly to trunk.

这篇关于颠覆变基?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！