git merge是将指定分支差异集成到当前分支，而非复制文件；必须先确认并切换至目标分支（如develop），再pull最新代码、执行--no-ff合并，冲突解决后需git add标记并提交推送。
合并代码分支不是“把文件拷过去”，而是让 Git 找到两个分支的共同祖先，再把差异集成进当前分支——操作前不确认当前分支，90% 的合并错误就已注定。
git merge 前必须确认当前分支
Git 总是把指定分支合入「当前所在分支」，而不是你心里想的那个目标分支。很多人执行 git merge feature-login 后发现代码进了 feature-login 分支，就是因为还在该分支上没切走。
安全做法永远是：先用 git status 看第一行提示，明确显示 “On branch develop” 或类似信息；再执行 git checkout develop 切过去，最后运行 git merge feature-login。
常见错误现象：
- 执行完
git merge后，git log里看不到新提交，反而发现feature-login分支多了一堆来自develop的提交（说明误在 feature 分支上反向合并） - 远程
develop没更新，但本地git status显示 “your branch is ahead by X commits”（本地合并成功但忘了 push）
合并前必须拉取目标分支最新代码
不更新就合并，等于拿过时的 develop 基线去集成新功能，极大概率引发重复冲突，或掩盖别人已修复的问题。
标准动作链（以合并到 develop 为例）：
git checkout develop-
git pull origin develop（不是git fetch+git merge，避免意外触发合并） -
git status确认输出 “nothing to commit, working tree clean”
如果本地 develop 有未提交修改，优先用 git stash 暂存，而不是 git reset --hard ——后者会永久丢弃未提交内容，且无法撤销。
GitHub Hosts 更新工具（仅限中国用户），安全更新系统hosts文件，保留原有非GitHub条目，仅替换GitHub相关地址。支持备份恢复和风险提示。用于解决GitHub访问问题。
merge 还是 merge --no-ff？选错影响追溯能力
默认 git merge feature-x 在无冲突且历史线性时会触发快进（fast-forward），只移动指针，不产生新提交；而 git merge --no-ff feature-x 强制生成一个带双父节点的合并提交。
团队协作中推荐始终加 --no-ff，原因很实际：
- 没有它，
git log --oneline看不到哪次提交是一次“集成动作”，所有 feature 提交平铺在时间线上，无法区分开发与合入边界 - 审计或回滚时，
git revert -m 1 <merge-commit></merge-commit>可精准撤销整个分支集成，而快进合并只能逐个 revert 子提交，极易漏掉 - CI/CD 流水线依赖合并提交触发构建，快进模式下可能跳过某些检查环节
所以固定写法应为：git merge --no-ff -m "merge feature-user-login into develop" feature-user-login
冲突解决后必须 git add，否则 commit 会失败
Git 不会自动标记冲突已解决。你在文件里删掉 、<code>=======、>>>>>> feature-user-login 这些标记只是第一步；真正让 Git 认可解决完成的动作，是 git add <file></file>。
最容易被忽略的点：
- 改了 5 个文件有冲突，只
git add了其中 3 个 →git commit报错 “fix conflicts and run git commit” - 用 IDE 自动解决冲突但没触发
git add→ 界面显示“已解决”，命令行仍卡在 unmerged 状态 - 解决完以为万事大吉，直接
git push→ 推送失败，因为本地还没 commit
最稳妥的收尾流程：解决全部冲突 → git status 确认无 “Unmerged paths” → 对每个冲突文件执行 git add <file></file> → git commit（消息由 merge 自动生成，无需手写）→ git push origin develop。
