分支到底是什么
很多人把分支想得很神秘，其实分支就是一个指向某次提交的可移动指针。每次提交（commit）会生成一个新节点，分支指针跟着移动。所谓新建分支，就是复制一个指针出来，让它从当前提交开始独立往前走，互不干扰。
理解这一点后，下面所有操作都顺理成章：合并是把两条提交链重新接起来，冲突是两边的修改恰好碰到了同一块代码。
第一步：创建与切换分支
常用命令只有三个：
- git branch 功能名 —— 创建新分支，比如 git branch feature/login 创建登录功能分支。
- git switch 功能名 —— 切换到该分支，注意切换前先提交或暂存当前工作区的改动。
- git switch -c 功能名 —— 创建并切换一步到位，最常用。
建议命名规范：feature/登录功能、fix/修复空指针、release/v1.2。看到分支名就能知道它干什么，团队协作的第一条规矩就是命名清晰。
第二步：合并分支的正确姿势
功能开发完要合并回主分支。推荐流程：先切换到主分支 git switch main，拉取最新代码 git pull，再执行 git merge feature/login。合并成功后删除功能分支 git branch -d feature/login，保持仓库干净。
两个细节：第一，合并前务必 pull 最新代码，否则容易把旧代码合进去；第二，如果功能分支落后主分支较多，可以先在主分支上执行 git merge 主分支名 把主分支的最新改动拉进功能分支，提前解决潜在冲突，再合并回去。
第三步：冲突解决的三类场景
冲突不可怕，可怕的是不知道怎么处理。冲突文件里会出现冲突标记：冲突区域以 开头，中间是分隔符，结束是。意思是一边是当前分支的内容，一边是传入分支的内容。
场景一：同一行被两边改了不同的值。保留正确的那个，删掉冲突标记即可。场景二：一边改了A文件，另一边删了A文件。要么保留文件，要么确认删除。场景三：两边都新增了同名函数。需要人工合并两个函数或改名。
解决完冲突后执行 git add 标记已解决，再 git commit 完成合并。原则：宁可多问一句，不要自作主张丢弃队友的代码。
第四步：团队分支模型参考
小团队用轻量模型：main 分支保持稳定，每个需求开一个 feature 分支，完成后合并。中大型团队用 GitFlow：main 只放正式发布版本，develop 放日常开发，功能分支从 develop 拉出，release 分支负责发布准备，hotfix 分支紧急修线上问题。
不要照搬任何模型，按团队规模和发布节奏裁剪。核心红线只有一条：main 分支永远保持可发布状态，谁都不能直接往 main 上推未验证的代码。
命令速查表
git branch 查看本地分支，git branch -a 查看所有分支，git switch -c 名 新建并切换，git merge 分支名 合并，git rebase 分支名 变基（重放提交），git branch -d 名 删除已合并分支，git stash 暂存未提交改动。把这张表存下来，遇到不确定先查命令再操作，比瞎敲安全得多。