在掌握了基础的版本提交与远程仓库交互后，开发者日常工作的重心会自然转移到多任务并行与团队协作上。Git最强大的特性之一就是它的分支管理机制。本章将带你彻底搞懂分支的创建、切换、合并以及处理代码冲突的实际操作，让你在实际开发中不再害怕改错代码或覆盖他人成果。
理解分支的本质与常用命令
很多初学者看到命令行里的分支列表会觉得复杂，其实分支在Git底层只是一个指向特定提交记录的轻量级指针。默认情况下，你每次初始化仓库都会获得一个名为master的主干分支，所有初始提交都挂在这个指针后面。当你需要开发新功能或者修复紧急漏洞时，直接在主线上动刀风险极高。正确的做法是新建一条分支，在这个独立的空间里进行实验，确认无误后再合回主干。
创建新分支的命令非常直观，输入git branch加分支名称即可生成一个快照。但创建之后你必须手动切过去才能开始工作。推荐使用git checkout加分支名来切换上下文，或者使用更现代的git switch命令。这两个指令的作用是让工作目录完全对齐到你指定的那个指针位置。你可以在任意时刻随时跳转，之前的修改状态会被安全保存，不会互相干扰。配合git branch命令不加参数，可以随时查看当前所有分支的状态，星号标记的就是你现在所在的位置。
高效合并代码与冲突处理
当你的功能开发完毕并测试通过后，就需要把这条分支的成果带回到主线上。这一步叫作合并。执行git merge加目标分支名，Git会自动尝试将两条线的提交历史缝合在一起。如果两个分支修改了不同的文件，或者修改了同一个文件的完全不同区域，Git能完美自动完成合并，整个过程几乎不需要人工干预。
真正的挑战在于冲突发生的时候。冲突通常出现在多人同时修改同一个文件的同一行代码，或者一方删除了文件而另一方又做了修改。此时Git会暂停合并流程，并在文件里插入清晰的标记符号，告诉你哪些是你的改动，哪些是别人的改动。你需要打开这些文件，人工审查每一处标记，决定保留哪部分逻辑，或者直接重写整段代码。删掉那些特殊的提示符号后，执行标准的提交流程，合并就算正式结束。记住，冲突不是错误，而是协作的必然产物，冷静逐行核对才是解决之道。
工作流规范与分支清理
在实际的团队项目中，分支的生命周期通常很短。功能验证完成后，主线上的旧分支就失去了存在的意义。长期堆积无用分支会让仓库变得臃肿，增加后续查找和维护的成本。因此，养成定期清理的习惯非常重要。使用git branch加删除标志可以移除本地已经合并完成的分支。对于已经推送到服务器端的分支，如果确定不再需要，也要及时同步删除远端记录，保持团队视野整洁。
除了常规的合并操作，有些场景下开发者会选择变基模式。这种方式会把一系列提交重新排列，让历史记录看起来像是一条直线，而不是分叉后又汇合的网状结构。它能让项目的演进脉络更加清晰，适合在公开分享前整理个人提交。不过在使用变基之前务必确认没有其他人依赖该分支，避免引发连锁问题。
掌握分支管理意味着你已经跨过了新手门槛，能够从容应对复杂的开发节奏。接下来的章节我们会深入探讨如何配置忽略规则、如何处理临时存档以及高级的撤销技巧。先把本章提到的切换、合并与冲突解决练熟，建立起肌肉记忆，后面的进阶内容就会水到渠成。
