跳到主要内容
Git Merge vs Rebase 底层逻辑、适用场景与操作指南 | 极客日志
Shell / Bash 大前端
Git Merge vs Rebase 底层逻辑、适用场景与操作指南 综述由AI生成 深入解析 Git Merge 与 Rebase 的底层逻辑与核心差异。Merge 保留完整历史分叉，适用于公共分支合并，确保协作安全；Rebase 重写历史使其线性化，适用于本地私有分支整理与同步。文章强调了核心红线：严禁对已推送的公共分支执行 Rebase 操作。提供了企业级分支管理、冲突处理及代码评审的最佳实践规范，帮助开发者根据场景选择合适的工具，避免常见误区。
修罗 发布于 2026/3/24 更新于 2026/5/20 几乎每个开发者每天都在和 Git 打交道，但分支合并时的核心问题——'到底用 Merge 还是 Rebase？'，却难倒了无数人。有人无脑用 Merge，导致仓库提交历史分叉成'蜘蛛网'；有人盲目跟风用 Rebase，结果重写了公共分支历史，把整个团队的协作流程搞崩。这两个命令的核心区别到底是什么？什么时候该用哪个？本文将从 Git 底层对象模型出发，讲透 Merge 和 Rebase 的本质，搭配实战示例，明确区分易混淆点，给出企业级可落地的最佳实践。
一、前置基础：Git 分支的底层核心逻辑
要彻底搞懂 Merge 和 Rebase，必须先理解 Git 的核心设计——Git 是一个基于快照的分布式版本控制系统，分支本质是指向提交对象的可变指针 。所有的合并操作，本质都是对提交对象和分支指针的操作。
1.1 Git 提交对象的核心结构
Git 中的每一次提交（commit），都是一个不可变的快照对象，包含 4 个核心信息，所有内容共同生成唯一的 SHA-1 哈希值：
tree 对象 ：指向当前提交的文件目录树快照，记录所有文件的内容和结构parent 对象 ：指向当前提交的父提交，也就是上一次提交的哈希值，初始提交无父对象作者信息 ：代码修改人的姓名、邮箱和修改时间提交者信息 ：执行提交操作的人的姓名、邮箱和提交时间
这里的核心关键点：只要提交的 parent、内容、元数据有任何一点变化，生成的 SHA-1 哈希值就会完全改变，变成一个全新的提交对象 。这是理解 Merge 和 Rebase 核心区别的关键。
1.2 分支的本质
Git 的分支，本质上只是一个指向某个提交对象的、轻量级的可变指针 。你创建一个新分支，本质只是创建了一个新的指针文件，里面存储了目标提交的哈希值，几乎没有任何性能开销。
而 HEAD 指针，本质是一个指向当前所在分支的指针，你切换分支，本质只是改变了 HEAD 的指向，然后把工作区更新为对应分支指向的提交快照。
这个底层逻辑，是所有 Git 操作的基础，接下来的 Merge 和 Rebase，都是基于这个核心逻辑实现的。
二、Git Merge 深度解析：完整保留历史的分支合并
Git Merge 的官方定义是：将两个或多个开发历史合并在一起 。它的核心设计目标是：在不修改现有提交历史的前提下，完成两个分支的合并，完整保留所有开发轨迹。
2.1 Merge 的两种核心合并模式
根据两个分支的提交状态，Git Merge 会自动选择两种合并模式：Fast-Forward（快进合并）和 Three-Way Merge（三方合并）。
2.1.1 Fast-Forward 快进合并
当你要合并的两个分支，满足一个前提：目标分支（比如 main）在你创建特性分支之后，没有任何新的提交 。此时两个分支的提交历史是线性的，Git 不需要生成新的合并提交，只需要把目标分支的指针，直接移动到特性分支的最新提交上，就完成了合并，这就是快进合并。
# 初始化 Git 仓库并配置用户信息
git init merge-rebase-demo
cd merge-rebase-demo
git config user.name "Demo User"
git config user.email "[email protected] "
# 主干分支初始提交（LCA 共同祖先）
echo "# Merge vs Rebase Demo" > README.md
git add README.md
git commit -m "chore: init project"
# 创建并切换到特性分支 feature/docs
git checkout -b feature/docs
# 特性分支提交新内容
echo "## Quick Start" >> README.md
git add README.md
git commit -m "docs: add quick start guide"
# 切回主干分支 main，此时 main 无新提交
git checkout main
#
执行快进合并
合并完成后，执行 git log --oneline --graph 查看提交历史，输出如下：
* 45f 8d21 (HEAD -> main, feature/docs) docs: add quick start guide
* a7c3d90 chore: init project
可以看到，main 分支的指针直接移动到了 feature/docs 分支的最新提交，没有生成任何新的合并提交，提交历史完全线性。
2.1.2 Three-Way Merge 三方合并 这是 Merge 最常用的场景，当两个分支满足：目标分支和特性分支，在分出之后都有了新的提交 ，此时两个分支的历史出现了分叉，无法执行快进合并，Git 会自动执行三方合并。
三方合并的核心逻辑，是 Git 会自动找到 3 个关键提交节点：
待合并的两个分支的最新提交 （main 的 HEAD 和 feature 的 HEAD）两个分支的最近共同祖先 LCA（Lowest Common Ancestor） 基于这 3 个节点，Git 会对比两个分支相对于共同祖先的差异，自动合并差异内容，最终生成一个全新的合并提交（Merge Commit） 。这个合并提交有一个特殊的结构：它有两个 parent 指针，分别指向两个待合并分支的最新提交，以此完整保留两个分支的开发历史。
# 基于上面的仓库，重置 main 分支到初始提交
git reset --hard a7c3d90
# 删除旧的特性分支
git branch -D feature/docs
# 重新创建特性分支
git checkout -b feature/login
# 特性分支第一次提交
mkdir src
echo "// user login core logic" > src/login.js
git add src/login.js
git commit -m "feat: add login core logic"
# 特性分支第二次提交
echo "// login input validation" >> src/login.js
git add src/login.js
git commit -m "feat: add login validation"
# 切回 main 分支，提交新内容，制造分叉
git checkout main
echo "// project base config" > config.js
git add config.js
git commit -m "chore: add base config"
# 执行三方合并
git merge feature/login
如果没有冲突，Git 会自动生成合并提交，并打开编辑器让你填写合并提交信息，默认信息为 Merge branch 'feature/login'。合并完成后，执行 git log --oneline --graph 查看历史，输出如下：
* 3f 7e2d1 (HEAD -> main) Merge branch 'feature/login'
|
| * 2 c8d3f4 (feature/login) feat: add login validation
| * 7 d9e4f5 feat: add login core logic
* | 5 a6b7c8 chore: add base config
|
* a7c3d90 chore: init project
可以清晰看到，提交历史出现了分叉，合并提交有两个父节点，完整保留了两个分支的所有开发轨迹。
2.2 Merge 的核心特性
绝对不修改现有提交历史 ：所有已存在的提交的哈希值、内容、父节点都不会有任何变化，只会新增合并提交，这是 Merge 最大的优势，也是协作安全性的核心保障完整保留开发轨迹 ：合并提交的双父节点结构，完整记录了分支的分叉和合并过程，可追溯性极强，方便后续排查问题和回滚冲突仅需解决一次 ：无论两个分支有多少差异，只需要在生成合并提交时解决一次冲突，操作成本低分支历史会出现分叉 ：多次合并后，提交历史会出现大量分叉，长期下来会变成'蜘蛛网'，可读性变差
2.3 Merge 的核心参数与高频用法
--no-ff：强制关闭快进合并，即使可以快进，也强制生成合并提交。这是企业级团队最常用的参数，能完整保留特性分支的开发轨迹，方便后续回滚和追溯，示例：git merge --no-ff feature/login--squash：压缩合并，将特性分支的所有提交压缩成一个新的提交，合并到目标分支，不会保留特性分支的提交历史，也不会生成双父节点的合并提交，适合清理临时分支的零散提交--abort：合并出现冲突时，终止合并操作，恢复到合并前的状态
三、Git Rebase 深度解析：线性化历史的变基操作 Git Rebase 的官方定义是：在另一个基础提交的顶端，重新应用一系列提交 。它的核心设计目标是：重新设置分支的基准节点，将分叉的提交历史线性化，保持提交历史的整洁可读 。
3.1 Rebase 的底层执行逻辑 很多人对 Rebase 的理解停留在'让提交历史变直'，但没有搞懂它的底层操作，这也是绝大多数坑的根源。
Rebase 的核心逻辑，拆解为 5 个不可拆分的步骤：
Git 自动找到当前分支与目标分支的最近共同祖先 LCA
提取当前分支中，LCA 之后的所有提交，将每个提交的差异内容生成临时补丁文件
将当前分支的指针，直接指向目标分支的最新提交（也就是重新设置分支的'基准'）
按照原始提交的顺序，逐个将临时补丁应用到新的基准节点上，每应用一个补丁，就生成一个全新的提交
所有补丁应用完成后，变基操作结束，当前分支的提交历史变成完全线性的结构。
这里的核心关键点，也是和 Merge 最本质的区别：Rebase 会重写提交历史，LCA 之后的所有原始提交都会被废弃，生成全新的提交，即使内容完全不变，提交的哈希值也会完全改变 ，因为新提交的父节点、元数据都发生了变化。
3.2 Rebase 基础实战示例 我们用和上面三方合并完全相同的仓库场景，来演示 Rebase 的操作，让你直观看到和 Merge 的区别：
# 基于之前的仓库，重置 main 分支到初始提交
git reset --hard a7c3d90
# 删除旧的特性分支
git branch -D feature/login
# 重新创建特性分支，和 Merge 示例完全一致的提交
git checkout -b feature/login
mkdir src
echo "// user login core logic" > src/login.js
git add src/login.js
git commit -m "feat: add login core logic"
echo "// login input validation" >> src/login.js
git add src/login.js
git commit -m "feat: add login validation"
# 切回 main 分支，提交新内容，制造完全一致的分叉
git checkout main
echo "// project base config" > config.js
git add config.js
git commit -m "chore: add base config"
# 切回特性分支，执行 Rebase 操作，目标基准是 main 分支
git checkout feature/login
git rebase main
如果没有冲突，Rebase 会自动完成所有补丁的应用，执行完成后，执行 git log --oneline --graph 查看特性分支的提交历史，输出如下：
* 8 d9e0f1 (HEAD -> feature/login) feat: add login validation
* 7 c6d5b4 feat: add login core logic
* 5 a6b7c8 (main) chore: add base config
* a7c3d90 chore: init project
可以看到，特性分支的提交历史变成了完全线性的结构，没有任何分叉，原本的两个提交，现在生成了两个全新的提交，哈希值和之前完全不同，它们的父节点变成了 main 分支的最新提交，相当于把特性分支的开发，'嫁接'到了 main 分支的最新提交之后。
此时，我们只需要切回 main 分支，执行快进合并，就能把特性分支的内容合并进来，不会生成任何合并提交，main 分支的历史也会保持完全线性：
git checkout main
git merge feature/login
* 8 d9e0f1 (HEAD -> main, feature/login) feat: add login validation
* 7 c6d5b4 feat: add login core logic
* 5 a6b7c8 chore: add base config
* a7c3d90 chore: init project
3.3 Rebase 冲突处理 Rebase 在逐个应用补丁的过程中，如果遇到冲突，会暂停当前的变基操作，提示冲突文件，此时你需要遵循以下正确步骤处理，90% 的开发者在这里都会操作错误：
打开冲突文件，手动解决所有冲突内容
解决完成后，执行 git add <冲突文件>，将修改后的文件加入暂存区
执行 git rebase --continue，继续应用下一个补丁，绝对不要执行 git commit
如果想中途放弃变基，恢复到变基前的状态，执行 git rebase --abort
这里必须强调：Rebase 的冲突是逐个提交处理的，如果你的特性分支有 10 个提交，可能需要解决 10 次冲突，这是 Rebase 的一个缺点；而 Merge 只需要解决一次冲突。
3.4 Rebase 的核心特性
提交历史完全线性化 ：彻底消除分支分叉，提交历史是一条干净的直线，可读性极强，方便后续代码评审、日志排查重写提交历史 ：会废弃原始提交，生成全新的提交，改变提交哈希值，这是 Rebase 最大的风险点无额外合并提交 ：不会生成 Merge Commit，避免了大量合并提交污染提交历史原子性提交可保障 ：配合交互式变基，可以整理零散的提交，确保每个提交都是原子性的，有明确的功能边界
3.5 Rebase 的高频进阶用法：交互式变基（git rebase -i） 交互式变基是 Git 提供的超强功能，也是企业级开发中最常用的 Rebase 场景，它可以让你在变基的过程中，修改、合并、删除、重新排序提交，彻底整理你的本地提交历史。
它的基础用法是：git rebase -i <目标提交>，其中目标提交是你要整理的提交范围的父提交，比如 git rebase -i HEAD~3，就是整理最近 3 个提交。
执行命令后，Git 会打开编辑器，列出你要整理的所有提交，每个提交前面有一个操作命令，默认是 pick，你可以修改命令来实现不同的操作，核心命令如下：
命令 缩写 功能说明 pick p 保留该提交，不做任何修改 reword r 保留提交内容，修改提交信息 edit e 保留提交内容，暂停变基，允许你修改提交的内容 squash s 将该提交合并到上一个提交中，保留两个提交的信息 fixup f 将该提交合并到上一个提交中，丢弃该提交的信息 drop d 删除该提交，彻底丢弃该提交的内容
实战示例：合并最近 2 个零散的提交，整理成一个完整的功能提交
# 基于上面的 feature/login 分支，执行交互式变基
git checkout feature/login
git rebase -i HEAD~2
pick 7 c6d5b4 feat: add login core logic
pick 8 d9e0f1 feat: add login validation
# 命令说明...
我们将第二个提交的命令改为 squash，修改后如下：
pick 7 c6d5b4 feat: add login core logic
squash 8 d9e0f1 feat: add login validation
保存退出后，Git 会打开新的编辑器，让你填写合并后的提交信息，修改为 feat: complete user login function with validation，保存后完成变基。
执行 git log --oneline 查看，原本的 2 个提交已经合并成了 1 个完整的提交，提交历史更加整洁。
四、Merge vs Rebase 核心差异全对比 我们用一张表格，从核心维度，彻底区分 Merge 和 Rebase 的区别，所有内容均基于 Git 官方定义，100% 准确：
对比维度 Git Merge Git Rebase 提交历史修改 绝对不修改现有提交，仅新增合并提交，历史 100% 可追溯 重写现有提交，生成全新的提交哈希，原始提交会被废弃 提交结构 保留分支分叉历史，合并后会出现分叉结构 彻底消除分叉，合并后提交历史完全线性 冲突处理 仅需在生成合并提交时，一次性解决所有冲突 逐个应用补丁时处理冲突，有 N 个提交可能需要解决 N 次冲突 协作安全性 极高，不会修改公共历史，不会影响其他协作者 极低，对公共分支执行会彻底破坏团队协作历史，引发灾难性后果 可追溯性 极强，合并提交的双父节点完整保留所有开发轨迹，可精准追溯每个分支的合并过程 较弱，原始分支的开发轨迹被抹除，无法追溯提交的原始分支来源 回滚操作 简单，合并提交可直接通过 git revert -m 1 <hash> 一键回滚整个特性分支的修改 复杂，线性历史中无法直接区分特性分支的提交范围，回滚需要逐个处理提交 学习门槛 低，逻辑简单，不易出错 高，需要理解底层逻辑，操作不当极易引发问题 核心优势 安全、完整、可追溯，冲突处理简单 历史整洁、线性可读，可灵活整理本地提交
五、核心红线与适用场景：再也不会用错的决策标准 这是本文最核心的部分，也是 90% 的开发者踩坑的根源。Merge 和 Rebase 没有绝对的优劣，只有是否适合场景，用对了事半功倍，用错了灾难连连。
5.1 不可逾越的核心红线（Git 官方明确警告） 永远不要对已经推送到公共远程仓库、且有其他协作者基于其开发的提交，执行 Rebase 操作！
这是 Git 官方文档中明确标注的最高优先级警告，没有任何例外。
原因非常简单：你对公共分支执行 Rebase 后，重写了提交历史，远程仓库的提交哈希发生了变化，而其他协作者的本地仓库，还是基于旧的提交历史开发的。当他们执行 pull 操作时，Git 会把两个不同的历史合并，生成大量重复的提交，最终导致整个仓库的提交历史彻底混乱，甚至丢失代码。
即使你用 git push --force 强制覆盖了远程分支，也无法解决这个问题，只会让灾难扩散。唯一的补救方式，是让所有协作者都删除本地的对应分支，重新拉取远程的新分支，这在多人协作的团队中，成本极高，极易引发代码丢失。
5.2 什么时候必须用 Merge？ 满足以下任意一个场景，优先选择 Merge，绝对不要用 Rebase：
将特性分支合并回公共主干分支（main/develop） ：这是 Merge 最核心的使用场景。无论是 GitHub PR、GitLab MR，合并到公共主干时，用 Merge（推荐 --no-ff 参数）可以完整保留特性分支的开发历史，保证主干分支的历史可追溯，回滚方便，且不会修改任何现有提交，绝对安全。多人协作的共享分支合并 ：只要是多个开发者同时在开发的分支，合并时必须用 Merge，禁止用 Rebase，避免重写公共历史。需要完整保留开发轨迹的合规场景 ：很多企业有合规要求，需要完整记录代码的开发、合并、修改全流程，Merge 的完整历史可以满足这个要求，而 Rebase 会抹除原始开发轨迹。合并多个分支的复杂场景 ：当需要一次性合并多个分支时，Merge 的 octopus 策略可以轻松处理，而 Rebase 无法实现。
5.3 什么时候可以用 Rebase？ 满足以下所有前提条件，才可以使用 Rebase，缺一不可：
操作的分支是你自己的本地私有分支 ：没有推送到远程仓库，或者推送到了远程，但只有你一个人在使用，没有任何其他协作者基于这个分支开发你要重写的提交，没有被合并到任何公共分支 满足前提的情况下，以下场景是 Rebase 的最佳实践：
同步公共主干分支的最新提交到本地特性分支 ：当你在本地开发特性分支时，主干分支有了新的提交，你需要同步这些提交来解决冲突、避免后续合并出现问题。此时用 git rebase main，可以把你的特性分支'嫁接'到主干的最新提交上，保持提交历史线性，避免生成无意义的合并提交。整理本地私有分支的提交历史 ：开发过程中，你可能会生成很多零散的提交，比如'fix: typo''wip: 临时提交'，在提交 PR/MR 之前，用交互式变基 git rebase -i 整理这些提交，合并零散提交、修改提交信息、删除无用提交，让每个提交都是原子性的、有明确意义的，方便代码评审。线性化本地分支历史，提升可读性 ：对于你自己的私有分支，用 Rebase 保持提交历史线性，方便后续排查问题、回溯代码修改。提交 PR/MR 之前，解决与主干的冲突 ：在提交代码评审之前，用 Rebase 同步主干最新代码，解决所有冲突，确保评审的代码是基于最新主干的，避免评审完成后合并时出现冲突。
5.4 绝对禁止使用 Rebase 的场景
任何公共分支（main/develop/release 等），绝对禁止执行 Rebase
已经推送到远程仓库、且有其他协作者使用的分支，绝对禁止执行 Rebase
已经合并到公共主干的提交，绝对禁止执行 Rebase
多人协作的共享分支，绝对禁止执行 Rebase
六、高频误区与易混淆点避坑 这里整理了开发者最容易踩的 10 个误区，100% 纠正错误认知，避免踩坑：
误区 1：Rebase 会丢失提交历史，Merge 不会 纠正 ：Rebase 不会丢失任何提交内容，它只是把原始提交废弃，生成了全新的提交，所有的代码修改都会完整保留，只是提交的哈希值和父节点变了，历史变成了线性的。Merge 保留的是分叉的原始历史，Rebase 保留的是线性的修改历史，两者都不会丢失代码内容。
误区 2：Rebase 比 Merge 高级，用 Rebase 就是更专业 纠正 ：Merge 和 Rebase 只是两个不同的工具，有不同的适用场景，没有高低优劣之分。用对了场景，两个都是专业的操作；用错了场景，哪怕是 Rebase，也是灾难性的错误。很多资深开发者，在公共分支合并时，永远只用 Merge，因为安全永远是第一位的。
误区 3：Fast-Forward 合并和 Rebase 的结果是一样的 纠正 ：两者的最终提交历史看起来都是线性的，但底层逻辑完全不同。Fast-Forward 合并只是移动了分支指针，没有修改任何提交，所有提交的哈希值完全不变；而 Rebase 是生成了全新的提交，哈希值完全改变，原始提交被废弃。
误区 4：对公共分支 Rebase 后，只要强制推送就行 纠正 ：对公共分支执行 Rebase 后，哪怕用 git push --force 强制覆盖了远程分支，也无法解决根本问题。其他协作者的本地分支还是基于旧的历史，他们 pull 的时候会生成大量重复提交，导致历史彻底混乱。唯一正确的做法，是永远不要对公共分支执行 Rebase。如果非要修改已经推送的公共分支提交，必须用 git revert 生成反向提交，而不是 Rebase。
误区 5：git pull 的默认行为是 Rebase 纠正 ：git pull 的默认行为是 git fetch + git merge，也就是先拉取远程分支的最新内容，然后用 Merge 合并到本地分支。如果你想让 pull 的时候默认用 Rebase，可以执行配置命令：git config --global pull.rebase true，这也是很多团队的推荐配置，可以避免本地分支生成大量无意义的合并提交。
误区 6：Merge 的--squash 参数和 Rebase 的 fixup 是一样的 纠正 ：git merge --squash 是将特性分支的所有提交压缩成一个新的提交，合并到目标分支，不会保留特性分支的提交历史，也不会生成双父节点的合并提交；而 Rebase 的 fixup 是在变基的过程中，将提交合并到上一个提交，是在同一个分支内整理提交历史，两者的使用场景和底层逻辑完全不同。
误区 7：Rebase 之后，原始提交就彻底消失了 纠正 ：Rebase 之后，原始提交只是没有被分支指针指向了，并没有被立即删除。Git 有 reflog 机制，会记录所有分支指针的变化，你可以通过 git reflog 找到原始提交的哈希值，在 30 天内（Git 默认的过期时间）都可以恢复。
误区 8：合并冲突的时候，Rebase 和 Merge 的处理方式是一样的 纠正 ：Merge 冲突解决完成后，需要执行 git commit 生成合并提交；而 Rebase 冲突解决完成后，需要执行 git add，然后 git rebase --continue，绝对不能执行 git commit，否则会生成额外的提交，导致变基失败。
误区 9：Rebase 可以替代 Merge 纠正 ：绝对不能。Rebase 只能处理私有分支的历史整理和同步，无法替代 Merge 在公共分支合并中的作用。任何团队，都不可能只用 Rebase 不用 Merge，否则协作一定会出问题。
误区 10：三方合并就是简单的两个分支内容对比覆盖 纠正 ：Git 的三方合并，是基于共同祖先的差异合并，不是简单的覆盖。Git 会对比两个分支相对于共同祖先的修改，只要两个分支修改的不是同一行代码，Git 会自动合并；只有修改了同一行代码，才会提示冲突。这也是 Git 合并能力强大的核心原因。
七、企业级团队协作最佳实践 基于 Git 官方推荐，结合业界主流的 Git Flow、GitHub Flow、GitLab Flow 规范，我们整理了一套可直接落地的、零坑的合并策略最佳实践，无论是小团队还是大型企业，都可以直接使用：
7.1 分支管理与合并策略匹配规范 分支类型 分支命名 核心用途 合并策略 禁止操作 主干分支 main/master 存放可部署的生产代码，永远保持稳定 仅接受 PR/MR 合并，必须使用 git merge --no-ff，禁止直接提交 禁止 Rebase、禁止强制推送、禁止直接提交 特性分支 feature/* 开发者本地开发新功能 开发过程中用 git rebase main 同步主干代码，用 git rebase -i 整理提交历史；合并回主干用 Merge --no-ff 禁止 Rebase 已经推送到远程的共享特性分支 发布分支 release/* 版本发布前的测试、预发布 用 Merge 合并特性分支，修复 bug 直接提交 禁止 Rebase、禁止强制推送 热修复分支 hotfix/* 生产环境紧急 bug 修复 开发完成后，用 Merge 同时合并回 main 分支和 release 分支 禁止 Rebase、禁止强制推送
7.2 提交历史管理规范
本地开发过程中，允许生成临时提交，但在提交 PR/MR 之前，必须用交互式变基整理提交历史，确保每个提交都是原子性的，一个提交只做一件事，提交信息符合 Conventional Commits 规范
禁止将多个不相关的功能修改，放在同一个提交中
禁止在主干分支中生成无意义的合并提交，所有合并到主干的操作，都必须有明确的合并目的
7.3 远程操作规范
绝对禁止对公共分支执行 git push --force，仅允许对自己的私有特性分支，使用 git push --force-with-lease 强制推送，--force-with-lease 会检查远程分支是否有新的提交，避免覆盖其他人的修改，比--force 安全得多
拉取远程分支更新时，推荐使用 git pull --rebase，或者配置全局默认 pull 用 rebase，避免本地分支生成大量无意义的合并提交
推送代码之前，必须先拉取远程分支的最新更新，解决所有冲突，再推送
7.4 冲突处理规范
合并冲突必须由代码的修改人亲自解决，禁止不看代码直接用--ours 或--theirs 覆盖
解决冲突后，必须编译测试通过，再继续合并或变基操作
Rebase 过程中，如果冲突过多，难以解决，可以执行 git rebase --abort 放弃变基，改用 Merge 合并
7.5 代码评审与合并规范
PR/MR 提交之前，必须先 Rebase 同步主干的最新代码，解决所有冲突，确保评审的代码是基于最新主干的
代码评审通过后，由项目负责人执行合并操作，必须使用 git merge --no-ff，禁止快进合并，确保完整保留特性分支的开发轨迹
合并完成后，及时删除已经合并的远程特性分支，避免分支冗余
八、最终总结 回到最开始的灵魂拷问：到底用 Merge 还是 Rebase？
答案非常简单，记住两句话就够了： 公共分支合并用 Merge，安全完整可追溯；私有分支整理用 Rebase，干净线性易阅读。
Git Merge 和 Rebase，不是对立的两个选项，而是互补的两个工具。Merge 的核心价值是安全和可追溯，是团队协作的基础保障；Rebase 的核心价值是整洁和灵活，是本地开发的效率工具。
你不需要盲目跟风用 Rebase，也不用无脑只用 Merge，只要理解了它们的底层逻辑，守住了公共分支不用 Rebase 的核心红线，根据场景选择合适的工具，就能把 Git 用得得心应手，再也不会因为合并操作踩坑。
最后，再强调一遍 Git 官方的最高警告：永远不要重写已经公开的提交历史！
参考资料 相关免费在线工具 Base64 字符串编码/解码 将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
Base64 文件转换器 将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
Markdown转HTML 将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
HTML转Markdown 将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML转Markdown在线工具，online
JSON 压缩 通过删除不必要的空白来缩小和压缩JSON。 在线工具，JSON 压缩在线工具，online
JSON美化和格式化 将JSON字符串修饰为友好的可读格式。 在线工具，JSON美化和格式化在线工具，online
