为何Git合并修改了文件的分支到master分支时未触发预期的合并冲突？

嘿，这个问题其实是对Git合并逻辑的典型误解，我来给你掰扯清楚～

首先得明白**快进合并（Fast-forward merge）**的本质：当你要合并的目标分支（这里是master）在创建待合并分支（branch1）之后，没有任何新提交，Git就会直接把目标分支的指针向前移动，追上待合并分支的最新提交——这本质上根本不是“合并两个不同修改”，只是单纯移动分支指针而已，自然不会产生冲突。

咱们回头看你的操作流程：

• 你在master分支完成第一次提交（commit A），此时master的HEAD指向commit A
• 基于commit A创建branch1，在branch1里修改fileA.txt并提交（commit B），此时branch1的HEAD指向commit B，且commit B的父提交就是commit A
• 切回master后，master的HEAD依然停留在commit A，没有任何新改动

这种情况下，Git判断master完全可以直接“追上”branch1的进度，所以执行了快进合并，直接把master的指针移到commit B，相当于你在master上直接做了commit B的修改，自然不会触发冲突。

那什么时候才会触发合并冲突呢？得让两个分支都产生独立的新提交才行。比如你调整一下操作步骤：

# 创建项目目录
mkdir projA
cd projA
# 初始化Git仓库
git init
# 在master分支提交
echo "text 1" > fileA.txt
git add .
git commit -m "commit A"
# 在新分支提交
git checkout -b branch1
echo "text 2" > fileA.txt
git add .
git commit -m "commit B"
# 切回master，新增一个独立提交
git checkout master
echo "text 1 modified" >> fileA.txt
git add .
git commit -m "commit C"
# 现在合并branch1到master
git merge branch1

这时候master有commit C，branch1有commit B，两个分支都基于commit A做了不同的修改，Git没办法直接快进，只能尝试整合内容，这时候因为fileA.txt在两个分支里都被修改，就会触发合并冲突啦。

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