git rebase会省略哪些提交？变基提交匹配规则疑问

你对官方文档的直观理解是准确的：变基过程中，待变基分支里所有重放到目标分支上也不会产生任何实际内容变更的提交，都会被直接跳过，不会加入最终复制到新基线的提交序列。官方文档里提到的「上游已接收的补丁即使提交信息、时间戳不同也会跳过」，说的就是这个逻辑——Git比对的是提交引入的实际文本变更，不是提交元数据。

针对你提出的两个疑问，具体说明如下：

• 关于指定new_base参数时的匹配范围：确实会调整。当你手动传入新基线参数执行git rebase <new_base>时，Git用于匹配重复补丁的提交范围会从默认的HEAD..upstream切换为HEAD..new_base，整个重复提交检测逻辑会围绕你指定的新基线运行，和默认走上游跟踪分支的逻辑完全一致。
• 关于提交区间的表述原因：这是Git为了逻辑严谨、同时匹配内部实际运行逻辑做的精准表述，核心原因有两个：
  1. Git里A..B的提交范围明确定义是「所有从B出发可以回溯到、但从A出发回溯不到的提交」，默认变基场景下HEAD..upstream刚好框定了上游分支和当前分支分叉之后，上游独有的增量提交集合——这些才是可能和你本地待变基提交重复的内容。
  2. 如果直接表述为「和upstream内所有提交比对」，逻辑上是冗余的：upstream分支里包含了大量两个分支分叉之前的公共提交，这些提交的内容本来就是两边共有的，根本不需要纳入重复检测的范围。用区间表述可以精准框定需要比对的提交范围，既避免歧义，也符合Git实际计算时的性能优化逻辑，不会做无意义的全量提交比对。

官方规则原文参考：
此前保存到临时区域的提交会按顺序逐个重新应用到当前分支。注意：HEAD中所有与HEAD..upstream区间内提交存在相同文本变更的提交都会被省略（即：上游已接收的补丁，即使提交信息或时间戳不同也会被跳过）。

内容的提问来源于stack exchange，提问作者Houidi mohamed amin