我们的团队在过去两个月里一直在虔诚地使用挤压和合并，因为我们听说这是最佳实践。但最近发现我们用错了。
最初，我认为压缩和合并只是为合并中的提交创建了一个简洁的小包装器提交，但事实并非如此。它创建一个单独的、不相关的提交。因此，两个月后，即使我们的文件在“开发”和“主”分支之间同步，但提交却没有同步——因此我们的 PR 显示了在那段时间内实施的整套更改。不用说，这是“不可能”看的。 我们通过对“开发”和发布分支进行变基来解决这个问题（这真是一场噩梦），然后，为了确保它不会再次发生，在我们的 GitHub 管理设置中查找设置或配置以禁止挤压 -并在 master 上合并，但找不到。
鉴于该设置不存在，我的问题是：如果您使用 GitFlow，是否会有挤压并合并到“master”的用例？似乎这个函数只能在非永久分支和永久分支之间使用，而不能在两个永久分支之间使用。如果是这样，您是否需要一些步骤或配置来确保您的分支不会不同步？
但据我记得 - 您应该将更改从
feature分支压缩并合并到 develop 分支。这会为每个拉取请求创建一个单独的干净提交。 这是有道理的，因为功能工作是迭代的，拉取请求可以有多次迭代。 合并到主分支时，您不应该压缩更改。这让 git 明白提交是相同的。例如，这在修补程序的情况下非常重要。您可以仅将修复推送到主分支，然后需要合并回开发分支。
至于“小包装提交”，这不是它在 git 中的工作方式。每次提交都是一个快照，其中包括其整个历史记录。对历史记录的每次更改（例如 rebase 或 squash）本质上都是一次新的提交。