Question

假设我有各种标签/版本，1.0,1.0.1,1.0.2,1.0.3。硕士分支目前是最前沿，准备1.1.0。

我现在意识到我需要推送一个小补丁，1.0.4。

什么是基于1.0.3制作补丁的最佳方法，将其推送到github，将其标记为1.0.4，但是仍然保持主分支处于最前沿并准备1.1.0？

编辑：有问题的存储库（注意，它实际上是v1.0.5 - ＆gt; v1.0.6）：https://github.com/brashrebel/render

Answer 1

您可以查看要基于修补程序的提交。您可以执行必要的操作，创建提交，标记结果并推送。为了让它们进入你的主线，你可以选择那些提交或合并分支。

现在，如果新标签不在分支上，可能会有点尴尬。我当然从未见过只能通过标签访问的分支。所以我个人的建议是将分支合并回来。

更具体一点：

$ git checkout -b v1.0.5_fixes v1.0.5    # create a bugfix branch
# ... do some work ...
# ... make commits ...
$ git tag v1.0.6
$ git checkout master
$ git merge v1.0.5_fixes     # merge back, solve merge conflicts if any
$ git branch -d v1.0.5_fixes # delete the branch, it's not needed anymore

Answer 2

我想说你有两种可能性：一种是将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 rebase。

第二种选择是更清洁，你可以删除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提交之上，请执行rebase：

A --------- E ------- B' - C' - D' (v.1.0.3) (v1.0.4) (v1.1.0)

请注意，此更改会将B - C - D提交到B' - C' - D'，它们具有相同的内容（冲突修正除外），但会有不同的哈希值，因为它们现在位于E之上，而不是A。这可能会破坏团队中其他人的master分支或其功能分支，但会使事情按逻辑顺序排除。

修改Github上的旧版本以推出补丁

2 个答案: