git merge前必须先git pull origin main，否则推送失败或他人拉不到代码；正确顺序为git checkout main → git pull origin main → git merge feature。

合并分支到主干（main 或 master）不是“切过去 merge 就完事”，漏掉同步远程最新状态这一步，90% 的推送失败和同事拉不到代码都源于此。

git merge 前必须先 git pull origin main

很多人执行 git checkout main && git merge feature 后发现 git push 报 non-fast-forward，或者别人 git pull 后主线没变——根本原因是本地 main 分支还停在旧提交上，压根没拿到远程最新内容。

• git merge 只合并你当前工作区已有的提交历史，它不会自动联网拉取远程变更
• 正确顺序必须是：git checkout main → git pull origin main → git merge feature
• 如果远程主干叫 master，就把所有 main 换成 master；别凭印象硬写
• 执行完 git pull origin main 后，用 git log --oneline -n 3 对比 origin/main，确认 HEAD 真的对齐了

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

选错命令会直接影响历史可读性、回滚成本和协作体验，不是风格偏好问题，而是场景适配问题。

Conventional Git

Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。

下载

• git merge feature：保留 feature 上全部提交记录，适合长期迭代、多人协作的功能分支；后续 git blame 或 git revert 可精确定位
• git merge --squash feature：把 feature 所有改动压缩成一个暂存状态，需手动 git commit -m "..."；适合一次性修复、CI/CD 自动化 PR 场景，主线历史干净
• --squash 不会自动生成提交，忘记 git commit 就等于什么都没合并，git status 会显示大量 modified 文件
• 用 --squash 后再删 feature 分支，git branch -d feature 会报 “not fully merged”，这是正常行为，别慌

git fetch --all 不能代替 git pull origin main

git fetch --all 只下载远程所有分支的最新引用（origin/main、origin/dev 等），但不会更新你的本地 main 分支指针——它只是“看见”了新提交，还没“拉进来”。

• 执行 git fetch --all 后，git branch -vv 可能看到 [origin/main: behind 2]，说明本地 main 落后，但分支本身没动
• 要真正同步，仍需 git checkout main && git merge origin/main（或 git rebase origin/main）
• 不存在 git pull --all；网上那些一键脚本批量 pull 所有本地分支，极容易在未暂存修改时中断，或误把 main reset 成 origin/dev
• 如果本地 main 从没设过上游，git pull 会报 “There is no tracking information”，此时必须先 git branch --set-upstream-to=origin/main main

冲突文件里删

冲突标记不是注释，是 Git 解析合并状态的锚点。删一半、留一半，Git 会认为冲突未解决，git add 失败，甚至提交后文件里还残留 字符串。

• 必须完整删除三段：从 开始，到 <code>=======，再到 >>>>>> feature 结束
• 删完后检查文件是否逻辑通顺，尤其注意 if/else、函数闭合、JSON 格式等易出错位置
• 改完一个文件，立刻 git add 文件名；别等全改完再统一 add，容易漏
• 不确定改得对不对？用 git diff --ours 和 git diff --theirs 分别看两边原始内容

最常被跳过的其实是「确认本地 main 是否真同步了远程」这一步——它不报错、不卡住，但只要没做，后面所有操作都在旧基线上运行，合并、推送、测试全可能白忙。