使用Git时，修补程序分支应该与开发分支合并，还是应该相反？
使用Git时，修补程序分支应该与开发分支合并，还是应该相反？
提问于 2012-08-30 01:04:07
我想知道为什么在Pro Git书(Apress 2009)中，第3章中的例子是：
- 现在，在
master分支上提交的所有内容都已经推向生产了。 - 创建一个用于开发特性的
iss53分支，添加一些临时更改并提交。 - 需要热修复，所以切换到
master分支并创建一个hotfix分支 - 修复错误(例如技术支持电子邮件地址的错误)，并提交，然后推送到生产中
- 切换到
master分支并与hotfix分支合并 - (可选)删除
hotfix分支
现在，我想知道为什么这本书会转到master分支，并与iss53分支进行合并。难道这不会使主干道处于中间状态吗？如果需要另一个热修复，那么主服务器就不适合进行热修复，我们必须手动选择合并之前的提交。合并不应该是，进入iss53分支并与hotfix分支合并，这样现在有什么问题将被合并到将来的发行版中？
更新:实际上，本书假设iss53工作已经完成，并完成了最后一次合并。但是，如果iss53上的工作还没有完成，并且我们想要合并到热修复中呢？
回答 2
Stack Overflow用户
发布于 2012-08-30 01:13:52
@動靜能量，
在这种情况下，您有三个选择：
cherry-pickhotfix提交给iss53- 将
master合并到iss53 - 将
iss53重定向到master上
就我个人而言，我更喜欢3号，因为它提供了更干净的历史。
但是，如果您有太多的开发人员(比如linux )，那么#2可能更容易。这应该是罕见的。在这种情况下，请确保将master合并到一个稳定点(例如，稳定点发布，而不是一些随机测试状态)，这样历史就不会变得太复杂。
LWN让文章详细讨论这个问题。
Stack Overflow用户
发布于 2012-08-30 01:17:08
如果iss53上的工作尚未完成，但您想要修补程序，则可以将master合并到iss53中，或者(更好)在master的基础上重新设置iss53。
合并：
git checkout iss53
git merge --no-ff master # --no-ff keeps the master tip where it is重基(您将在本章后面讨论这个问题)：
git checkout iss53
git rebase master页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/12188543
复制相关文章
相似问题
腾讯云开发者
