家里有俩娃，一个写作业要用电脑，一个做项目也抢设备。我和表弟最近一起维护一个家庭记账的小程序，他改功能，我加界面，结果一合并代码，Git就报一堆冲突，搞得像吵架现场。
冲突不是故障，是常态
很多人以为Git冲突是操作失误，其实只要两个人动了同一段代码，冲突就躲不掉。比如我昨天改了登录按钮的颜色，表弟同一天优化了登录逻辑，都改了login.js的第25行，一提交，Git就不知道该听谁的。
这时候Git会标记出冲突区域，让你手动决定保留哪部分，或者两边都留一点。
怎么看出冲突来了？
执行git pull或git merge的时候，如果看到这种提示：
Auto-merging login.js
CONFLICT (content): Merge conflict in login.js
Automatic merge failed; fix conflicts and then commit the result.那就说明冲突了。打开文件，你会看到类似这样的内容：
<<<<<<< HEAD
backgroundColor: '#007bff',
=======
backgroundColor: '#28a745', // 表弟改成绿色
>>>>>>> feature/new-login上面那段是当前分支的修改，下面那段是别人提交的内容。中间用=======隔开。
手动解决也不难
我一般直接打开文件，看看两边改的是啥。如果是颜色问题，我就问问表弟：你是想表达成功登录的意思才用绿色？那我觉得可以接受，就把我的删了，留他的。
改完后记得删掉那三行标记符——<<<<<<<、=======和>>>>>>>，然后保存。
接着执行：
git add login.js
git commit -m "修复登录按钮颜色冲突"提交完就恢复正常了。
提前预防更省心
现在我们家定了个规矩：每天晚饭前发明天要改的文件清单，谁碰config.json这类公共文件，得在群里喊一声。小改动直接提，大调整先拉分支。
比如我要重构首页，就先建个新分支：
git checkout -b refactor/homepage表弟继续在main上修bug，互不干扰。等我测好了再合并，冲突概率小多了。
Git冲突检测不是为了找麻烦，而是帮我们看清协作中的“重叠地带”。就像家里两个孩子抢遥控器，定好规则，轮流来，日子就好过多了。