Git 分支开一条新线改代码改坏了也不影响主线

之前的 Git 入门讲了 add、commit、push 这些日常命令，但真正让 Git 好用的其实是分支：在主线之外开一条独立的线，新功能、改 bug 都在分支上折腾，稳了再合并回去，改坏了删掉就行。本文讲清分支的创建、切换、合并、删除，以及新手最容易被吓到的冲突到底是怎么回事、怎么解决。

用 Git 管代码，如果所有改动都直接堆在 main 主线上，很快就会遇到尴尬：新功能写了一半，线上突然报了个急 bug 必须马上修，可你的代码改得乱七八糟还没法提交。这时候分支就派上用场了。分支可以理解成一条平行的时间线：从主线的某个点岔出去，你在新线上随便改、随便提交，主线一点不受影响；等改稳了，再把新线合回主线。改坏了更简单，分支一删，就当无事发生。
先学会看和建。git branch 不带参数，列出本地所有分支，前面带星号的是你当前所在的那条。git branch dev 是新建一条叫 dev 的分支，注意它只是建好，你人还站在原地；要过去得再执行 git switch dev。嫌两步麻烦，可以用 git switch -c dev 一步到位：建好并切过去。很多人教程里写的是 git checkout -b dev，那是老命令，效果一样，看到了别懵。还有一个认知要纠正：分支不是把代码复制一份，它只是一个指向某次提交的指针，建分支几乎不占空间，所以别舍不得开，该开就开。
在分支上干活和平时完全一样：改文件、git add、git commit，提交都记在当前分支名下。切回 main 你会发现，分支上改的东西不见了——不是丢了，是工作区跟着分支走，每个分支看到的是自己那条线上的文件状态。两个分支互不干扰，这正是分支的意义：一个分支开发新功能，另一个分支修 bug，各自提交，最后再汇总。
干完活要把分支合回主线，动作叫合并：先 git switch main 切回主线，再 git merge dev，把 dev 的成果并进来。如果主线在你离开期间没人动过，Git 会直接快进，一下就对齐了；如果主线也有新提交，Git 就做一次三方合并，自动生成一个合并提交。合并没问题后，把结果 git push 推到远程仓库。想让别人看到你的分支，也可以 git push -u origin dev 把分支本身推上去。
合并时最可能遇到的“拦路虎”是冲突：两个分支改了同一个文件的同一行，Git 不知道听谁的，就把文件打开成这样：冲突位置用 <<<<<<< 和 >>>>>>> 标出两边的内容，中间用 ======= 隔开。冲突不是报错，更不是文件坏了，它是 Git 在说“这处我裁决不了，你来定”。你手动把那段改成最终想要的样子，把标记符号删干净，再 git add、git commit，合并就完成了。第一次遇到别慌，冲突区域就那么几行，改完记得全局搜一下还有没有漏掉的标记符号。
最后是收尾和两条红线。用完的分支及时删：git branch -d dev，小写 -d 只会删已经合并过的，安全；大写 -D 是强制删除，没合并的成果会一起丢，新手不要碰。红线一：切换分支前先把手头的改动提交掉，或者用 git stash 暂存起来，别让未提交的改动跟着你到处跑，容易搅成一团。红线二：main 主线尽量保持随时可用的状态，半成品都留在分支上，这是用分支最核心的纪律。