Git推送非远程跟踪分支时提交数量显示错误的原因咨询

• 核心原因是远程主分支（RM）中被合入的f1，和本地功能分支（LF）上的f1不是同一个Git提交对象，两者的SHA-1哈希完全不同。
• 当初将远程功能分支（RF）合入RM时，使用了git merge --squash或者代码平台的「压缩合并」功能，该操作不会保留原提交的哈希，会把RF上的所有提交压缩为一个全新的提交写入RM，哪怕提交信息和f1完全一致，它也是独立的新提交。
• 后续拉取更新本地主分支（LM）拿到的是这个压缩生成的新提交，而本地LF上的f1还是原始的旧提交，两者没有继承关系。

• Git的每个提交都是不可变的对象，唯一标识是SHA-1哈希，哈希值由提交内容、父提交哈希、作者信息、提交时间等所有元数据共同计算得出，只要任何一项有差异，哈希就完全不同。
• 执行git push时，Git会先比对本地分支和远程目标分支的提交链，找到两者的最近公共祖先（LCA），所有在LCA之后的本地提交都会被纳入待推送列表。
• 当前场景下，远程目标分支的提交链是m1 - m2 - 压缩后的f1新提交 - x，而本地LF的提交链是m1 - m2 - 原始f1旧提交 - f2，两者的最近公共祖先是m2，所以Git会把m2之后的两个提交（原始f1、f2）都列入待推送列表。

从更新后的master新建分支并cherry-pick f2时，新分支的提交链是m1 - m2 - 压缩后的f1新提交 - x - f2，和远程主分支的最近公共祖先是x，所以待推送的只有x之后的f2一个提交，和观测到的现象一致。

内容的提问来源于stack exchange，提问作者Juan