(svn) 合并回重构但不是整个分支,可能吗?

发布于 2024-12-26 03:45:00 字数 374 浏览 0 评论 0原文

我注意到我的团队中有一个(n)(反)模式:

我们决定实现一个功能,所以我们(svn)分支。 在实现该功能时,我们进行了重构,如果可以立即合并回主干,这将使每个人受益。 我们等到分支完成后,然后将其与主干重新集成,每个人都可以获得该功能+重构。

现在有趣的是,重构通常比启动它们的功能具有更高(和直接)的价值,所以如果我能以某种方式立即将它们放入后备箱而不是等到分支已完成并重新集成。

据我所知,您不应该将分支与主干“合并”,但您可以采取相反的方式(经常将主干与分支合并),直到分支完成,然后您将分支“重新集成”回来树干。如果你以错误的方式做事(将分支与主干合并),那么你就会把事情搞砸(合并信息之类的),到时候,你就会陷入各种邪恶的境地,并且无法顺利地重新整合。

想法?

I noticed a(n) (anti-)pattern in my team:

We decide to implement a feature so we (svn) branch.
While implementing the feature, we do refactorings that would benefit everyone if they could be merged back to the trunk right away.
We wait until we are done with the branch, then reintegrate it with the trunk and everyone gets the feature + the refactorings.

Now the funny thing is very often the refactorings are of much higher (and immediate) value than the feature that set them in motion, so it would be very nice if somehow I could get them in the trunk immediately and don't wait till the branch is done with and gets reintegrated.

As far as I know you are not supposed to "merge" a branch with the trunk, but you do the other way around (merge the trunk with the branch frequently) until the branch is done and then you "reintegrate" the branch back with the trunk. If you do it the wrong way (merge a branch with trunk) then you mess things up (mergeinfo and stuff) and when the time comes, you get into all sorts of evil and you can't reintegrate smoothly.

Ideas ?

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

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

发布评论

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

评论(1

顾冷 2025-01-02 03:45:00

这是可能的。它甚至还有一个名字 - 择优挑选。实际上,只要能够避免分支合并的“大爆炸”,就鼓励挑选。此外,如果您以相同方向合并(在您的情况下从分支到主干),它会简化重新集成。 Subversion 会记住之前使用 mergeinfo 合并的内容,并排除包含在之前合并中的提交。它对应于模式尽早合并,经常合并

原理如图所示:

enter image description here

与您的情况不同的是,您需要在其他方向合并,但是源分支和目标分支是什么并不重要。

因此,不要害怕将重构合并到主干中。实际上,它甚至会简化将来的分支重新集成。

It is possible. It even has a name - cherrypicking. Actually, cherrypicking is encouraged as long as it allows to avoid 'big bang' on branches merging. Moreover, if you do merging in the same direction (in your case from branch to trunk), it simplifies reintegration. Subversion remembers what have been merged previously using mergeinfo and excludes commits included into previous merges. It corresponds to the pattern Merge Early, Merge Often.

Principle is illustrated on the picture:

enter image description here

Difference with your case is that you need to merge in other direction, but it does not matter what will be the source branch and what will be the target branch.

So, don't be afraid of merging your refactorings into trunk. Actually, it will even simplify branch reintegration in the future.

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