在日常开发中，把不同分支的代码整合到一起是最常见的操作之一。很多新手看到命令行里的报错就会慌，其实只要掌握基础流程，合并分支就像拼图一样简单。本文不讲晦涩的理论，直接上实操步骤，帮你快速搞定代码合并。
合并前的必要检查
动手合并前，先确保你的工作区是干净的。如果有没提交的修改，建议先用 stash 命令暂存起来，或者老老实实提交掉。打开终端，输入 git status 查看当前状态。确认无误后，切换到你要接收代码的主分支，通常是 master 或 main。用 git checkout main 完成切换。这时候你的本地仓库已经站在主线上，准备迎接新代码了。
执行基础合并命令
切换到位后，直接运行 git merge 分支名。这里的分支名换成你想并入主线的功能分支名称，比如 git merge feature-login。Git 会自动尝试将两个分支的改动融合在一起。如果两边改的是不同文件，或者同一文件的不同行，Git 会秒级完成自动合并，并生成一个新的合并节点。此时输入 git log --oneline 就能看到清晰的分支交汇记录。
遇到冲突怎么解决
自动合并失败不代表代码有问题，只是说明你和同事在同一个文件的同一位置都改了东西。这时候终端会明确提示哪些文件出现了冲突。用编辑器打开这些文件，你会看到类似 <<<<<<< HEAD 和 ======= 这样的标记。上面是你的代码，下面是别人的代码。你需要手动判断保留哪部分，或者把两部分拼在一起。删掉冲突标记后，把文件重新加入缓存，再用 git add 文件名 提交。最后输入 git commit 完成冲突解决，整个合并就彻底结束了。
merge 和 rebase 的区别选择
很多团队还会提到 rebase 命令，它看起来也能达到合并的效果，但底层逻辑完全不同。merge 会在历史里留下一个真实的交汇点，保持时间线真实，适合公共分支。rebase 则是把分叉的提交重新排列，让历史记录变成一条直线，看起来非常干净，但会改写提交历史，通常只在个人特性分支上使用。日常协作中，除非项目规范明确要求，否则优先使用 merge，安全系数更高。
合并后的收尾工作
合并成功并不意味着任务结束。务必跑一遍自动化测试，或者在本地环境启动项目验证核心功能是否正常运行。确认没问题后，把主分支推送到远程服务器，同步给团队成员。如果是通过拉取请求完成的合并，记得在平台上关闭对应的关联分支，避免后续重复提交。养成随手清理无用本地分支的习惯，能保持仓库整洁，减少后续查找的麻烦。
常见避坑指南
新手最容易踩的坑就是忘记切换分支直接合并，结果把别人的代码混进自己的特性分支里。另一个高频错误是在合并中途强行中断，导致工作区处于未完成状态。如果遇到这种情况，直接用 git merge --abort 回滚到合并前的样子即可。另外，大型项目的合并最好避开周五下午，留出足够的时间处理突发问题，别把进度压力带到周末。
掌握这些步骤后，你会发现代码管理其实没有想象中复杂。多练几次就能形成肌肉记忆，以后面对复杂的分支策略也能从容应对。把工具用在刀刃上，才能让开发效率真正提上来。
