Linux Git Merge 分支合并到主线操作详解

直接说结论：将 Git 分支合并到主线（main 或 master），并非一键完成。必须严格遵循四步流程——先确保本地主线代码是最新的，再切换到主线分支，然后执行合并操作，最后推送到远程仓库。缺了任何一步，结果要么是合并失败，要么是合并且推送后，远程仓库仍是一份过时的代码。

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，则改为 git pull origin master）。
• 最后，确认当前 HEAD 已是最新远程提交，可以使用 git log --oneline -n 3 对比本地和 origin/main 的提交记录。

git merge feature 和 git merge --squash feature 的区别

这两个命令都能将 feature 分支的改动合并到当前分支，但生成的提交历史截然不同。选错了会直接影响代码的可追溯性和团队协作效率。

简单来说：

• git merge feature：适合长期维护、多次迭代的功能分支。它保留分支上所有中间提交记录，方便日后回溯每一步修改细节。
• git merge --squash feature：适合一次性完成的功能、小修复或 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 status 查看哪些文件被标记为 “both modified”，即发生了冲突。
• 打开冲突文件，找到冲突块。你的任务是只保留最终想要的代码逻辑，将整个冲突块（包括三行标记以及中间的无用内容）完整删除或替换。
• 修改完成后，执行 git add 冲突文件名 将文件标记为已解决，然后 git commit。此时可不加 -m 参数，Git 会自动生成一个包含冲突解决信息的默认提交信息。
• 若不确定如何解决冲突，有两个快捷命令可以辅助：git checkout --ours 冲突文件 完全采用当前分支（ours）的版本；git checkout --theirs 冲突文件 完全采用合并进来分支（theirs）的版本。

git push origin main 失败的三个高频原因

本地合并成功，不代表代码已同步到远程。git push 失败通常不是权限问题，而是本地和远程仓库的状态没有对齐。

典型错误信息：

• ! [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），这是基本的保障。