Shell / Bash大前端
Git 分支管理：本地操作与协作流程
Git 分支管理通过功能隔离、并行开发和风险控制提升代码迭代效率。核心概念包括分支指针与 HEAD 指针。常用命令涵盖查看、创建、切换、合并及冲突解决。规范使用 Fast-forward 或 --no-ff 模式合并，配合 stash 处理临时中断，能有效保障主分支稳定并优化团队协作流程。
Git 分支管理通过功能隔离、并行开发和风险控制提升代码迭代效率。核心概念包括分支指针与 HEAD 指针。常用命令涵盖查看、创建、切换、合并及冲突解决。规范使用 Fast-forward 或 --no-ff 模式合并，配合 stash 处理临时中断，能有效保障主分支稳定并优化团队协作流程。
在 Git 版本控制中，分支是实现'并行开发''功能隔离''版本回溯'的核心机制。无论是修复紧急 Bug、开发新功能，还是尝试实验性代码，合理的分支管理都能让代码迭代更有序、协作更高效。本文将聚焦 Git 分支的本地操作（不涉及远程仓库），从分支核心概念切入，详解分支创建、切换、合并、冲突解决等关键操作，帮你掌握 Git 分支管理的核心逻辑。
在未使用分支时，所有代码提交都会线性堆叠在 master 分支上，一旦出现问题（如开发中的功能影响线上代码、实验性代码失败），很难快速回滚或隔离风险。而分支的本质是 '代码版本的独立副本'，其核心价值体现在三点：
分支就像是科幻电影里面的平行宇宙，当你正在电脑前努力学习 C++ 的时候，另一个你正在另一个平行宇宙里努力学习 JAVA。如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了 C++ 又学会了 JAVA！
master 分支指向最新的稳定提交，feature/login 分支指向登录功能的最新提交；HEAD 指针标记'当前所在的分支'，执行 git branch 命令时，带*的分支即为 HEAD 指向的当前分支。HEAD 严格来说不是指向提交，而是指向 master，master 才是指向提交的，所以，HEAD 指向的就是当前分支。
每次提交，master 分支都会向前移动一步，这样，随着你不断提交，master 分支的线也越来越长，而 HEAD 只要一直指向 master 分支即可指向当前分支。
通过查看当前的版本库，我们能理清我们的思路：
[Lotso@VM-4-4-centos ~]$ cat .git/HEAD
ref: refs/heads/master
[Lotso@VM-4-4-centos ~]$ cat .git/refs/heads/master
9817f602e58a6c44d5ec63a23e0b38defe043080
（1）查看分支（git branch）
# 查看本地所有分支（* 表示当前分支）
[Lotso@VM-4-4-centos gitcode]$ git branch
* master
（2）创建分支（git branch <分支名>）
Git 支持我们查看或创建其它分支，创建分支时，Git 会基于'当前分支的最新提交'创建新指针，不会复制代码文件，在这里我们来创建第一个自己的分支 dev，对应的命令为：
# 创建分支
[Lotso@VM-4-4-centos gitcode]$ git branch dev
[Lotso@VM-4-4-centos gitcode]$ git branch dev
* master
当我们创建新的分支后，Git 新建了一个指针叫 dev，* 表示当前 HEAD 指向的分支是 master 分支，另外，可以通过目录结构发现，新的 dev 分支：
[Lotso@VM-4-4-centos gitcode]$ ls .git/refs/heads/
dev master
[Lotso@VM-4-4-centos gitcode]$ cat .git/refs/heads/*
7803308c167a495b3d18e6a3ba1cab43a9749872
7803308c167a495b3d18e6a3ba1cab43a9749872
我们会发现目前 dev 和 master 指向同一个修改。并且也可以验证 HEAD 目前是指向 master 的。
[Lotso@VM-4-4-centos gitcode]$ cat .git/HEAD
ref: refs/heads/master
一张图总结：
（3）切换分支（git checkout）
那我们如何切换到 dev 分支下进行开发呢？使用 git checkout 命令即可完成切换，示例如下：
# 前提是 dev 分支已经通过 git branch 创建过了
[Lotso@VM-4-4-centos gitcode]$ git checkout dev
Switched to branch 'dev'
[Lotso@VM-4-4-centos gitcode]$ git branch
* dev master
[Lotso@VM-4-4-centos gitcode]$ cat .git/HEAD
ref: refs/heads/dev
补充：创建并切换分支（一步操作）
[Lotso@VM-4-4-centos gitcode]$ git checkout -b dev
Switched to branch 'dev'
[Lotso@VM-4-4-centos gitcode]$ git branch
* dev master
我们发现 HEAD 已经指向了 dev，就表示我们已经成功切换到了 dev 上！
接下来，在 dev 分支下修改 move.txt 文件，新增一行内容，并进行一次提交操作：
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
hello world
[Lotso@VM-4-4-centos gitcode]$ echo "add branch1" >> move.txt
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
hello world
add branch1
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify move.txt"
[dev aee0d50] modify move.txt
1 file changed, 1 insertion(+)
现在，dev 分支的工作完成，我们就可以切换回 master 分支：
[Lotso@VM-4-4-centos gitcode]$ git checkout master
Switched to branch 'master'
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
hello world
切换回 master 分支后，发现 move.txt 文件中新增的内容不见了！！，赶紧切回 dev 看看
[Lotso@VM-4-4-centos gitcode]$ git checkout dev
Switched to branch 'dev'
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
hello world
add branch1
在 dev 分支上，内容还在。为什么会出现这个现象呢？我们来看看 dev 分支和 master 分支的指向，会发现两者的指向是不同的：
[Lotso@VM-4-4-centos gitcode]$ cat .git/refs/heads/dev
aee0d504f1435726a2e2a4187fdef061c8e87436
[Lotso@VM-4-4-centos gitcode]$ cat .git/refs/heads/master
7803308c167a495b3d18e6a3ba1cab43a9749872
看到这里大家应该就都明白了，因为我们是在 dev 分支上提交的，而 master 分支此刻的提交点并没有变，此时的状态如下图所示：
现在当切换到 master 分支后，HEAD 就直接指向 master 了，当然看不到提交了！
分支开发完成后，需要将代码合并到目标分支；若合并时出现代码冲突，需手动解决；当然，删除分支也是必不可少的操作。
git merge）：将分支代码融入目标分支为了在 master 主分支上能看到新的提交，就需要将 dev 分支合并到 master 分支，合并分支的核心逻辑是**'将源分支的提交记录合并到目标分支'**，需先切换到目标分支，再执行合并命令。
[Lotso@VM-4-4-centos gitcode]$ git branch
* dev master
[Lotso@VM-4-4-centos gitcode]$ git checkout master # 切换到 master 上进行合并
Switched to branch 'master'
[Lotso@VM-4-4-centos gitcode]$ git merge dev # 合并 dev 分支
Updating 7803308..aee0d50 Fast-forward
move.txt | 1 + 1 file changed, 1 insertion(+)
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
hello world
add branch1
git merge 命令用于合并指定分支到当前分支。合并后，master 就能看到 dev 分支提交的内容。
我们会看到上面合并之后，会出现 Fast-forward 代表'快进模式'，也就是直接把 master 指向 dev 的当前提交，所以合并速度非常快。当然，也不是每次合并都能 Fast-forward，我们后面还没讲其它方式的合并。
git branch -d dev）：在其它分支上进行删除当前分支合并完成后，dev 分支对于我们来说就没用了，那么 dev 分支就可以删除掉，注意如果当前正处于某个分支下，就不能删除当前分支，如：
[Lotso@VM-4-4-centos gitcode]$ git branch
[Lotso@VM-4-4-centos gitcode]$ git branch
* dev master
[Lotso@VM-4-4-centos gitcode]$ git branch -d dev
error: Cannot delete branch 'dev' checked out at '/home/Lotso/gitcode'
而可以在其它分支下删除当前分支，如：
[Lotso@VM-4-4-centos gitcode]$ git branch dev
* master
[Lotso@VM-4-4-centos gitcode]$ git branch -d dev
Deleted branch dev (was aee0d50).
[Lotso@VM-4-4-centos gitcode]$ git branch
* master
此时的状态如下图所示：
因为创建，合并，删除分支非常快，所以 Git 鼓励你使用分支完成某个任务，合并后再删除分支，这和直接在 master 分支上工作效果是一样的，但过程更安全。
若合并的两个分支修改了**'同一文件的同一部分'（如 master 分支和 dev 都修改了 move.txt），Git 无法自动判断保留哪部分代码，会触发'合并冲突'**，此时需手动解决。
为了演示这个问题，创建一个新的分支 dev1，并切换至目标分支，我们可以使用**git checkout -b dev1**一步完成创建并切换的动作，示例如下：
[Lotso@VM-4-4-centos gitcode]$ git checkout -b dev1
Switched to a new branch 'dev1'
[Lotso@VM-4-4-centos gitcode]$ git branch
* dev1 master
在 dev 分支下修改 move.txt 文件，更改文件内容，并进行一次提交，如：
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
hello world
add branch1
[Lotso@VM-4-4-centos gitcode]$ echo "bdd new branch" > move.txt # 将文件内容直接改成 bdd new branch
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
bdd new branch
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify move.txt"
[dev1 3252095] modify move.txt
1 file changed, 1 insertion(+), 2 deletions(-)
切换至 master 分支，观察 move.txt 文件内容：
[Lotso@VM-4-4-centos gitcode]$ git checkout master
Switched to branch 'master'
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
hello world
add branch1
我们切换回来会发现文件内容还没变，这个我们上面讲过是因为还没提交，这个很好现在理解。那么我们此时如果在 move.txt 文件再进行一次修改，并进行提交，如下：
[Lotso@VM-4-4-centos gitcode]$ git branch dev1
* master
[Lotso@VM-4-4-centos gitcode]$ echo "cdd new branch" > move.txt
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
cdd new branch
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify move.txt"
[master 800feaa] modify move.txt
1 file changed, 1 insertion(+), 2 deletions(-)
现在，master 分支和 dev1 分支都分别有了新的提交，变成了这样：
这种情况下，Git 只能试图把各自的修改合并起来，但这种合并就可能会有冲突，如下所示：
[Lotso@VM-4-4-centos gitcode]$ git merge dev1
Auto-merging move.txt
CONFLICT (content): Merge conflict in move.txt
Automatic merge failed; fix conflicts and then commit the result.
[Lotso@VM-4-4-centos gitcode]$ git status
# On branch master
# You have unmerged paths.
# (fix conflicts and run "git commit")
#
# Unmerged paths:
# (use "git add <file>..." to mark resolution)
#
# both modified: move.txt
# no changes added to commit (use "git add" and/or "git commit -a")
我们发现 move.txt 文件有冲突后，可以直接查看文件内容，要说的是 Git 会用 <<<<<<<, =======, >>>>>>> 来标记出不同分支的冲突内容，如下所示：
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
<<<<<<< HEAD
cdd new branch
=======
bdd new branch
>>>>>>> dev1
此时我们需要手动调整冲突代码，并需要再次提交修正后的结果！！！(再次提交很重要，不要忘记)
[Lotso@VM-4-4-centos gitcode]$ nano move.txt
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
bdd new branch
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "solve conflict"
[master cf9fd59] solve conflict
到这里冲突就解决完成，此时的状态变成了
我们使用带参数的 git log 也可以看到分支的合并情况，具体大家可以自行搜索**git log**的用法：
[Lotso@VM-4-4-centos gitcode]$ git log --graph --pretty=oneline --abbrev-commit
* cf9fd59 solve conflict |
* 3252095 modify move.txt
* | 800feaa modify move.txt
|/
* aee0d50 modify move.txt
* 7803308 move
最后，不要忘记 dev1 分支使用完毕后就可以删除了；
[Lotso@VM-4-4-centos gitcode]$ git branch dev1
* master
[Lotso@VM-4-4-centos gitcode]$ git branch -d dev1
Deleted branch dev1 (was 3252095).
通常合并分支时，如果可能，Git 会采用 Fast forward 模式，还记得如果我们采用 Fast forward 模式之后，形成的合并结果是什么呢？回顾一下
在这种 Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是 merge 进来的还是正常提交的。
但在合并冲突部分，我们也能看到通过解决冲突问题，会再进行下一次提交，得到的最终状态为：
那么这就不是 Fast forward 模式了。这样的好处是，从历史分支上就可以看出分支信息，例如我们现在已经删除了在合并冲突部分创建的 dev1 分支，但依旧能看到 master 其实是由其它分支合并得到：
hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit
* 2976afc (HEAD -> master) merge ReadMe |
* c594fd1 modify ReadMe
* | c10f6d0 modify ReadMe
|/
Git 支持我们强制禁用 Fast forward 模式，那么就会在 merge 时生成一个新的 commit，这样，从分支历史上就可以看出分支信息。
下面我们实战一下 --no-ff 方式的 git merge。首先，创建新的分支 dev2，并切换至新的分支：
[Lotso@VM-4-4-centos gitcode]$ git checkout -b dev2
Switched to a new branch 'dev2'
修改 test.txt 文件，并提交一个新的 commit
[Lotso@VM-4-4-centos gitcode]$ echo "a,b,c,d" > test.txt
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify test.txt"
[dev2 23e1ffd] modify test.txt
1 file changed, 1 insertion(+)
切换回 master 分支，开始合并：
[Lotso@VM-4-4-centos gitcode]$ git checkout master
Switched to branch 'master'
[Lotso@VM-4-4-centos gitcode]$ git merge --no-ff -m"merge with no-ff"dev2
fatal: No commit specified and merge.defaultToUpstream not set.
[Lotso@VM-4-4-centos gitcode]$ git merge --no-ff -m"merge with no-ff" dev2
Merge made by the 'recursive' strategy.
test.txt | 1 + 1 file changed, 1 insertion(+)
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d
请注意**--no-ff**参数，表示禁用 Fast forward 模式。禁用 Fast forward 模式后合并会创建一个新的 commit，所以加上 -m 参数，把描述写进去。
合并后，查看分支历史：
[Lotso@VM-4-4-centos gitcode]$ git log --graph --pretty=oneline --abbrev-commit
* 8de46c8 merge with no-ff |
* 23e1ffd modify test.txt
|/
可以看到，不使用 Fast forward 模式，merge 后就像这样：
所以在合并分支时，加上 --no-ff 参数就可以普通合并模式，合并后的历史有分支，能看出曾经做过合并，而 Fast forward 合并后就看不出来曾经做过合并。
在实际开发中，我们应该按照几个基本原则进行分支管理： 首先，master 分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活； 那在哪里干活呢？干活都在 dev 分支上，也就是说，dev 分支是不稳定的，到某个时候，比如 1.0 版本发布时，再把 dev 分支合并到 master 上，在 master 分支上发布 1.0 版本； 你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合并就可以了。 所以，团队合作的分支看起来就像这样：
假如我们现在正在 dev2 分支上进行开发，开发到一半，突然发现 master 分支上面有 bug。需要解决。在 Git 中，每个 bug 都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
可现在 dev 的代码在工作区中开发了一半，还无法提交，怎么办？例如：
[Lotso@VM-4-4-centos gitcode]$ git branch
* dev2 master
[Lotso@VM-4-4-centos gitcode]$ echo "I am coding" >> test.txt
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d
I am coding
[Lotso@VM-4-4-centos gitcode]$ git status
# On branch dev2
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: test.txt
# no changes added to commit (use "git add" and/or "git commit -a")
Git 提供了**git stash**命令，可以将当前工作区信息进行储藏，被储存的内容可以在将来某个时间恢复出来
[Lotso@VM-4-4-centos gitcode]$ git stash
Saved working directory and index state
WIP on dev2: 23e1ffd modify test.txt
HEAD is now at 23e1ffd modify test.txt
[Lotso@VM-4-4-centos gitcode]$ git status
# On branch dev2
nothing to commit, working directory clean
再查看工作区，就是干净的 (除非有没有被 Git 管理的文件)，因此可以放心的创建分支来修复 bug。
储藏 dev2 工作区后，由于我们要基于 master 分支修复 bug，所以需要切回 master 分支，再新建临时分支来修复 bug，示例如下：
[Lotso@VM-4-4-centos gitcode]$ git checkout master # 切回 master
Switched to branch 'master'
[Lotso@VM-4-4-centos gitcode]$ git checkout -b fix_bug # 新建并切换到 fix_bug 分支
Switched to a new branch 'fix_bug'
[Lotso@VM-4-4-centos gitcode]$ vim test.txt # 修复 bug，忘记写 e 了
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d,e
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "fix bug"
[fix_bug a5b2a26] fix bug
1 file changed, 1 insertion(+), 1 deletion(-)
修复完成后，切换到 master 分支，并完成合并，最后删除 fix_bug 分支：
[Lotso@VM-4-4-centos gitcode]$ git checkout master
Switched to branch 'master'
[Lotso@VM-4-4-centos gitcode]$ git merge --no-ff -m "merge fix_bug branch" fix_bug
Merge made by the 'recursive' strategy.
test.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d,e
[Lotso@VM-4-4-centos gitcode]$ git branch -d fix_bug
Deleted branch fix_bug (was a5b2a26).
至此，bug 的修复工作已经做完了，我们还要继续回到 dev2 分支进行开发，切换回 dev2 分支：
[Lotso@VM-4-4-centos gitcode]$ git checkout dev2
Switched to branch 'dev2'
[Lotso@VM-4-4-centos gitcode]$ git status
# On branch dev2
nothing to commit, working directory clean
工作区是干净的，刚才的工作存到哪里去了？用**git stash list**命令看看：
[Lotso@VM-4-4-centos gitcode]$ git stash list
stash@{0}: WIP on dev2: 23e1ffd modify test.txt
工作现场还在，Git 把 stash 内容存在某个地方了，但是需要恢复一下，如果恢复现场呢？我们可以使用 git stash pop 命令，恢复的同时会把 stash 也删了，示例如下：
[Lotso@VM-4-4-centos gitcode]$ git stash pop
# On branch dev2
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: test.txt
# no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0}(c76d0003c79b9bbdf96586c6e645c5efb6)
再次查看的时候，我们已经发现没有现场可以恢复了
[Lotso@VM-4-4-centos gitcode]$ git stash list
[Lotso@VM-4-4-centos gitcode]$
另外，恢复现场也可以采用 git stash apply 恢复，但是恢复后，stash 内容并不删除，你需要用 git stash drop 来删除；
你可以多次 stash，恢复的时候，先用 git stash list 查看，然后恢复指定的 stash，用命令 git stash apply stash@{0}，这部分大家可以自己去试试。
恢复完代码之后我们还可以继续完成开发，开发完后就可以提交了，例如：
[Lotso@VM-4-4-centos gitcode]$ vim test.txt
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d
I am coding...Done!
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify"
[dev2 8127dcc] modify
1 file changed, 1 insertion(+)
但是我们注意到了，修复 bug 的内容，并没有在 dev2 上显示，此时的状态图为：
Master 分支目前最新的提交，是要领先于新建 dev2 时基于的 master 分支的提交的，所以我们在 dev2 中当然看不见修复 bug 的相关代码。
我们的最终目的是要让 master 合并 dev2 分支的，那么正常情况下我们切回 master 分支直接合并即可，但这样其实是有一定风险的。
是因为在合并分支时可能会有冲突，而代码冲突需要我们手动解决（在 master 上解决）。我们无法
保证对于冲突问题可以正确地一次性解决掉，因为在实际的项目中，代码冲突不只一两行那么简单，
有可能几十上百行，甚至更多，解决的过程中难免手误出错，导致错误的代码被合并到 master 上。
此时的状态为：
解决这个问题的一个好的建议就是：最好在自己的分支上合并下 master，再让 master 去合并 dev，这样做的目的是又冲突可以在本地解决并进行测试，而不影响 master。此时的状态为：
对应的实操演示如下，要说明的是，以下演示的 merge 操作，没有使用 --no-ff，但上述的图示是禁用Fast forward 了模式后得出的，主要为了方便解释问题。
# dev 合并 master
[Lotso@VM-4-4-centos gitcode]$ git branch
* dev2 master
[Lotso@VM-4-4-centos gitcode]$ git merge master
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.
# 发生冲突
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
<<<<<<< HEAD
a,b,c,d
I am coding...Done!
=======
a,b,c,d,e
>>>>>>> master
# 解决冲突并重新提交
[Lotso@VM-4-4-centos gitcode]$ vim test.txt
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d,e
I am coding...Done!
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "merge master"
[dev2 d07c456] merge master
[Lotso@VM-4-4-centos gitcode]$ git status
# On branch dev2
nothing to commit, working directory clean
# 切回 master
[Lotso@VM-4-4-centos gitcode]$ git checkout master
Switched to branch 'master'
# master 合并 dev2 ---无需解决冲突!!!
[Lotso@VM-4-4-centos gitcode]$ git merge dev2
Updating c8358de..d07c456 Fast-forward
test.txt | 1 + 1 file changed, 1 insertion(+)
[Lotso@VM-4-4-centos gitcode]$ git status
# On branch master
nothing to commit, working directory clean
# 删除 dev2 分支
[Lotso@VM-4-4-centos gitcode]$ git branch -d dev2
Deleted branch dev2 (was d07c456).
软件开发中，总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个分支，我们可以将其称之为 feature 分支，在上面开发，完成后，合并，最后，删除该 feature 分支。
可是，如果我们今天正在某个 feature 分支上开发了一半，被产品经理突然叫停，说是要停止新功能的开发。虽然白干了，但是这个 feature 分支还是必须就地销毁，留着无用了。这时使用传统的 git branch -d 命令删除分支的方法是不行的。演示如下：
# 新增并切换到 dev3 分支
[Lotso@VM-4-4-centos gitcode]$ git checkout -b dev3
Switched to a new branch 'dev3'
# 开始开发新功能并提交
[Lotso@VM-4-4-centos gitcode]$ vim test.txt
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d,e
I am coding...Done!
I am writing new features……
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify new features"
[dev3 c9bf49d] modify new features
1 file changed, 1 insertion(+)
# 此时新功能叫停
# 切回 master 准备删除 dev3
[Lotso@VM-4-4-centos gitcode]$ git checkout master
Switched to branch 'master'
# 常规删除 dev3 分支时失败
[Lotso@VM-4-4-centos 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'.
直接使用传统的删除分支方式不行，按照提示，我们使用如下方式：
[Lotso@VM-4-4-centos gitcode]$ git branch -D dev3
Deleted branch dev3 (was c9bf49d).
小结： 分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了 50% 的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。 现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上 正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。 并且 Git 无论创建、切换和删除分支，Git 在 1 秒钟之内就能完成！无论你的版本库是 1 个文件还是 1 万个文件。
Git 分支管理是版本控制的核心能力之一，它让我们在'功能开发'
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML转Markdown在线工具，online
通过删除不必要的空白来缩小和压缩JSON。 在线工具，JSON 压缩在线工具，online
将JSON字符串修饰为友好的可读格式。 在线工具，JSON美化和格式化在线工具，online