图文详解：Git分支创建、合并与冲突解决｜新手零门槛完整教程

在上一篇 GitHub 上传代码教程里，我们掌握了基础的 add → commit → push 提交流程。但真正进入项目开发和团队协作，分支操作才是 Git 的核心灵魂，也是新手必须跨过的一道坎。

很多同学刚接触分支时会一头雾水：好好的主分支不用，为什么要开分支？切换分支代码会不会丢？合并冲突到底怎么解？这篇教程全程配操作截图，从本地命令行操作到 GitHub 线上 PR 协作流程，再到合并冲突解决，一步一步带你吃透 Git 分支。

一、先搞懂：分支到底是什么？

1. 通俗理解分支

你可以把分支想象成代码的「平行副本」：

主分支（默认叫 main 或 master）存放稳定、可正常运行的正式代码
开发新功能、修复 Bug 时，从主分支「切」出一个独立副本
你在副本里随便改代码，都不会影响主分支的稳定版本
功能开发测试完成后，再把副本的改动「合并」回主分支

2. 为什么一定要用分支？

更安全：不会把半成品、有 Bug 的代码直接提交到主干，避免搞崩线上项目
更高效：多人团队可以同时在不同分支开发不同功能，互不干扰
更灵活：功能做一半需要紧急修 Bug，随时切换分支，代码不会混乱

3. 常见分支类型

主分支 ：main / master，存放正式发布的代码
功能分支 ：feature/xxx，用于开发新功能，如 feature/user-login
修复分支 ：fix/xxx，用于修复 Bug，如 fix/homepage-crash
热修复分支 ：hotfix/xxx，用于线上紧急问题修复

二、方法一：命令行本地分支操作（基础必学）

这是最核心的基础操作，我们以「从主分支创建功能分支，开发完成后合并回主分支」为例，全程演示。

步骤 1：查看当前所在分支

打开终端 / Git Bash，进入你的项目文件夹，执行：

bash 复制代码

git branch

执行后会列出所有本地分支，前面带 * 号的就是你当前所在的分支。

下图完整演示了查看、创建、切换的全流程：初始状态在 master 主分支，只有一个默认分支。

步骤 2：创建并切换到新分支

方式一：两步操作（先创建再切换）

bash 复制代码

# 创建名为 dev 的新分支
git branch dev

# 切换到 dev 分支
git checkout dev

方式二：一步到位（日常开发推荐）

bash 复制代码

git checkout -b dev

-b = branch + checkout，创建分支的同时直接切换过去，效率更高，是日常开发最常用的写法。

切换完成后，再次执行 git branch，可以看到 * 已经移动到 dev 分支上，代表当前工作分支切换成功。

步骤 3：在分支上修改并提交代码

切换到新分支后，就可以正常编写代码了。修改完成后，执行常规的提交操作：

bash 复制代码

git add .
git commit -m "feat: 完成用户登录页面开发"

此时所有的提交都只保存在 dev 分支里，主分支的代码完全不受影响。

步骤 4：切换回主分支

功能开发完成后，先切回要合并到的目标分支（main/master），再执行合并：

bash 复制代码

git checkout main

关键原则：要把 A 分支合并到 B 分支，就必须先切换到 B 分支，再执行 merge 命令。

步骤 5：将功能分支合并到主分支

在主分支下执行合并命令：

bash 复制代码

git merge dev

如果没有冲突，终端会提示 Fast-forward（快进合并），代表合并顺利完成。此时主分支就已经包含了 dev 分支的所有代码改动。

步骤 6（可选）：删除已合并的分支

分支合并完成后就完成了使命，可以删除以保持仓库整洁：

bash 复制代码

git branch -d dev

如果分支还没合并，想要强制删除，用大写 -D：

bash 复制代码

git branch -D dev

三、方法二：GitHub 远程分支 + PR 合并（团队协作标准流程）

实际工作中，不会直接在本地合并完就推送主干，而是通过 Pull Request（简称 PR，拉取请求） 完成合并：本地推分支 → 线上提 PR → 代码审查 → 合并到主干。这是所有研发团队的标准协作规范。

步骤 1：将本地分支推送到 GitHub

在本地功能分支开发完成后，执行推送命令，把本地分支同步到 GitHub 远程仓库：

bash 复制代码

git push -u origin feature/login

