Git技巧：如何判断特性分支的变更是否已存在于dev分支

嘿，这个场景我太熟悉了——我们团队也在用类似的Git工作流，经常需要确认特性分支的所有变更是不是已经通过变基、压缩合并等方式进入dev分支，避免做无用的空合并。你之前用merge --no-commit的方法虽然准确，但确实有点繁琐，Git其实有更简洁的方式解决这个问题！

方法1：用三点Diff快速验证变更是否已被包含 #

不需要切换分支，在任意工作目录下执行这条命令就能判断：

git diff dev...my-feature

原理说明 #

dev...my-feature这种三点语法的Diff，会先找到dev和my-feature的最近共同祖先提交，然后对比my-feature相对于这个祖先的所有变更，是否已经完全被dev分支包含。如果命令输出为空，就说明my-feature的所有修改都已经存在于dev中，此时合并会产生空提交；如果有输出内容，就代表还有未合并的变更（或者冲突需要处理）。

方法2：用merge干跑模式直接确认合并结果 #

如果你想更直观地看到合并的预期结果，可以切换到dev分支后执行干跑合并：

# 先确保本地dev是最新的
git checkout dev
git pull origin dev

# 模拟合并，不会修改任何文件
git merge --dry-run my-feature

结果判断 #

• 如果输出Already up to date.，说明my-feature的变更已完全在dev中，合并会是空提交；
• 如果输出了合并提交的相关信息，说明有未合并的变更；
• 如果提示冲突信息，说明合并会产生冲突，需要手动处理。

为什么比你原来的方法更优？ #

这两种方法都不需要修改工作区或索引，也不需要手动终止合并操作，全程只读操作，不会污染你的工作状态。而且方法1甚至不需要切换分支，在特性分支上就能直接验证，效率高很多。

注意事项 #

• 执行前一定要确保本地dev分支是远程的最新版本，避免因为本地缓存的旧代码导致判断错误；
• 如果dev分支在特性分支开发期间有大量其他变更，这两个方法依然能准确识别当前特性分支的变更是否被包含，完全符合你“忽略dev其他变更”的需求。

内容的提问来源于stack exchange，提问作者Matt R. Wilson