Git分支误判已合并提交问题求助（GitHub Actions CI/CD）

核心问题出在Squash合并的机制上：

• 每次执行Squash合并时，Git都会生成一个全新的提交，这个提交的哈希值由内容、提交时间戳、父提交、作者信息等多个因素共同决定。
• 你把同一个feature分支分别Squash合并到int、uat、main三个分支时，相当于在三个分支上各自创建了内容相同但元数据（比如父提交、合并时间）完全不同的提交，它们的哈希值自然不一样。Git只认哈希值，所以会认为这些是完全独立的变更，导致int和main分支的提交历史无法对齐，int会显示落后于main，后续合并feature/B时也会重复处理已有的变更。

结合你的Salesforce Org Development模型，推荐三种适配的调整方案：

方案1：改用Rebase合并，保持提交历史一致 #

调整工作流，放弃跨分支的Squash合并，统一使用Rebase合并长期分支：

• 所有feature分支基于main创建
• 合并到int时，使用Rebase合并（而非Squash），让int的提交历史和main完全对齐
• QA通过后，将int分支Rebase合并到uat
• UAT通过后，将uat分支Rebase合并到main
• 优势：所有长期分支的提交哈希完全相同，Git能准确识别已合并的变更，彻底解决分支落后和重复合并问题
• 注意：需要团队统一遵守Rebase合并规范，避免分支历史混乱

方案2：保留Squash，通过Cherry-pick同步变更 #

如果必须保留Squash合并的提交整洁性，可以调整变更同步方式：

• feature分支Squash合并到int，完成集成环境部署和QA
• QA通过后，将int上的Squash提交Cherry-pick到uat，而非从feature分支重新发起Squash PR
• UAT通过后，再将uat上的提交Cherry-pick到main
• 优势：同一个变更只生成一次Squash提交，后续通过Cherry-pick同步到其他分支，保证各分支上的变更哈希一致
• 注意：Cherry-pick可能会遇到冲突，需要及时处理，适合变更规模较小的场景

方案3：设置单向晋升的分支路径 #

调整分支晋升顺序，让变更只从下游往上游流动：

• 所有feature分支先合并到main（Squash或Rebase）
• 通过GitHub Actions自动将main的变更同步到uat，再同步到int
• 优势：完全保证所有长期分支的提交历史一致，自动化同步减少人工操作失误
• 注意：需要调整部署流程，确保生产环境的变更先验证再同步到测试环境，符合你的团队发布节奏

Git的提交哈希是全局唯一的，只要提交的任何元数据（比如提交时间、父提交ID、提交信息的空格）发生变化，哈希值就会改变。Squash合并每次都会生成新的父提交和时间戳，所以必然导致同一内容的提交哈希不同，这是Git的设计特性，无法绕过，只能通过调整工作流来适配。

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