original文章非常明确地说明了如何使用真正的合并。鉴于你的链接Atlassian文章没有提到南瓜，我要说的是，没有现有的优先权。
此外，在这种工作流中使用挤压合并绝对没有好处，但有严重的缺点，可能不切实际。

• develop和gang也是永恒分支，所以通过挤压合并到master中不会保存空间（除了每次master提交时少一个父指针）
• 真正的合并（因为它们有父代）可以直接找出master与develop的关系。随着挤压合并，两个历史变得完全分离。然后，怀疑开始恶化：我真的“squash merge”到master正确吗？或者是不同步。develop？
• 您还需要将hotfix和release分支合并到master中。啊

在我看来，请记住，这只是一个观点，你可能会得到不同的答案，你不应该在从开发分支合并到master分支时压缩提交。这样做会丢失很多已经做出的改变的历史。例如，我所做的几乎所有提交都标有问题号，这样就可以通过git历史记录完整地追溯到所提出的问题，以及为什么要进行更改。
更重要的是，您不应该直接将develop合并到master。假设你正在使用git-flow，那么这个转换应该通过发布分支完成。
如果你问是否，当在一个特性或热修复分支上时，提交应该被压缩，那么这将是一个不同的答案。在这些情况下，可以说分支应该足够小，以保证只有一个单一的提交，所以在这些情况下，我几乎总是在合并到目标分支之前，将提交转换为一个单一的提交。

master分支用于维护发布的记录，因此每个提交都应该代表来自组成发布构建的开发分支的一组压缩的更改。
压缩提交可以更容易地查看发布中的更改，并在必要时从发布提交创建热修复分支。用发布版本号标记每个压缩的提交。

如果你压缩了develop、release分支和master之间的合并，那么很难在没有文件冲突的情况下将发布分支的更改合并回develop。也很难合并一个修补程序到开发，然后通过发布将开发合并回主版本。