git 合并操纵历史

git merge manipulates the history

在我们的团队中,常规程序是当我们有一个重要的功能时,我们在功能分支上工作。
时不时地 - 我们从 master 合并到功能分支,当我们准备好时 - 我们合并回 master (通常通过拉取请求)。

问题是在合并后提交历史是混合的 - 我们没有简单的方法来回退分支合并操作,以排除分支以防我们发现它有问题。

我们正在考虑一些备选方案:

  1. 而不是将 master 合并到功能分支 - 在 master 之上重新设置分支的基线,以便功能提交出现在日志的最后。
    这将简化它的删除,但如果有人不遵守此规则,我们仍然会遇到同样的问题)

  2. 与其将分支合并回 master,不如将功能分支重新设置在它之上。这可能意味着我们不能再使用拉取请求。

  3. 每天有一个脚本标签大师。
    由于我们需要排除一个已经合并的分支的情况非常少见——我们可能可以一个一个地检查和考虑从昨天开始的提交。这听起来很老套,但它并不妨碍我们目前在这里做事的方式

这里的最佳做法是什么?

instead of merging the branch back to master - rebase the feature branch on top of it. this will prםbably mean we can no longer use pull requests.

是的,在强制将你的 rebased 分支推送到你的 fork 之后,你将能够使用 PR。
拉取请求能够跟随分支历史的多次重写。

请注意,此处 1 与 2 出奇地相似:"rebase the branch on top of master" 与 "rebase the feature branch on top of it (master)"。

但无论如何,在 PR 之前,在 master 之上的 rebase 功能是首选的工作流程。