Git 分支管理完全指南：从基础到团队协作

作为一名开发者，你是否经历过这些 "崩溃瞬间"：刚写完的功能代码被同事意外覆盖、线上突发 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 分支即可指向当前分支

查看我们当前的版本库：

bash 复制代码

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）

查看本地所有分支（* 表示当前分支）

bash 复制代码

yhr@VM-24-15-ubuntu:~/gitcode$ git branch
* master

<2> 创建分支（git branch <分支名>）

Git 支持我们查看或创建其它分支，创建分支时，Git 会基于 "当前分支的最新提交" 创建新指针，不会复制代码文件，在这里我们来创建第一个自己的分支 dev ，对应的命令为：

bash 复制代码

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分支下进行操作该怎么办呢？

bash 复制代码

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文件新增一行代码：

bash 复制代码

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文件：

bash 复制代码

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分支：

bash 复制代码

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 分支的指向，会发现两者的指向是不同的：

bash 复制代码

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 分支，合并分支的核心逻辑是 "将源分支的提交记录合并到目标分支"，需先切换到目标分支，再执行合并命令

bash 复制代码

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分支就可以删除掉，注意如果当前正处于某个分支下，就不能删除当前分支，如：

bash 复制代码

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'

而可以在其它分支下删除当前分支，如：

bash 复制代码

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 一步完成创建并切换的动作，示例如下：

bash 复制代码

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 文件，更改文件内容，并进行一次提交，如：

bash 复制代码

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 文件再进行一次修改，并进行提交，如下：

bash 复制代码

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只能试图把各自的修改合并起来，但这种合并就可能会有冲突，如下所示：

bash 复制代码

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：再次提交：

bash 复制代码

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 打印一下日志：

bash 复制代码

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 分支使用完毕后就可以删除了；

bash 复制代码

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 其实是由其它分支合并得到：

bash 复制代码

yhr@VM-24-15-ubuntu:~/gitcode$ git log --graph --abbrev-commit
* commit 2b90647 (HEAD -> master, dev2)
| Author: yhr <xxxxxxxxx@qq.com>
| Date:   Fri Dec 12 08:20:14 2025 +0800
| 
|     md ReadMe

我们在以后分支修改与提交过程可以采用这种模式，可以观察到历史信息与提交记录

no Fast forward 命令：git merge --no-ff -m "merge dev2" dev2

我们来实战一下：

切换回dev2分支，并修改ReadMe文件：

bash 复制代码

yhr@VM-24-15-ubuntu:~/gitcode$ git checkout -b dev2
Switched to a new branch 'dev2'
yhr@VM-24-15-ubuntu:~/gitcode$ vim ReadMe

提交一下：

bash 复制代码

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** 参数，把描述写进去。

bash 复制代码

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

合并后，查看分支历史：

bash 复制代码

yhr@VM-24-15-ubuntu:~/gitcode$ git log --graph --abbrev-commit
*   commit 8b22d5b (HEAD -> master)
|\  Merge: 2b90647 ba59442
| | Author: yhr <xxxxxxxxx@qq.com>
| | Date:   Fri Dec 12 08:28:26 2025 +0800
| | 
| |     merge dev2
| | 
| * commit ba59442 (dev2)
|/  Author: yhr <xxxxxxxxx@qq.com>
|   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，那我们应该怎么办？

bash 复制代码

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命令，可以将当前工作区信息进行储藏，被储存的内容可以在将来某个时间恢复出来

bash 复制代码

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，示例如下：

bash 复制代码

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 分支，并完成合并：

bash 复制代码

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 命令看看：

bash 复制代码

yhr@VM-24-15-ubuntu:~/gitcode$ git stash list
stash@{0}: WIP on dev2: ba59442 md ReadMe

工作现场还在，Git把 stash 内容存在某个地方了，但是需要恢复一下，如果恢复现场呢？我们可以使用 git stash pop 命令，恢复的同时会把 stash 也删了，示例如下：

bash 复制代码

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)

恢复完代码之后我们还可以继续完成开发，开发完后就可以提交了，例如：

bash 复制代码

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 分支：

bash 复制代码

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命令删除分支的方法是不行的。演示如下：

bash 复制代码

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'.

直接使用传统的删除分支方式不行，按照提示，我们使用如下方式：

bash 复制代码

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 提交做起。

结尾：

结语：最后，欢迎在评论区分享你的团队分支管理经验 ------ 无论是踩过的坑、优化的技巧，还是定制化的流程方案，都能让更多开发者少走弯路。愿我们都能通过科学的分支管理，让开发协作更顺畅，让线上版本更稳定！