发布后重置开发和暂存分支

Question

在讨论实际问题之前，我会给出一些背景信息：我是唯一一个从事项目的开发人员，除了所有功能/*和修补程序/*之外，我还有

main

、

develop

和

staging

分支我在开发过程中可能会拥有这些。

分支之间的集成是通过使用 GitHub 的拉取请求进行的，其中一些是通过合并提交进行的，另一些是通过挤压提交进行的，所以结果是分支变得非常混乱。例如，我刚刚将 staging 合并到

main

，然后将

main

更新（合并）为

develop

和

staging

。由于我是唯一的开发人员，我知道此时所有三个分支的内容是相同的，但提交方面却不同：

develop

和

staging

都比

main

提前了382次提交。

当我通过从

staging

检出的分支创建对

develop

的拉取请求时，拉取请求仅显示有关功能本身的提交，这很好。但是，当我通过

main

创建对

staging

的拉取请求时，会显示许多与此请求无关的提交（因为它们是来自

develop

和

staging

的提交，但不在

main

中） ）并使代码审查变得混乱，变更日志管理也变得混乱。

对我来说（如果我错了，请纠正我）完美的场景是

main

、开发和

staging

具有完全相同的内容和提交计数（即，开发和

staging

显示 0|0前方/后方

main

）。我可以从

develop

删除并重新创建

staging

和

main

分支，但是（这是第一个问题）有没有办法重置

develop

和

staging

分支而不重新创建它们？

第二个问题有点明显：您认为哪种方式处理以下拉取请求以在未来保持干净的情况是最干净的？。我认为任何基于合并的解决方案都将至少包含一次提交，所以也许答案会通过 rebase。

Answer 1

它搞砸的原因是因为你没有创建real合并。当您进行挤压合并时，original分支并未真正合并到目标分支中，因此如果您稍后尝试再次合并，那些已合并（在挤压中）的相同更改将会显示 （因为它们没有真正合并，对吧？）.....所以，当你想在这3个分支之间合并时，做真正的合并。

经验法则是这样的：不要合并挤压长寿的分支。例如，当您想要合并功能分支时，squash 就很好，因为您不会从原始功能分支开始。比如说，它已经达到了停产状态。但是，长期存在的分支do需要在合并时保留按顺序合并的提交。 然后....如果你想让这两个分支与主分支（内容和

历史）相同，只需移动分支指针（记住：在git中，分支只是指向提交的指针......它们可以是四处走动）：

git checkout main
git pull # get the latest from remote main
git push -f origin main:develop main:staging

现在所有 3 个（远程）分支都指向同一个提交。当地的分支机构，您也需要移动它们：

git branch -f staging main
git branch -f develop main

现在一切都同步了。