Merging 将一个分支的更改合并到另一个分支中——通常是将已完成的特性分支合并回主分支。Git 会自动处理大多数 merge，但理解 merge 类型和冲突很重要。
git switch main # be on the branch you want to merge INTO
git merge feature-x # merge feature-x's changes into main
您切换到目标分支（接收更改的分支）并将源分支 merge 到其中。
FAST-FORWARD merge → if main hasn't changed since the branch was created, Git just
MOVES main's pointer forward to the branch's latest commit (no merge commit, linear)
MERGE COMMIT (three-way merge) → if BOTH branches have new commits, Git creates a new
"merge commit" combining them (has two parents) → preserves that a merge happened
→ git merge --no-ff forces a merge commit even when fast-forward is possible
Git 在可能的情况下快进（仅仅推进指针）或创建merge 提交（有两个父提交）当两个分支都有新的提交时。
A CONFLICT happens when both branches changed the SAME lines differently — Git can't
auto-decide which to keep, so it asks YOU to resolve:
<<<<<<< HEAD
the version from the current branch (main)
=======
the version from the branch being merged (feature-x)
>>>>>>> feature-x
# resolve: edit the file to the desired result, remove the markers, then:
git add <file> # mark the conflict resolved
git commit # complete the merge
# git merge --abort # or cancel the merge entirely
当两个分支修改同样的代码行时会出现冲突——Git 会标记它们，您需要手动选择正确的结果，然后暂存并提交。
理解 merging 是必要的，因为合并分支更改是协作 Git 工作流中的基础且持续的一部分，所以知道它的工作原理（包括冲突）是必不可少的日常知识。Merging 是已完成的工作（通常是特性分支）如何集成回主分支的方式——在团队开发中持续进行的例行合并更改的操作。
理解快进 merge（当目标分支未发散时，Git 仅仅推进指针，保持历史线性）和merge 提交（当两个分支都有新提交时进行三路合并，创建一个有两个父提交的新提交，记录发生了 merge）之间的区别，可以理解 Git 如何集成更改以及生成的历史记录是什么样的。
最重要的是，理解merge 冲突——当两个分支以不同的方式修改同样的代码行时，Git 无法自动决定，需要您手动解决——这是关键的实践知识：冲突是协作的正常、不可避免的一部分，知道如何识别冲突标记（<<<<<<<、=======、>>>>>>>）、编辑文件到正确的结果，以及完成 merge（暂存并提交）是一项必备技能，对于不理解的人来说通常是焦虑的来源。
由于通过 merging 集成分支更改在协作开发中是基础且持续的，而且由于理解 merge 类型，特别是解决冲突对于正确地合并工作是必要的（这是一项例行的、不可避免的任务），理解 merging 如何工作——基本 merge、快进 vs merge 提交以及冲突解决——是必要的、经常应用的 Git 知识，是协作的核心技能，其中冲突解决特别是每个开发人员必须自信地处理的实际必需。