如何轻松地在 Git 中的多个发布分支上应用错误修复?

发布于 2024-08-13 02:25:24 字数 588 浏览 5 评论 0原文

我已经使用 git 进行单人开发有一段时间了,但直到现在我还没有遇到任何棘手的分支问题,而且我似乎忘记了一些基本的东西,而我在阅读实用版本后毫无疑问“知道”这些东西使用 Git 进行控制书籍..

我经常比我的网站上实际发布的内容提前几个版本,因此当错误报告出现时,我只将它们应用到当前的主分支,而不是在下一个发布的版本中修复它们。当然,我想改变这一点以便更快地修复问题。

假设 1.0 刚刚发布,1.1 即将发布,但我已经在开发 1.3,例如

1.0 - released  
1.1 - finished  
1.2 - finished  
1.3 - in development  

出现错误报告..通常这会在 1.3 中修复,但我如何在 1.1 中修复它?

据我所知,在 svn 和其他“传统”源代码控制系统中,我需要分支 B.1.1 和 B.1.2 并将更改依次应用到每个分支,然后从每个分支进行构建,最后将修复应用到主分支。

然而,我似乎记得 git 做了一些聪明的事情:我分支 B.1.1,在那里进行更改,执行 {something} 和 B.1.2,并且主分支会通过修复自动更新。这是可能的还是我想象的{某事}?

I've been using git for a while for my one-man developments, but I haven't run into any tricky branching issues until now and I seem to have forgotten something fundamental that I no doubt "knew" just after reading the Pragmatic Version Control Using Git Book..

I'm often several releases ahead of what is actually published on my website, so that when a bug report comes in, I only apply them to the current master branch rather than fixing them in the next released version. Of course, I'd like to change that to get fixes out quicker.

Let's say 1.0 was just released, 1.1 is going to be released soon, but I'm already working on 1.3, e.g.

1.0 - released  
1.1 - finished  
1.2 - finished  
1.3 - in development  

A bug report comes in.. usually this would be fixed in 1.3, but how do I fix it in 1.1 instead?

As far as I am aware in svn and other "traditional" source control systems, I would need to branch B.1.1 and B.1.2 and apply the changes to each branch in turn, then build from each branch and finally apply the fix to the master branch.

I seem to remember that git, however, does something clever: I branch B.1.1, make the changes there, do {something} and B.1.2 and the master branches are automagically updated with the fix. Is this possible or did I imagine {something}?

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

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

发布评论

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

评论(2

半岛未凉 2024-08-20 02:25:24

在这种情况下,正确的方法是:

  • 确保您已创建 B1.1 和 B1.2(以隔离各自分支中的最终修复)
  • 将补丁应用于
  • 提交到 B1 和 B2 的 mastercherry-pick

正如<中提到的a href="http://www.mail-archive.com/libtool-patches@gnu.org/msg03765.html" rel="nofollow noreferrer">此线程,这将:

确保 master 不会相对于旧分支回归。 (不要使用合并,除非您想将一个分支的所有更改合并到另一个分支,而不仅仅是单个提交
你提到。)

The right way in this case would be to:

  • make sure you have B1.1 and B1.2 created (to isolate final fixes in their respective branch)
  • apply your patch on master
  • cherry-pick that commit to B1 and B2

As mentionned in this thread, that would:

ensures master doesn't regress with respect to an older branch. (Do not use merge unless you want to merge all changes from one branch to another, rather than just the single commit
you mention.)

爱的故事 2024-08-20 02:25:24

在这种情况下,如何固定 B1.1,将 B1.1 合并到 B1.2,然后将 B1.2 合并到 B1.3?

What about in this case fixing on B1.1, merging B1.1 into B1.2, then B1.2 into B1.3?

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