使用Git，一个修补程序分支应该与开发分支合并还是应该是相反的方式？

Question

我想知道为什么在Pro Git书（Apress 2009）中，第3章的例子是：

1. 现在master分支上承诺的所有内容已经推送到生产
2. 创建了一个iss53分支，用于开发功能，添加一些临时更改并提交。
3. 需要进行热修复，因此切换到master分支并创建hotfix分支
4. 修复错误（例如技术支持电子邮件地址的拼写错误），并提交并推送到生产
5. 切换到master分支并与hotfix分支
合并
6. （可选）删除hotfix分支

在这一点上，我想知道为什么这本书会转到master分支并与iss53分支合并。这不会实际上使主分支处于中间状态吗？如果需要另一个热修复，那么master不适合进行热修复，我们必须手动选择合并之前的提交。不应该合并，转到iss53分支并与hotfix分支合并，以便现在将错误的内容合并到未来的版本中吗？

更新：实际上，本书假设iss53工作已完成，并进行最后一次合并。但是如果iss53上的工作还没有完成，我们想要在热修复中合并呢？

Answer 1

@动静能量，

在这种情况下，您有三种选择：

1. cherry-pick hotfix提交iss53
2. 将master合并到iss53
3. 将iss53重新定位到master

就个人而言，我更喜欢＃3。因为它提供了更清晰的历史。

但是，如果你有太多的开发人员（比如linux），＃2可能会更容易。这应该是罕见的。在这种情况下，请确保将master合并到稳定点（例如稳定点释放，而不是某些随机测试状态），因此历史记录不会太复杂。

LWN an article详细讨论了这一点。

Answer 2

如果iss53上的工作尚未完成但您需要此修补程序，则可以master合并到iss53，或者iss53在{{{{}}之上。 1}}。

合并：

master

Rebase（你将在本章后面讨论）：

git checkout iss53
git merge --no-ff master # --no-ff keeps the master tip where it is