Git 分支管理完全指南：从基础到团队协作
🔥个人主页：Cx330🌸
❄️个人专栏：《C语言》《LeetCode刷题集》《数据结构-初阶》《C++知识分享》
《优选算法指南-必刷经典100题》《Linux操作系统》:从入门到入魔
🌟心向往之行必能至
🎥Cx330🌸的简介：
目录
前言：
作为一名开发者，你是否经历过这些 “崩溃瞬间”：刚写完的功能代码被同事意外覆盖、线上突发 bug 却找不到可回滚的稳定版本、多人协作时代码冲突堆积成山？这些问题的根源，往往不是技术能力不足，而是缺乏一套清晰、可执行的 Git 分支管理规范。
Git 的分支能力本是版本控制的 “利器”，但如果使用无章，就会变成团队协作的 “绊脚石”。无论是刚接触 Git 的新手，还是需要搭建团队协作流程的负责人，掌握科学的分支管理策略，都是提升开发效率、降低线上风险的关键。
本文将从 “为什么要做分支管理” 出发，层层拆解核心概念、主流策略、实操命令和避坑指南，既兼顾新手的入门理解，也满足团队协作的实战需求。无论你是独立开发者，还是中大型团队成员，都能从中找到适合自己的分支管理方案
一、为什么要分支？——分支的意义
Git 分支是版本控制的核心能力，它能解决三大核心问题：
- 并行开发：多人协作不冲突（比如 A 开发支付功能，B 修复登录 bug）
- 风险隔离：新功能开发不影响线上稳定版本
- 版本回溯：出现问题可快速回滚到历史稳定版本
分支就像是科幻电影里面的平行宇宙，当你正在电脑前努力学习 C++ 的时候，另⼀个你正在另⼀个平行宇宙里努力学习 JAVA。如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了 C++ 又学会了 JAVA！
二. Git 分支基础：核心概念与常用命令
2.1 分支与 HEAD 指针解析
- 分支：Git 分支并非复制完整代码目录，而是一个 “指向提交记录的指针”（占极少存储空间）。例如
master分支指向最新的稳定提交，feature/login分支指向登录功能的最新提交 - HEAD指针：Git 用
HEAD指针标记 “当前所在的分支”，执行git branch命令时，带*的分支即为HEAD指向的当前分支
再来理解⼀下HEAD，HEAD 严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD 指向的就是当前分支
每次提交，master 分支都会向前移动一步，这样，随着你不断提交，master 分支的线也越来越长，而 HEAD 只要一直指向 master 分支即可指向当前分支
查看我们当前的版本库：
yhr@VM-24-15-ubuntu:~/gitcode$ cat .git/HEAD ref: refs/heads/master yhr@VM-24-15-ubuntu:~/gitcode$ cat .git/refs/heads/master ebc48f707e2908206260e9279a8932f66a71c4c7 master指向的是最近一次提交的commit id，我们可以使用git log来查看：
2.2 基础指令：查看、创建、切换分支
<1> 查看分支（git branch）
查看本地所有分支（* 表示当前分支）
yhr@VM-24-15-ubuntu:~/gitcode$ git branch * master <2> 创建分支（git branch <分支名>）
Git 支持我们查看或创建其它分支，创建分支时，Git 会基于 “当前分支的最新提交” 创建新指针，不会复制代码文件，在这里我们来创建第一个自己的分支 dev ，对应的命令为：
yhr@VM-24-15-ubuntu:~/gitcode$ git branch dev yhr@VM-24-15-ubuntu:~/gitcode$ git branch dev * master 我们使用 tree .git 来看一下创建的分支：
我们发现此时heads多了一个我们刚刚创建的dev分支
<3> 切换分支（git checkout ）
此时dev分支指向的也是最近一次的提交，但是，进行修改等操作还是只能在master分支进行操作，此时如果想要切换到dev分支下进行操作该怎么办呢？
yhr@VM-24-15-ubuntu:~/gitcode$ git checkout dev Switched to branch 'dev' yhr@VM-24-15-ubuntu:~/gitcode$ git branch * dev master yhr@VM-24-15-ubuntu:~/gitcode$ cat .git/HEAD ref: refs/heads/dev 此时：
接下来，我们在dev分支下对ReadMe文件新增一行代码：
yhr@VM-24-15-ubuntu:~/gitcode$ ls file1 ReadMe yhr@VM-24-15-ubuntu:~/gitcode$ vim ReadMe yhr@VM-24-15-ubuntu:~/gitcode$ git add ReadMe yhr@VM-24-15-ubuntu:~/gitcode$ git commit -m "md ReadMe" [dev a2c0656] md ReadMe 1 file changed, 1 insertion(+) yhr@VM-24-15-ubuntu:~/gitcode$ git status On branch dev nothing to commit, working tree clean yhr@VM-24-15-ubuntu:~/gitcode$ cat ReadMe Hello git Hello Git aaa on dev branch 我们在dev分支下对ReadMe文件修改，现在切换回master分支，看一下ReadMe文件：
yhr@VM-24-15-ubuntu:~/gitcode$ git checkout master Switched to branch 'master' yhr@VM-24-15-ubuntu:~/gitcode$ git branch dev * master yhr@VM-24-15-ubuntu:~/gitcode$ ls file1 ReadMe yhr@VM-24-15-ubuntu:~/gitcode$ cat ReadMe Hello git Hello Git 我们发现，在master分支下，ReadMe文件并没有变化，我们新增的那一行代码并没有显示出来，我们再切回dev分支：
yhr@VM-24-15-ubuntu:~/gitcode$ git checkout dev Switched to branch 'dev' yhr@VM-24-15-ubuntu:~/gitcode$ git branch * dev master yhr@VM-24-15-ubuntu:~/gitcode$ ls file1 ReadMe yhr@VM-24-15-ubuntu:~/gitcode$ cat ReadMe Hello git Hello Git aaa on dev branch 在 dev 分支上，内容还在。为什么会出现这个现象呢？我们来看看 dev 分支和 master 分支的指向，会发现两者的指向是不同的：
yhr@VM-24-15-ubuntu:~/gitcode$ cat .git/refs/heads/dev a2c0656bbc3c1a570d863680882d389684230991 yhr@VM-24-15-ubuntu:~/gitcode$ cat .git/refs/heads/master ebc48f707e2908206260e9279a8932f66a71c4c7看到这里大家应该就都明白了，因为我们是在 dev 分支上提交的，而 master 分支此刻的提交点并没有变，此时的状态如下图所示：
三. Git 分支进阶：合并、删除和冲突
分支开发完成后，需要将代码合并到目标分支；若合并时出现代码冲突，需手动解决；当然，删除分支也是必不可少的操作
3.1 合并分支（git merge 分支名）
为了在 master 主分支上能看到新的提交，就需要将 dev 分支合并到 master 分支，合并分支的核心逻辑是 “将源分支的提交记录合并到目标分支”，需先切换到目标分支，再执行合并命令
yhr@VM-24-15-ubuntu:~/gitcode$ git checkout master Switched to branch 'master' yhr@VM-24-15-ubuntu:~/gitcode$ git merge dev Updating ebc48f7..a2c0656 Fast-forward ReadMe | 1 + 1 file changed, 1 insertion(+) yhr@VM-24-15-ubuntu:~/gitcode$ cat ReadMe Hello git Hello Git aaa on dev branch git merge 分支名命令用于合并指定分支到当前分支。合并后，master 就能看到 dev 分支提交的内容
我们会看到上面合并之后，会出现 Fast-forward 代表 “快进模式”，也就是直接把 master 指向 dev 的当前提交，所以合并速度非常快。当然，也不是每次合并都能 Fast-forward，我们后面还没讲其它方式的合并
3.2 删除分支（git branch -d 分支名）：
合并完成后，dev 分支对于我们来说就没用了，那么dev分支就可以删除掉，注意如果当前正处于某个分支下，就不能删除当前分支，如：
yhr@VM-24-15-ubuntu:~/gitcode$ git checkout dev Switched to branch 'dev' yhr@VM-24-15-ubuntu:~/gitcode$ git branch -d dev error: Cannot delete branch 'dev' checked out at '/home/yhr/gitcode' 而可以在其它分支下删除当前分支，如：
yhr@VM-24-15-ubuntu:~/gitcode$ git checkout master Switched to branch 'master' yhr@VM-24-15-ubuntu:~/gitcode$ git branch -d dev Deleted branch dev (was a2c0656). yhr@VM-24-15-ubuntu:~/gitcode$ git branch * master 此时的状态如下图所示：
因为创建，合并，删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删除分支，这和直接在 master 分支上工作效果是一样的，但过程更安全
3.3 解决合并冲突
若合并的两个分支修改了 “同一文件的同一部分”（如 master 分支和 dev1 都修改了ReadMe文件），Git 无法自动判断保留哪部分代码，会触发 “合并冲突”，此时需手动解决
创建一个新的分支 dev1，并切换至目标分支，我们可以使用 git checkout -b dev1 一步完成创建并切换的动作，示例如下：
yhr@VM-24-15-ubuntu:~/gitcode$ git checkout -b dev1 Switched to a new branch 'dev1' yhr@VM-24-15-ubuntu:~/gitcode$ git branch * dev1 master 在 dev 分支下 修改 ReadMe 文件 ，更改文件内容，并进行一次提交，如：
yhr@VM-24-15-ubuntu:~/gitcode$ vim ReadMe yhr@VM-24-15-ubuntu:~/gitcode$ git add . yhr@VM-24-15-ubuntu:~/gitcode$ git status On branch dev1 Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: ReadMe yhr@VM-24-15-ubuntu:~/gitcode$ git commit -m "md ReadMe:bbb" [dev1 74cd7a0] md ReadMe:bbb 1 file changed, 1 insertion(+), 1 deletion(-) 切换至 master 分支 ，观察 ReadMe 文件内容：
我们切换回来会发现文件内容还没变，这个我们上面讲过是因为还没提交，这个很好现在理解。那么我们此时如果在 ReadMe 文件再进行一次修改，并进行提交，如下：
yhr@VM-24-15-ubuntu:~/gitcode$ git checkout master M ReadMe Already on 'master' yhr@VM-24-15-ubuntu:~/gitcode$ vim ReadMe yhr@VM-24-15-ubuntu:~/gitcode$ git add . yhr@VM-24-15-ubuntu:~/gitcode$ git commit -m "md ReadMe:ccc" [master 0b2410c] md ReadMe:ccc 1 file changed, 1 insertion(+), 1 deletion(-) 现在，master 分支和 dev1 分支都分别有了新的提交，变成了这样：
这种情况下，Git只能试图把各自的修改合并起来，但这种合并就可能会有冲突，如下所示：
yhr@VM-24-15-ubuntu:~/gitcode$ git branch dev1 * master yhr@VM-24-15-ubuntu:~/gitcode$ git merge dev1 Auto-merging ReadMe CONFLICT (content): Merge conflict in ReadMe Automatic merge failed; fix conflicts and then commit the result. 我们发现 ReadMe 文件有冲突后，可以直接查看文件内容，要说的是 Git 会用 <<<<<<<, ======,>>>>>>> 来标记出不同分支的冲突内容，如下所示：
此时我们需要手动调整冲突代码，并需要再次提交修正后的结果！！！(再次提交很重要，不要忘记)
我们将dev1下的ReadMe文件修改为bbb on dev branch：再次提交：
yhr@VM-24-15-ubuntu:~/gitcode$ vim ReadMe yhr@VM-24-15-ubuntu:~/gitcode$ cat ReadMe Hello git Hello Git bbb on dev branch yhr@VM-24-15-ubuntu:~/gitcode$ git status On branch master You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: (use "git add <file>..." to mark resolution) both modified: ReadMe no changes added to commit (use "git add" and/or "git commit -a") yhr@VM-24-15-ubuntu:~/gitcode$ git add . yhr@VM-24-15-ubuntu:~/gitcode$ git commit -m "merge dev1" [master de63d7e] merge dev1 yhr@VM-24-15-ubuntu:~/gitcode$ git status On branch master nothing to commit, working tree clean yhr@VM-24-15-ubuntu:~/gitcode$ cat ReadMe Hello git Hello Git bbb on dev branch 到这里冲突就解决完成，此时的状态变成了
我们可以使用 git log 打印一下日志：
yhr@VM-24-15-ubuntu:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit * de63d7e (HEAD -> master) merge dev1 |\ | * 74cd7a0 (dev1) md ReadMe:bbb * | 0b2410c md ReadMe:ccc |/ * a2c0656 md ReadMe * ebc48f7 delete file2 * 0e59887 delete file3 * c5ab24b modify ReadMe * 746b339 add 3 file * c991930 add first file 最后，不要忘记 dev1 分支使用完毕后就可以删除了；
yhr@VM-24-15-ubuntu:~/gitcode$ git branch dev1 * master yhr@VM-24-15-ubuntu:~/gitcode$ git branch -d dev1 Deleted branch dev1 (was 74cd7a0). yhr@VM-24-15-ubuntu:~/gitcode$ git branch * master 四. 分支管理规范
4.1 禁用 Fast forward 模式
通常合并分支时，如果可能，Git会采用 Fast forward 模式，还记得如果我们采用 Fast forward 模式之后，形成的合并结果是什么呢？如图所示：
在这种 Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是merge进来的还是正常提交的，在公司里，如果产品出现错误，不能追究到个人。
但在合并冲突部分，我们也能看到通过解决冲突问题，会再进行下一次提交，得到的最终状态为：
那么这就不是 Fast forward 模式了，这是 No Fast forward，这样的好处时，从历史分支上就可以看出分支信息，例如我们现在已经删除了在合并冲突部分创建的 dev2 分支，但依旧能看到 master 其实是由其它分支合并得到：
yhr@VM-24-15-ubuntu:~/gitcode$ git log --graph --abbrev-commit * commit 2b90647 (HEAD -> master, dev2) | Author: yhr <[email protected]> | Date: Fri Dec 12 08:20:14 2025 +0800 | | md ReadMe 我们在以后分支修改与提交过程可以采用这种模式，可以观察到历史信息与提交记录
no Fast forward命令：git merge --no-ff -m "merge dev2" dev2
我们来实战一下：
切换回dev2分支，并修改ReadMe文件：
yhr@VM-24-15-ubuntu:~/gitcode$ git checkout -b dev2 Switched to a new branch 'dev2' yhr@VM-24-15-ubuntu:~/gitcode$ vim ReadMe 提交一下：
yhr@VM-24-15-ubuntu:~/gitcode$ git add . yhr@VM-24-15-ubuntu:~/gitcode$ git commit -m "md ReadMe" [dev2 2b90647] md ReadMe 1 file changed, 1 insertion(+) 切回master分支，开始 merge 合并：
--no-ff参数，表示禁用Fast forward模式。禁用Fast forward模式后合并会创建一个新的commit，所以加上-m参数，把描述写进去。
yhr@VM-24-15-ubuntu:~/gitcode$ git checkout master Switched to branch 'master' yhr@VM-24-15-ubuntu:~/gitcode$ git merge --no-ff -m "merge dev2" dev2 Merge made by the 'ort' strategy. ReadMe | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) yhr@VM-24-15-ubuntu:~/gitcode$ cat ReadMe Hello git Hello Git bbb on dev branch abcde 合并后，查看分支历史：
yhr@VM-24-15-ubuntu:~/gitcode$ git log --graph --abbrev-commit * commit 8b22d5b (HEAD -> master) |\ Merge: 2b90647 ba59442 | | Author: yhr <[email protected]> | | Date: Fri Dec 12 08:28:26 2025 +0800 | | | | merge dev2 | | | * commit ba59442 (dev2) |/ Author: yhr <[email protected]> | Date: Fri Dec 12 08:27:01 2025 +0800 | | md ReadMe | no fast forward模式如图所示：
所以在合并分支时，加上 --no-ff 参数就可以普通合并模式，合并后的历史有分支，能看出曾经做过合并，而 Fast forward 合并后就看不出来曾经做过合并
4.2 分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪里干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支上发布1.0版本；
你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
4.3 修改bug 创建新分支
假如我们现在正在 dev2 分支上进行开发，开发到一半，突然发现 master 分支上面有 bug，需要解决。在 Git 中，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
但是我们还不想提交dev2，那我们应该怎么办？
yhr@VM-24-15-ubuntu:~/gitcode$ cat ReadMe Hello git Hello Git bbb on dev branch abcde i am coding... yhr@VM-24-15-ubuntu:~/gitcode$ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: ReadMe no changes added to commit (use "git add" and/or "git commit -a") Git 提供了 git stash 命令，可以将当前工作区信息进行储藏，被储存的内容可以在将来某个时间恢复出来
yhr@VM-24-15-ubuntu:~/gitcode$ git checkout dev2 M ReadMe Switched to branch 'dev2' yhr@VM-24-15-ubuntu:~/gitcode$ git stash Saved working directory and index state WIP on dev2: ba59442 md ReadMe 再查看工作区，因此可以放心的创建分支来修复bug。
储藏 dev2 工作区后，由于我们要基于 master 分支修复 bug ，所以需要切回 master 分支，再新建临时分支来修复 bug，示例如下：
yhr@VM-24-15-ubuntu:~/gitcode$ git checkout master Switched to branch 'master' yhr@VM-24-15-ubuntu:~/gitcode$ git checkout -b fix_bug Switched to a new branch 'fix_bug' yhr@VM-24-15-ubuntu:~/gitcode$ vim ReadMe yhr@VM-24-15-ubuntu:~/gitcode$ git add . yhr@VM-24-15-ubuntu:~/gitcode$ git commit -m "fix bug:f" [fix_bug e035682] fix bug:f 1 file changed, 1 insertion(+), 1 deletion(-) 修复完成后，切换到 master 分支，并完成合并：
yhr@VM-24-15-ubuntu:~/gitcode$ git checkout master Switched to branch 'master' yhr@VM-24-15-ubuntu:~/gitcode$ git merge --no-ff -m "merge fix_bug" fix_bug Merge made by the 'ort' strategy. ReadMe | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) yhr@VM-24-15-ubuntu:~/gitcode$ git status On branch master nothing to commit, working tree clean yhr@VM-24-15-ubuntu:~/gitcode$ cat ReadMe Hello git Hello Git bbb on dev branch abcdef bug的修复工作已经做完了，我们还要继续回到 dev2 分支进行开发，切换回 dev2 分支，工作区是干净的，刚才的工作存到哪里去了？用 git stash list 命令看看：
yhr@VM-24-15-ubuntu:~/gitcode$ git stash list stash@{0}: WIP on dev2: ba59442 md ReadMe 工作现场还在，Git把 stash 内容存在某个地方了，但是需要恢复一下，如果恢复现场呢？我们可以使用 git stash pop 命令，恢复的同时会把 stash 也删了，示例如下：
yhr@VM-24-15-ubuntu:~/gitcode$ git stash pop On branch dev2 Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: ReadMe no changes added to commit (use "git add" and/or "git commit -a") Dropped refs/stash@{0} (c3c2100ccd5938ee9b996b7456ee29bf7cfb5e00) 恢复完代码之后我们还可以继续完成开发，开发完后就可以提交了，例如：
yhr@VM-24-15-ubuntu:~/gitcode$ cat ReadMe Hello git Hello Git bbb on dev branch abcde i am coding... yhr@VM-24-15-ubuntu:~/gitcode$ vim ReadMe yhr@VM-24-15-ubuntu:~/gitcode$ git add . yhr@VM-24-15-ubuntu:~/gitcode$ git commit -m "md ReadMe:Done" [dev2 10e7b71] md ReadMe:Done 1 file changed, 2 insertions(+) yhr@VM-24-15-ubuntu:~/gitcode$ git branch * dev2 fix_bug master 但是我们注意到了，修复 bug 的内容，并没有在 dev2 上显示，此时的状态图为：
Master 分支目前最新的提交，是要领先于新建 dev2 时基于的 master 分支的提交的，所以我们在 dev2 中当然看不见修复 bug 的相关代码
我们的最终目的是要让 master 合并 dev2 分支的，那么正常情况下我们切回 master 分支直接合并即可，但这样其实是有⼀定风险的。是因为在合并分支时可能会有冲突，而代码冲突需要我们手动解决（在 master 上解决）。我们无法保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项目中，代码冲突不只一两行那么简单，有可能几十上百行，甚至更多，解决的过程中难免手误出错，导致错误的代码被合并到 master 上。
此时的状态为：
解决这个问题的一个好的建议就是：最好在自己的分支上合并下 master ，再让 master 去合并 dev，这样做的目的是又冲突可以在本地解决并进行测试，而不影响 master。此时的状态为：
最后 merge 合并 dev2 分支：
yhr@VM-24-15-ubuntu:~/gitcode$ git branch * dev2 fix_bug master #dev2分支合并master yhr@VM-24-15-ubuntu:~/gitcode$ git merge --no-ff -m "merge master" master Auto-merging ReadMe CONFLICT (content): Merge conflict in ReadMe Automatic merge failed; fix conflicts and then commit the result. #在dev2分支上修改 yhr@VM-24-15-ubuntu:~/gitcode$ vim ReadMe yhr@VM-24-15-ubuntu:~/gitcode$ git add . yhr@VM-24-15-ubuntu:~/gitcode$ git commit -m "merge master fix" [dev2 996e6ee] merge master fix #切换回master分支 yhr@VM-24-15-ubuntu:~/gitcode$ git checkout master Switched to branch 'master' #合并dev2分支 yhr@VM-24-15-ubuntu:~/gitcode$ git merge --no-ff -m "merge dev2" dev2 Merge made by the 'ort' strategy. ReadMe | 1 + 1 file changed, 1 insertion(+) yhr@VM-24-15-ubuntu:~/gitcode$ cat ReadMe Hello git Hello Git bbb on dev branch abcdef i am coding... Done! yhr@VM-24-15-ubuntu:~/gitcode$ git branch dev2 fix_bug * master #删除fix_bug分支 yhr@VM-24-15-ubuntu:~/gitcode$ git branch -d fix_bug Deleted branch fix_bug (was e035682). #删除dev2分支 yhr@VM-24-15-ubuntu:~/gitcode$ git branch -d dev2 Deleted branch dev2 (was 996e6ee). 4.4 删除临时分支
软件开发中，总有无穷无尽的新的功能要不断添加进来。
添加⼀个新功能时，你肯定不希望因为⼀些实验性质的代码，把主分支搞乱了，所以，每添加⼀个新功能，最好新建一个分支，我们可以将其称之为 feature 分支，在上面开发，完成后，合并，最后，删除该 feature 分支
可是，如果我们今天正在某个 feature 分支上开发了⼀半，被产品经理突然叫停，说是要停止新功能的开发。虽然白干了，但是这个 feature 分支还是必须就地销毁，留着无用了。这时使用传统的 git branch -d 命令删除分支的方法是不行的。演示如下：
yhr@VM-24-15-ubuntu:~/gitcode$ git checkout -b dev3 Switched to a new branch 'dev3' yhr@VM-24-15-ubuntu:~/gitcode$ vim ReadMe yhr@VM-24-15-ubuntu:~/gitcode$ git add . yhr@VM-24-15-ubuntu:~/gitcode$ git commit -m "md ReadMe" [dev3 63bfcad] md ReadMe 1 file changed, 1 insertion(+) yhr@VM-24-15-ubuntu:~/gitcode$ git checkout master Switched to branch 'master' yhr@VM-24-15-ubuntu:~/gitcode$ git branch -d dev3 #删除失败 error: The branch 'dev3' is not fully merged. If you are sure you want to delete it, run 'git branch -D dev3'. 直接使用传统的删除分支方式不行，按照提示，我们使用如下方式：
yhr@VM-24-15-ubuntu:~/gitcode$ git branch -D dev3 Deleted branch dev3 (was 63bfcad). yhr@VM-24-15-ubuntu:~/gitcode$ git branch * master 小结：分支管理的落地，更需要团队全员的共识与执行：从禁止直接提交主分支，到认真处理每一次代码冲突，再到定期清理冗余分支，每一个细节都在影响协作效率。如果你的团队还没有明确的规范，不妨从今天开始，从一份简单的分支命名规则、一次规范的 PR 提交做起。
结尾：
结语：最后，欢迎在评论区分享你的团队分支管理经验 —— 无论是踩过的坑、优化的技巧，还是定制化的流程方案，都能让更多开发者少走弯路。愿我们都能通过科学的分支管理，让开发协作更顺畅，让线上版本更稳定！
