0

我想知道为什么在 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还没有完成，我们想合并到热修复中怎么办？

4

2 回答 2

0

@动静能量，

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

  1. cherry-pickhotfix承诺_iss53
  2. 合并master到iss53
  3. 重新定位iss53到master

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

但是，如果你有太多的开发人员（像 linux 那样），#2 可能会更容易。这应该很少见。在这种情况下，请确保您master在稳定点上合并（例如，稳定点发布，而不是一些随机测试状态），这样历史不会变得太复杂。

LWN 有一篇文章详细讨论了这一点。

于 2012-08-30T01:13:52.820 回答
0

如果工作iss53尚未完成，但您想要修补程序，您可以合并master到iss53，或（更好）iss53在master.

合并：

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

变基（你将在本章后面介绍）：

git checkout iss53
git rebase master
于 2012-08-30T01:17:08.930 回答