假设我有各种标签/版本，1.0、1.0.1、1.0.2、1.0.3。Master 分支目前处于前沿，正在为 1.1.0 做准备。
我现在意识到我需要推送一个小补丁，1.0.4。
制作基于 1.0.3 的补丁、将其推送到 github、将其标记为 1.0.4，但仍然保持 master 分支处于前沿并为 1.1.0 做准备的最佳方法是什么？
编辑：有问题的存储库（注意，它实际上是 v1.0.5 -> v1.0.6）： https: //github.com/brashrebel/render
我想说你有两种可能性：一种将 1.0.4 作为悬空提交留在自己的分支中，另一种将所有以后的提交重新定基到该新分支之上，然后丢弃它。
第一个意思是：
$ git checkout v1.0.3
$ git checkout -b patch-for-1.0.4
# ... edit files ...
$ git commit -a -m 'Patch for 1.0.4'
$ git tag v1.0.4
此后，您的标签v1.0.4不在master分支中，但可以在存储库中找到它，并且您可以从中发布版本。你只需小心不要移除树枝即可patch-for-1.0.4。
第二个意味着执行上述操作，然后继续：
$ git checkout master
$ git rebase patch-for-1.0.4
# ... solve conflicts ...
$ git branch -d patch-for-1.0.4
这假设从 1.0.3 到 1.1.0 的所有提交都已在 master 上完成。如果您预计会出现很多冲突，您可能需要首先在主分支上进行测试，或者进行变基--interactive。
第二种选择更干净，您可以删除patch-for-v1.0.4分支；但这需要将旧的提交重新建立在新的提交之上，并不是每个人都觉得这样做很舒服，特别是如果您在团队中工作的话。
编辑：
这是你的起始情况：
A -------- B - C - D ( ... will become v1.1.0)
(v1.0.3)
第一个片段创建一个补丁并将其作为悬空提交保留在自己的分支中：
A -------- B - C - D
\
--- E
(v1.0.4)
如果此时进行合并，您将得到：
A --------- B - C - D --------- E
(v1.0.3) (v1.1.0) (v1.0.4)
为了避免E将其放在提交之上B - C - D，请进行变基：
A --------- E ------- B' - C' - D'
(v.1.0.3) (v1.0.4) (v1.1.0)
请注意，此更改提交B - C - D到B' - C' - D'，它们具有相同的内容（冲突修复除外），但具有不同的哈希值，因为它们现在位于 之上E，而不是 之上A。这可能会破坏master团队中其他人的分支或他们的功能分支，但会保持逻辑顺序。