GIT - 来自同一分支的拉取请求带来提交历史记录

Question

这是我的一个存储库中的设置：

• master 分支
• staging 分支（默认分支）

我们所做的每项更改都经过以下步骤。 假设我必须更改为readme.md。

1. 我从默认分支（staging）创建了一个新分支，我们称之为patch-readme
2. 我在patch-readme 中进行了我需要的所有更改。
3. 当我对自己的更改感到满意时，我会创建一个 PR 到 staging。
4. 我合并（压缩和合并）PR，然后删除patch-readme。
   • （注意：此时多个开发人员可以按照前面的步骤推送到staging 分支）
5. 然后将staging 分支部署到登台服务器。
6. 如果我对暂存服务器中的更改感到满意，我会创建一个从 staging 到 master 的新 PR。
7. 然后我查看更改并合并（压缩和合并）拉取请求。
8. 此时我将master 合并回staging。我这样做是因为如果 staging 的下一个 PR 更改了 readme.md 文件，当我创建从 staging 到 master 的新 PR 时，我会在该文件上遇到冲突。所以为了避免冲突，我会在每次合并 PR 后合并回 master。

这个工作流程有一个问题，基本上从staging 到master 的每个拉取请求都会带来几个月前的提交，这意味着存储库中的混乱（例如，如果有一个提交引用了一个问题，该问题将有一个很长的参考列表，每个新创建的 PR 都有一个）。

现在，我不明白的是，有时（我还没有弄清楚在什么情况下）历史会被清理掉。今天发生在我身上是因为开发人员在合并 PR 后忘记从 master 更新，我必须修复一些冲突，在修复冲突后新的 PR 有一个干净的历史记录。我试图复制这个场景，但它似乎没有做同样的事情。

我已经查看了 rebase，所以我在将 PR 从 staging 合并到 master 后尝试了什么，而不是合并回 master 我在 staging 上运行了 git rebase master分支。这不起作用，master 的下一个 PR 仍然有以前的历史记录。

有效的是，我没有为master 创建 PR，而是运行

git checkout master
git rebase staging

在这种情况下，我不需要做任何事情，并且下一次 PR 历史记录是干净的。但这没有多大意义，因为我们需要丢弃 PR。我们正在使用 PR 进行代码审查。

我做错了什么？从staging 到master，我如何才能在 PR 中每次都有干净的历史记录？

请注意，我们的开发人员通常只使用 Github 桌面 和 Github 网络界面。因为我们是一个小团队，所以每个人都可以创建 PR 并将其合并到 staging 和 master。

Answer 1

我找到了发生这种情况的原因。我们正在使用 GitHub Web UI 来合并 PR。

基本上每个发送到 staging 的 PR 都与“Squash and merge”合并。 从 staging 到 master 的 PR 以相同的方式合并。

通过使用“合并提交”而不是“压缩和合并”，暂存中的每个提交也会出现在主文件中（而不是使用 squash 的单个提交）。

所以，现在为了保持历史整洁，我们正在执行从功能分支到暂存的“压缩和合并”，同时我们正在执行从暂存到主分支的“合并提交”。

希望这对其他人有帮助。