git merge与git rebase核心区别在于：merge保留三方历史并一次性解决冲突，生成合并提交；rebase重写历史、线性化分支，将冲突拆分为多次逐个解决，但会改变提交哈希、影响协作安全。

合并冲突不是故障，而是团队并行开发的自然信号。关键不在于“避免”，而在于让冲突可预测、可定位、可快速收口——这依赖分支节奏、提交粒度和解决动作三者的配合。

为什么 git merge 常报 conflict，但 git rebase 看似“没冲突”

本质差异在合并策略：git merge 保留三方历史（base + ours + theirs），冲突标记直接暴露分歧点；git rebase 是把当前分支所有提交“重放”到目标分支最新提交之后，每次重放都是一次微型合并，冲突会逐个出现、逐个解决——看似“没一次性冲突”，实则把大冲突拆成多个小冲突，对新手反而更难定位上下文。

团队项目中，除非明确采用 Trunk-Based Development（TBDD）且全员高频 push，否则不建议用 rebase 替代 merge。原因：

• rebase 会改写提交哈希，破坏 feature/* 分支的原始历史，CI/CD 流水线或代码审查记录可能失效
• 多人基于同一 feature 分支继续开发时，rebase 后强制 push --force-with-lease 容易覆盖他人本地提交
• 冲突发生在“重放第3个提交时”，你得同时理解 base 提交、第1/2个提交的意图，认知负荷更高

冲突文件里看到 到底该删哪块？

别凭感觉删。先确认三件事：

• 用 git log --oneline -n 5 看当前分支（HEAD）最近5次提交，确认你正在解决的是谁的改动
• 用 git log --oneline --merge 查看本次合并涉及的两个分支各自新增了哪些提交
• 打开冲突文件，对照 git blame <file></file> 看每行代码最后是谁改的、在哪次提交里——尤其注意冲突区域是否混入了未评审的调试代码或临时注释

真正要保留的，不是“谁写的”，而是“哪个逻辑符合当前需求”。例如两段都改了 user.validate() 调用，但一个加了邮箱校验、一个加了密码强度校验，正确做法是合并校验逻辑，而不是二选一。

batch-git-url-replace

批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。

下载

多人在 develop 分支上直接提交，冲突后怎么救？

这是规范性风险，不是技术问题。此时优先止损，再重建流程：

• 立即暂停所有向 develop 的 push，用 git status 和 git fetch origin 确认远程 develop 当前 HEAD
• 每个开发者从远程拉取最新 develop，用 git stash 暂存本地未提交改动，再 git pull origin develop 同步
• 逐个 git stash pop 应用改动，遇到冲突就按前述方式解决——此时冲突范围可控，因为只涉及自己改动 vs 最新主干
• 修复完成后，立刻发起 Pull Request 到 develop，禁用直接 push 权限，强制走代码审查

后续必须落地分支隔离：新功能一律从 develop 切出 feature/[ID]-xxx，严禁在 develop 上直接编码。否则每次 pull 都像开盲盒。

CI 流水线里自动检测冲突失败，怎么办？

CI 报错如 CONFLICT (content): Merge conflict in src/api/client.ts，说明 PR 合并前未同步目标分支。这不是 CI 的锅，是本地操作遗漏：

• 在发起 PR 前，必须执行 git checkout develop && git pull origin develop && git checkout <your-feature-branch> && git merge develop</your-feature-branch>，手动触发并解决冲突
• 如果不想本地 merge，可在 GitHub/GitLab PR 页面点击 “Update branch” 按钮（需开启 auto-update 设置），平台会自动将 develop 合入你的 feature 分支
• 更彻底的方案：在 CI 脚本开头加检查 git merge-base --is-ancestor origin/develop HEAD || (echo "Branch is outdated, please merge develop first" && exit 1)

复杂点在于：很多团队把“解决冲突”当成 merge 的前置步骤，却忽略了冲突本质是“代码意图未对齐”。哪怕语法上能自动合并，逻辑上也可能埋雷——比如 A 改了支付超时时间，B 改了退款重试次数，两者都不冲突，但组合起来可能导致资金延迟到账。这类问题只能靠设计评审，Git 无能为力。