运行git merge --squash提交消息时，包含我正在压缩的所有提交的提交消息，太好了。然而，出于某种原因，它实际上包含的不仅仅是我正在压缩的提交。
这是我的工作流程：
git merge --squash从开发到登台。问题是第 2 步。每次我尝试进行壁球提交时，提交消息都包含至少半年以前的所有提交（从我从 master 分支开发开始），尽管我已经将它们合并到以前的壁球提交中. 我手动修剪了除相关之外的所有内容，但至少有两次我忘记了这样做，最终得到了一个荒谬笨拙的提交消息。
我从文档中看到的似乎暗示git merge --squash不应该这样做，并且应该聪明地猜测我正在压缩哪些提交。我一直无法找到它是如何做到这一点的解释，所以我可以弄清楚出了什么问题/如何解决它。
我该如何解决？如果它不能直接修复，是否有我可以使用的替代工作流程，它会给我一个具有完整历史记录的分支和一个具有合并提交的分支，这些提交引用回它们来自哪里？
添加更多细节：
we'll call common parent 0
feature branch one: 0-A - B - (merge to development, delete branch)
feature branch two: (development from point D) - E- F (merge to development, delete branch)
development: 0-A - B ------------------------------D- E - F-------------
|(source, NOT parent) /(merge from staging) \
staging: 0 --- 1st squash merge(C) - D(version tag) - 2nd squash merge(G) - H (version tag)
第二次壁球合并提交了 A、B、C、D、E、F，而不仅仅是记录在其中的 E、F
原始答案（见下面的更新）：
git merge --squash进行与git merge没有的常规分析相同的历史分析--squash。为此，它需要了解历史。但是--squash你过去所做的合并抹去了这段历史的重要部分。
事实上，如果笨拙的提交消息是您唯一的问题，那么您就很幸运了。我预计在被压缩合并的不同功能分支所触及的区域中会发生很多合并冲突。
一般来说，git merge --squash除非你知道后果，否则不要使用。它的主要目的（IMO）实际上只是将一系列混乱的提交减少到单个提交。如果您无论如何都在使用功能分支，则完全无法使用（再次是 IMO）。只需保持您的功能分支清洁并使用常规git merge.
更新：
我可以用这段历史重现你的观察：
0--A--B--M--E--F <-- development
\ /
C----D--G--H <-- staging
C是承诺的壁球合并B，即间的变化0和B，和G是承诺的壁球合并F，即之间的变化D和F。
让我们D成为 HEAD 提交。此时，当您git merge F（有或没有--squash）时，Git 确定一个合并基础，即D.
现在，如果没有--squash，Git 会发现这是一个快进的情况并将分支推进到F.
但是由于您提出了--squash，它在提交之前停止，但在更新工作树之后。它还规定了一个由 的输出组成的提交消息git log F ^HEAD，即可从 访问的所有提交F，但不包括可从 访问的提交HEAD。这些是A、B、M、E和F，如您在图中所见；这解释了为什么您在日志消息中看到这么多“不必要的”提交。
一个可能的解决方法是G'在M. 然后，你樱桃采摘G'到staging：
G' <-- temporary
/
0--A--B--M--E--F <-- development
\ /
C----D--G--H <-- staging
这应该为你工作，因为树木D和M应该是相同的。