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

Question

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

• master branch＆lt; - 这始终在生产服务器中
• staging分支（默认分支）＆lt; - 这是在登台服务器
中

我们所做的每项更改都要经过以下步骤。 我们要说我必须对readme.md进行更改。

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

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

现在，我不明白的是，有时候（我还没弄清楚在什么情况下）历史得到了清理。今天它发生在我身上，因为开发人员在合并PR之后忘记了从master更新而我必须解决一些冲突，在解决冲突之后，新PR有一个干净的历史。我试图复制这种情况，但似乎并没有这样做。

我看过rebase，所以我在将PR从staging合并到master之后尝试过，而不是合并回master我跑了在git rebase master分支上staging。这不起作用，master的下一个PR仍然有历史。

有效的是，我没有创建PR到master，而是跑

git checkout master
git rebase staging

在这种情况下，我没有做任何事情，而下一个PR的历史很干净。但这并没有多大意义，因为我们需要丢弃PR。我们正在使用PR进行代码审核。

我做错了什么？我怎样才能在staging到master的公关中获得干净的历史记录？

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

Answer 1

我发现了为什么会这样。我们正在使用GitHub网络用户界面来合并PR。

基本上每个发送到分段的PR都与＆＃34; Squash合并并合并＆＃34;。 从分段到掌握的PR以相同的方式合并。

使用＆＃34;合并提交＆＃34;而不是＆＃34;壁球和合并＆＃34;暂存中的每个提交也出现在master中（而不是使用squash进行单次提交）。

所以，现在为了保持历史的清洁，我们正在做一个＆＃34;壁球和合并＆＃34;从功能分支到暂存，我们正在进行＆＃34;合并提交＆＃34;从分期到掌握。

希望这对其他人有帮助。