直接说结论：想把Git分支合并到主线（main或master），可不是点一下按钮就完事。必须老老实实走完四步——先确保本地主线代码是最新的，再切换到主线分支，然后执行合并操作，最后推送到远程仓库。这四步，任何一步缺失，结果要么是合并失败，要么就是你辛苦合并完，推上去的却是一份过时的代码。掌握这套Git分支合并流程，是团队协作中必备的基础技能。
git merge 前必须 git pull origin main
很多人合并完分支，发现远程仓库没更新，或者同事拉不到新代码，问题根源往往出在第一步：合并前没有同步主线的最新状态。Git的merge命令只作用于你本地工作目录的提交历史，它可不会自动帮你把远程的更新拉下来。想要成功合并分支到主线，这一步绝对不能跳过。
常见的翻车现场是这样的：
- 合并后，
git status显示“Your branch is ahead of 'origin/main' by 1 commit”，但执行git push时却报错“non-fast-forward”。 - 你以为合并推送成功了，结果同事一拉代码，发现主线纹丝未动。原来，你本地的
main分支还停留在一周前的提交上。
正确的操作姿势应该是：
- 首先，切换到主线分支：
git checkout main（或者用更语义化的git switch main）。 - 然后，拉取远程主线的最新代码：
git pull origin main（如果远程主干分支名叫master，这里就换成master）。执行git pull确保本地与远程保持一致，是Git merge操作的前提。 - 最后，确认一下当前HEAD确实是最新的远程提交，可以用
git log --oneline -n 3对比一下本地和origin/main的提交记录。
git merge feature 和 git merge --squash feature 的区别
这两个命令都能把feature分支的改动合并到当前分支，但它们生成的提交历史截然不同，选错了会直接影响代码的可追溯性和团队协作效率。了解git merge与git merge --squash的区别，能帮助你更灵活地管理分支历史。
简单来说：
git merge feature：适合那些长期维护、迭代多次的功能分支。它会保留分支上所有的中间提交记录，方便日后回溯每一步的修改细节，这对于需要精细审计的项目非常有用。git merge --squash feature：适合一次性完成的功能、小修复或者PR（Pull Request）场景。它会把整个分支的所有改动“压缩”成一个单独的提交，让主线历史看起来非常干净，特别适合保持主分支的简洁。
这里有几个关键点需要注意：
- 使用
--squash参数后，Git不会自动创建提交。你需要手动执行git commit -m “feat: xxx”，否则改动只会停留在暂存区。 --squash合并后，如果你尝试删除feature分支（git branch -d feature），Git可能会提示“branch not fully merged”。这是正常现象，因为squash操作并没有产生一个真正的合并提交（merge commit）。- 如果这个
feature分支后续还要继续开发新功能，那就别用--squash。否则，下次合并时可能会把已经合并过的改动又带进来，造成混乱。
合并冲突时不要直接删掉
遇到合并冲突，文件里会出现<<<<<< HEAD、=======、>>>>>> feature这些标记。记住，这些可不是普通的注释，它们是Git用来定位冲突块的“锚点”。如果只图省事，光删掉这三行标记而没清理掉它们包裹的冲突代码块，那么后续执行git add可能会失败，或者提交后文件里依然残留着冲突标记。正确解决Git合并冲突的方法至关重要。
正确的处理流程应该是：
- 先用
git status查看哪些文件标为“both modified”，即发生了冲突。 - 打开冲突文件，找到冲突块。你的任务是只保留最终想要的代码逻辑，把整个冲突块（包括三行标记以及它们中间的无用内容）完整地删除或替换掉。
- 修改完成后，执行
git add 冲突文件名将文件标记为已解决，然后git commit。这时可以不加-m参数，Git会自动生成一个包含冲突解决信息的默认提交信息。 - 如果对如何解决冲突没把握，有两个快捷命令可以救急：
git checkout --ours 冲突文件会完全采用当前分支（ours）的版本；git checkout --theirs 冲突文件则会完全采用合并进来分支（theirs）的版本。这两个命令能快速处理简单的冲突。
git push origin main 失败的三个高频原因
本地合并成功，不代表代码就同步到远程了。git push失败，很多时候不是权限问题，而是本地和远程仓库的状态没有对齐。了解git push origin main失败的常见原因，能帮你快速定位问题。
典型的错误信息包括：
! [rejected] main -> main (non-fast-forward)：这通常意味着你本地的main分支不是基于最新的远程origin/main分支进行开发的。第一步的git pull origin main很可能被漏掉了。error: failed to push some refs to 'xxx'：这可能是在你合并的过程中，已经有其他人往远程主线推送了新的提交。你需要先执行git pull --rebase origin main，将你的提交“变基”到最新的远程提交之上，然后再尝试推送。- 什么错误都没报，但远程代码就是没更新：检查一下你是不是推错了分支名。比如远程主干叫
main，你却输成了git push origin master。
为了确保推送安全，可以养成这些习惯：
- 推送时使用完整形式：
git push origin main:main（冒号前是本地分支名，后是远程分支名），这样意图最明确，避免误推。 - 用
git branch -vv命令检查分支的追踪关系，确保你的main分支后面显示的是[origin/main]。 - 如果不确定远程状态，可以先
git fetch origin获取所有更新，然后对比origin/main的提交SHA和你本地main分支的是否一致。
最后，也是最容易被忽略的一点：Git只负责合并代码和版本管理，它可不会帮你验证合并后的代码是否能编译通过，或者测试用例是否全部跑通。即使merge和push都成功了，也不代表功能就一定是可用的。尤其是在涉及多人协作的公共模块时，上线前至少要在本地执行一遍构建（比如make）或测试（比如npm test），这是最基本的保障。遵循完整的Git分支合并到主线四步流程，并注重后续验证，才能确保团队协作顺畅。
