重新集成合并到主干后使用颠覆功能分支是否安全?

发布于 2024-07-21 00:13:54 字数 337 浏览 3 评论 0原文

功能分支合并(重新集成)回主干后是否必须删除?

我更喜欢不断地从我的功能分支来回合并更改 - 我相信这可以将冲突降到最低。 但我知道,一旦您使用重新集成合并到主干,就应该删除功能分支。

是这样吗? 为什么? 我可以做什么来规避这个问题?

更新 我问的是该工具带来的技术问题,而不是“方法问题”。 我打算在合并后继续开发功能分支。

更新最上面的答案确实指定了一个相当复杂的过程(合并、删除和重新分支)。 在 TortoiseSVN 中是否有一种简单的方法可以实现这一点? 不应该有吗?

Must a feature branch be deleted after it's merged (reintegrated) back to trunk?

I prefer to constantly merge changes back and forth from my feature branch - I believe this keeps the conflicts to a minimum. Yet I understand that once you use the reintegrate merge to trunk, a feature branch should be deleted.

Is it so? Why? What can I do to circumvent this?

Update
I'm asking about technical problems that come from the tool, not "methodology concerns". I intend to keep working on the feature branch after the merge.

Update the top answer indeed specifies a rather complex procedure (merge, delete & rebranch). Is there an easy way to accomplish this in TortoiseSVN? Shouldn't there be?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

耶耶耶 2024-07-28 00:13:54

编辑此问题似乎已在 SVN 1.8 中修复。 SVN 1.8 书中有关基本合并的部分已更新为可以重用功能分支。 下面的答案仅与较旧的 SVN 版本相关。


来自 svn 书中的基本合并部分:

在 Subversion 1.5 中,一旦
--reintegrate合并是从分支到主干,分支是no
可以更长时间地用于进一步的工作。 它是
无法正确吸收新树干
变化,也不能适当地
再次重新融入主干。 为了这
原因,如果你想继续努力
您的功能分支,我们推荐
销毁它然后重新创建它
从后备箱:

SVN 1.6和1.7中仍然是这种情况。

这篇关于反射合并的优秀文章解释了原因 确切地说,你不能或不应该回收功能分支。 最重要的几点总结:

  • 您可以努力解决冲突
    与主干重新集成时
  • 主干中的重新集成提交
    因此包含两个更改
    来自功能分支
    冲突解决工作
  • 然而,颠覆不会帮助你
    合并此冲突解决工作
    回到功能分支。 它只是简单地
    查看合并信息并思考
    “这些变化最初来自于
    feature分支,无需合并
    删除功能分支并重新分支的

成本很低,并且可以避免整个问题。

edit: This problem appears to have been fixed in SVN 1.8. The section on basic merging from the SVN 1.8 book has been updated to say that it is OK to reuse a feature branch. The answer below is only relevant for older SVN versions.


From the section on basic merging in the svn book:

In Subversion 1.5, once a
--reintegrate merge is done from branch to trunk, the branch is no
longer usable for further work. It's
not able to correctly absorb new trunk
changes, nor can it be properly
reintegrated to trunk again. For this
reason, if you want to keep working on
your feature branch, we recommend
destroying it and then re-creating it
from the trunk:

This is still the case in SVN 1.6 and 1.7.

This excellent article on reflective merges explains why exactly you can't or shouldn't recycle a feature branch. Summary of the most important points:

  • you may do work to resolve conflicts
    when reintegrating with the trunk
  • The reintegration commit in trunk
    therefore contains both changes
    coming from the feature branch and
    conflict resolution work
  • However, subversion will not help you
    merge this conflict resolution work
    back to the feature branch. It simply
    looks at the mergeinfo and thinks
    "these changes originally came from
    the feature branch, no need to merge
    them again to their origin".

Deleting the feature branch and rebranching is cheap and avoids this whole issue.

〆一缕阳光ご 2024-07-28 00:13:54

我们经常这样做(SVN 1.5 及更高版本)。 您只需确保不要将这些更改重新合并回分支中。

为此,只需将一系列修订从主干合并到分支即可。 指定主干中您重新集成分支的修订,并将其标记为“仅记录从主干修订到分支的合并”。

一旦你这样做了,你就可以开始了。

编辑
wcoenen 在有关冲突的文章中提出的观点是正确的。 如果在重新集成之前不将主干更改同步到分支中,则会出现冲突问题。 我们保持分支同步,并且在多次重新集成后继续重用分支没有问题。

编辑 2

使重新集成的分支保持活动状态
(http://svnbook.red-bean.com/en /1.7/svn.branchmerge.advanced.html)

重新集成后,还有一种替代方法可以销毁并重新创建分支。 要了解其工作原理,您需要了解为什么分支在重新集成后最初不适合进一步使用。

We do this often (SVN 1.5 and above). You just have to make sure not to remerge those changes back into the branch.

To do that simply do a range of revisions merge from the trunk to the branch. Specify the revision in the trunk that you did the reintegrate of the branch and mark it as "Only record the merge" from the trunk revision to the branch.

Once you do that you should be good to go.

Edit
The point the wcoenen brings up from the article about conflicts is valid. If you do not sync the trunk changes into the branch before doing the reintegrate you will have the conflict problem. We keep the branch synced up and have had no problem continuing to reuse the branch after multiple reintegrates.

Edit 2

Keeping a Reintegrated Branch Alive
(http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html)

There is an alternative to destroying and re-creating a branch after reintegration. To understand why it works you need to understand why the branch is initially unfit for further use after it has been reintegrated.

卸妝后依然美 2024-07-28 00:13:54

是的,您可以进行仅记录合并来保持分支处于活动状态。

请参阅保持重新集成的分支处于活动状态< /a> 在 Subversion 书中。

Yes, you can do a record-only merge to keep the branch alive.

See Keeping a reintegrated branch alive in the Subversion Book.

懒的傷心 2024-07-28 00:13:54

Subversion 1.8 允许您在两个分支之间反复来回合并,而 1.7 及更早版本则不允许。 请在此处阅读发行说明:http://subversion.apache.org /docs/release-notes/1.8.html#auto-reintegrate

Subversion 1.8 allows you to merge repeatedly back and forth between two branches, whereas versions 1.7 and earlier did not. Read the release note here: http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate.

电影里的梦 2024-07-28 00:13:54

这一切都取决于你的个人意见,以及合并到主干的人数。

如果您有很多人合并,那么最好只在完成后合并一个分支,然后将其删除(您始终可以通过返回到它存在的最后一个修订版来访问它)。 如果你在这种情况下尝试不断合并,你只会让自己感到困惑。

但是,如果您没有很多子分支,并且您使用的是 subversion 1.5+,则可以不用这样做,它可以帮助避免合并冲突。

当然,如果你的“主干”被用作测试版/发布候选者/发布存储库,那么你不应该这样做。

This all depends on your personal opinion, and on the number of people merging into trunk.

If you have a lot of people merging in, then it is probably better to only merge a branch once it is finished with, and then to delete it (you can always access it by going back to the last revision where it existed). If you try to continuously merge in this situation you will just confuse yourself.

However, if you don't have many sub-branches, and you are using subversion 1.5+, you can get away with this, and it can help to avoid merge conficts.

Of course, if your "trunk" is used as a beta/release candidate/release repository, then you sholdn't do this.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文