-u 参数会绑定本地分支和远程分支，后续再推送只需要输入 git push 即可。

步骤 2：在 GitHub 创建 Pull Request

推送成功后，刷新你的 GitHub 仓库页面，顶部会自动出现黄色提示条，点击 Compare & pull request 进入 PR 创建页。

下图是标准的 PR 创建页面，各个区域说明：

上方：确认合并方向，base: main 是目标分支，compare: 你的分支 是源分支
中间：填写 PR 标题和详细描述，说明本次改动的内容、实现逻辑
右侧：可指定审查人、标签、里程碑等
底部：绿色按钮提交 PR

填写完成后，点击底部绿色的 Create pull request 按钮，PR 就创建成功了。

步骤 3：代码审查与合并 PR

PR 创建后，团队成员可以查看代码差异、留言评论、提出修改意见。确认代码无误后，就可以执行合并：

进入 PR 详情页，滚动到页面底部
找到绿色的 Merge pull request 按钮
点击后填写合并说明，再点击 Confirm merge 确认

合并完成后，功能分支的代码就正式合入主分支了。最后可以点击 Delete branch 删除远程的功能分支，保持仓库整洁。

四、重点难点：合并冲突产生与解决

1. 冲突什么时候会出现？

当两个分支修改了同一个文件的同一行代码，Git 无法自动判断该保留哪一份，就会抛出合并冲突，需要人工手动决策。

举个简单例子：

main 分支里 index.html 第 5 行写的是 <h1>Hello</h1>
feature 分支里 index.html 第 5 行改成了 <h1>你好</h1>
合并时 Git 不知道该留哪个版本，就会产生冲突

2. 冲突文件长什么样？

合并时如果出现冲突，终端会提示 Automatic merge failed; fix conflicts and then commit the result.

打开冲突的文件，会看到 Git 自动插入的冲突标记：

复制代码

<<<<<<< HEAD
<h1>Hello</h1>
=======
<h1>你好</h1>
>>>>>>> feature/login

<<<<<<< HEAD 到 =======：当前分支（你所在的主分支）的内容
======= 到 >>>>>>> feature/login：要合并的分支的内容

3. 可视化解决冲突（VS Code）

现在主流编辑器都支持可视化冲突解决，以 VS Code 为例，打开冲突文件后会看到快捷操作选项：

四个选项对应四种处理方式：

Accept Current Change：保留当前分支的内容，丢弃要合并分支的改动
Accept Incoming Change：保留要合并分支的内容，覆盖当前分支
Accept Both Changes：两个版本的内容都保留
Compare Changes：并排对比两个版本的差异

选择对应的选项，或者手动编辑代码，删掉所有冲突标记，保留最终正确的内容即可。

4. 完成冲突解决

编辑保存文件后，执行以下命令完成合并：

bash 复制代码

# 将解决完冲突的文件重新加入暂存区
git add 冲突的文件名

# 提交合并结果
git commit -m "fix: 解决登录页面文案合并冲突"

至此冲突就彻底解决了。

5. 减少冲突的小技巧

功能分支粒度要小，不要一个分支开发十几天再合并
每天开工前从 main 拉取最新代码：git pull origin main，保持分支同步
多人协作时尽量避免同时修改同一个文件的同一区域
提前沟通分工，减少交叉修改

五、分支最佳实践与常用命令速查

1. 分支命名规范

功能开发：feature/功能名称，如 feature/user-center
Bug 修复：fix/问题描述，如 fix/login-404-error
线上热修复：hotfix/问题描述，如 hotfix/payment-fail
文档更新：docs/更新内容，如 docs/api-doc-update

2. 常用分支命令速查表

命令	功能说明
`git branch`	查看所有本地分支
`git branch 分支名`	创建新分支
`git checkout 分支名`	切换到指定分支
`git checkout -b 分支名`	创建并切换到新分支
`git merge 分支名`	将指定分支合并到当前分支
`git branch -d 分支名`	删除已合并的分支
`git branch -D 分支名`	强制删除分支
`git branch -r`	查看所有远程分支
`git push origin --delete 分支名`	删除远程分支

总结

分支操作的核心逻辑非常简单：从主干切出分支 → 分支内独立开发 → 完成后合并回主干 。新手最容易踩坑的地方是搞混「在哪个分支执行 merge」，记住一个原则就行：要合并到哪个分支，就先切换到哪个分支。