分支管理是Git的杀手级功能之一。分支：就是科幻中的平行宇宙，当你正在电脑面前学习C++的时候，另一个你正在另外一个平行宇宙里面学习Java。如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平时宇宙合并了，结果，你既学习了C++,也学习了Java.
在版本回退里，你已经知道，每次提交，Git都把他们串成一条时间线，这条时间线就可以理解是一个分支。截止到目前，在Git里，这个分支叫主分支，即 master 分支。
再来理解一下HEAD，HEAD严格来说不是指向提交，而是指向master,master才是指向提交的，所以，HEAD指向的就是当前分支。
每次提交，master分支都会向前移动一次，这样随着你不断的提交，master分支的线也越来越长，而HEAD只要一直指向master分支即可指向当前分支。
我们可以使用git log来验证：
[Lxy@aliyun gitcode]$ cat .git/HEAD
ref: refs/heads/master
[Lxy@aliyun gitcode]$ cat .git/refs/heads/master
7804665c14faf8e894e023f04576ba6b17632f85
[Lxy@aliyun gitcode]$ git log
commit 7804665c14faf8e894e023f04576ba6b17632f85
Author: Lxy <2357246060@qq.com>
Date: Mon Jun 26 13:48:27 2023 +0800
delete file1
Git支持我们查看或创建其他分支，在这里我们来创建第一个自己的分支dev，对应的命令为：
查看当前本地所有分支
git branch
*表示当前HEAD指向的分支是master分支。
[Lxy@aliyun gitcode]$ git branch
* master
创建新的分支
git branch dev # 新建分支dev
[Lxy@aliyun gitcode]$ git branch dev
[Lxy@aliyun gitcode]$ git branch
dev
* master
当我们创建新的分支后，Git新建了一个指针叫dev,创建完成后，我们使用git branch来查看当前有的分支。
另外，也可以通过目录结构看到新的分支：
[Lxy@aliyun gitcode]$ tree .git/refs/heads/
.git/refs/heads/
├── dev
└── master
0 directories, 2 files
[Lxy@aliyun gitcode]$ ls .git/refs/heads/
dev master
[Lxy@aliyun gitc
发现目前dev和master指向同一个修改。并且也可以验证下HEAD目前是指向master的。
现在已经成功创建了新的dev分支，那么如何切换到dev分支下进行开发呢？使用git checkout命令即可完成切换：
[Lxy@aliyun gitcode]$ git checkout dev
Switched to branch 'dev'
[Lxy@aliyun gitcode]$ git branch
* dev
master
[Lxy@aliyun gitcode]$ cat .git/HEAD
ref: refs/heads/dev
此时，HEAD已经指向了dev，就表示我们已经成功的切换到了dev上！接下来，在dev分支上修改ReadMe文件，新增一行内容，并进行一次提交操作。
[Lxy@aliyun gitcode]$ vim ReadMe
[Lxy@aliyun gitcode]$ cat ReadMe
hello git
hello world
hello ReadMe
git --version
I am Coding in dev!
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "modify ReadMe"
[dev 2690f7f] modify ReadMe
1 file changed, 2 insertions(+)
[Lxy@aliyun gitcode]$ git status
# On branch dev
nothing to commit, working directory clean
现在，dev分支的工作完成，我们就可以切回master分支：
[Lxy@aliyun gitcode]$ git checkout master
Switched to branch 'master'
[Lxy@aliyun gitcode]$ cat ReadMe
hello git
hello world
hello ReadMe
git --version
切换回master分支后，发现ReadMe文件中新增的内容不见了！！我们再切回dev看看
[Lxy@aliyun gitcode]$ git checkout dev
Switched to branch 'dev'
[Lxy@aliyun gitcode]$ cat ReadMe
hello git
hello world
hello ReadMe
git --version
I am Coding in dev!
在dev分支上，内容还在，为什么会出现这个现象呢？我们再来看看dev分支和master分支指向，发现两个指向的提交是不一样的：
[Lxy@aliyun gitcode]$ cat .git/refs/heads/dev
2690f7fcf1ccc686ffd88d2780140d4cc1cd493f
[Lxy@aliyun gitcode]$ cat .git/refs/heads/master
7804665c14faf8e894e023f04576ba6b17632f85
[Lxy@aliyun gitcode]$ git cat-file -p 2690f7fcf1ccc686ffd88d2780140d4cc1cd493f
tree 68c0c174cb2cbb0258f1979bfa92ff0fe06ec5d6
parent 7804665c14faf8e894e023f04576ba6b17632f85
author Lxy <2357246060@qq.com> 1689396001 +0800
committer Lxy <2357246060@qq.com> 1689396001 +0800
modify ReadMe
看到这里我们就能明白了，因为我们是在dev分支上提交的，而master分支此刻的提交点并没有变，此时的状态如图所示：
切换到 master分支时，HEAD就指向了master，当然看不到提交了。
为了在master主分支上能看到新的提交，就需要将dev分支合并到master分支，示例如下：
[Lxy@aliyun gitcode]$ git checkout master #切换到master上进行合并
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git merge dev # 合并dev分支
Updating 7804665..2690f7f
Fast-forward
ReadMe | 2 ++
1 file changed, 2 insertions(+)
[Lxy@aliyun gitcode]$ cat ReadMe # 发现已经成功了
hello git
hello world
hello ReadMe
git --version
I am Coding in dev!
git merge命令用于合并指定分支到当前分支。合并后，master就能够看到dev分支提交的内容。
[Lxy@aliyun gitcode]$ cat .git/refs/heads/master
2690f7fcf1ccc686ffd88d2780140d4cc1cd493f
[Lxy@aliyun gitcode]$ cat .git/refs/heads/dev
2690f7fcf1ccc686ffd88d2780140d4cc1cd493f
[Lxy@aliyun gitcode]$ cat .git/HEAD
ref: refs/heads/master
此时的状态图如下所示：
Fast-forward代表"快进模式"，也就是直接把master指向dev的当前提交，所以合并速度非常快，当然，也不是每次合并都能Fast-forward。
合并完成后，dev分支对于我们来说就没用了，那么dev分支就可以被删除掉，注意如果当前正处于某分支下，就不能删除当前分支，如：
[Lxy@aliyun gitcode]$ git branch -d dev
Deleted branch dev (was 2690f7f).
[Lxy@aliyun gitcode]$ tree .git/refs/heads/
.git/refs/heads/
└── master
0 directories, 1 file
此时的状态如下图所示：
因为创建、合并、删除分支非常快，所以Git鼓励我们使用分支完成某个任务，合并后再删除分支，这和直接在master分支上工作效果是一样的，但过程更安全。
可是，在实际分支合并的时候，并不是想合并就能合并成功的，有时我们可能遇到代码冲突的问题。为了演示这个问题，我们创建一个新的分支dev1,并切换到目标分支，我们可以使用git checkout -b dev1 一步完成创建并切换的动作。
[Lxy@aliyun gitcode]$ git checkout -b dev1
Switched to a new branch 'dev1'
[Lxy@aliyun gitcode]$ git branch
* dev1
master
在dev1分支下修改ReadMe文件，更改文件内容如下，并进行一次提交：
[Lxy@aliyun gitcode]$ vim ReadMe
[Lxy@aliyun gitcode]$ cat ReadMe
hello git
hello world
hello ReadMe
git --version
I am Coding in dev!
I am Coding in dev1...... #新增内容
[Lxy@aliyun gitcode]$ git add . #提交修改
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[dev1 50ba571] md ReadMe
1 file changed, 2 insertions(+)
切换至master，观察ReadMe文件内容：
[Lxy@aliyun gitcode]$ git checkout master #切换至master分支
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git branch #查看当前所有分支
dev1
* master
[Lxy@aliyun gitcode]$ cat ReadMe
hello git
hello world
hello ReadMe
git --version
I am Coding in dev!
我们发现，切回来之后，文件内容又变成了老的版本，这和我们预期一致，我们现在也能够理解。此时在master分支上，我们对ReadMe文件再进行一次修改，并进行提交，如下：
[Lxy@aliyun gitcode]$ vim ReadMe
[Lxy@aliyun gitcode]$ cat ReadMe
hello git
hello world
hello ReadMe
git --version
I am Coding in dev!
i am Coding in master ......
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[master a8d6985] md ReadMe
1 file changed, 3 insertions(+)
现在，master分支和dev1分支都有各自的新的提交变成了这样：
这种情况下，Git只能试图把各自的修改合并起来，但这种合并就可能会有冲突，如下所示：
[Lxy@aliyun gitcode]$ git merge dev1 #合并dev1到master
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
[Lxy@aliyun 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: ReadMe
#
no changes added to commit (use "git add" and/or "git commit -a")
发现ReadMe文件有冲突后，可以直接查看文件内容，要说的是Git会用<<<<<<<,============,>>>>>>>>>>>>>来标记出不同的分支的冲突内容，如下图所示：
[Lxy@aliyun gitcode]$ cat ReadMe
hello git
hello world
hello ReadMe
git --version
I am Coding in dev!
<<<<<<< HEAD
i am Coding in master ......
=======
I am Coding in dev1......
>>>>>>> dev1
此时我们必须要手动调整冲突代码，并且需要再次提交修改后的结果（再次提交很重要，切勿忘记）
[Lxy@aliyun gitcode]$ vim ReadMe
[Lxy@aliyun gitcode]$ cat ReadMe
hello git
hello world
hello ReadMe
git --version
I am Coding in dev!
i am Coding in master ......
I am Coding in dev1.....
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[master 832d4a2] md ReadMe
到这里冲突就解决了，此时的状态变成了
用带参数的git log也可以看到分支的合并过程
[Lxy@aliyun gitcode]$ git log --graph --pretty=oneline --abbrev-commit
* 832d4a2 md ReadMe
|\
| * 50ba571 md ReadMe
* | a8d6985 md ReadMe
|/
* 2690f7f modify ReadMe
* 7804665 delete file1
* 2f86525 第三次修改ReadMe
* 02716a9 修改ReadMe
* 0c3e2b8 add file2
* cfd11ac add file
* 3b64204 add first file
最后不要忘记dev1分支使用完毕后就可以删除了：
[Lxy@aliyun gitcode]$ git branch
dev1
* master
[Lxy@aliyun gitcode]$ git branch -d dev1
Deleted branch dev1 (was 50ba571).
[Lxy@aliyun gitcode]$ git branch
* master
通常合并分支时，如果可能，Git会采用Fast forward模式。在这种Fast forward模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是 merge进来的还是正常提交的。
但是合并冲突部分，我们也看到通过解决冲突问题，会再进行一次新的提交，得到的最终状态为：
那么这种就不是Fast forward模式了，这样的好处是，从分支历史上就可以看出分支信息。例如我们现在已经删除了在合并冲突部分创建的dev1分支，但依旧能看到 master其实是由其他分支合并得到：
[Lxy@aliyun gitcode]$ git branch #查看当前分支
* master
[Lxy@aliyun gitcode]$ git branch dev1 #创建dev1分支
[Lxy@aliyun gitcode]$ git checkout dev1 #切换到dev1分支
Switched to branch 'dev1'
[Lxy@aliyun gitcode]$ git branch
* dev1
master
[Lxy@aliyun gitcode]$ vim ReadMe #修改ReadMe文件
[Lxy@aliyun gitcode]$ git add . #提交修改
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[dev1 f41d236] md ReadMe
1 file changed, 3 insertions(+)
[Lxy@aliyun gitcode]$ git checkout master #切换到master分支
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git merge --no-ff -m "merge dev1" dev1 #将dev1分支使用no-ff方式合并到master分支
Merge made by the 'recursive' strategy.
ReadMe | 3 +++
1 file changed, 3 insertions(+)
[Lxy@aliyun gitcode]$ cat ReadMe #查看ReadMe文件内容
hello git
hello world
hello ReadMe
git --version
I am Coding in dev!
i am Coding in master ......
I am Coding in dev1.....
I am Coding in dev1..................
[Lxy@aliyun gitcode]$ git log --graph --abbrev-commit #查看日志信息
* commit 9c17f2d
|\ Merge: 832d4a2 f41d236
| | Author: Lxy <2357246060@qq.com>
| | Date: Sun Jul 16 18:21:49 2023 +0800
| |
| | merge dev1 #这里能够看到合并的信息
| |
| * commit f41d236
|/ Author: Lxy <2357246060@qq.com>
| Date: Sun Jul 16 18:20:46 2023 +0800
|
| md ReadMe
|
* commit 832d4a2
|\ Merge: a8d6985 50ba571
| | Author: Lxy <2357246060@qq.com>
| | Date: Sat Jul 15 13:10:06 2023 +0800
| |
| | md ReadMe
| |
| * commit 50ba571
| | Author: Lxy <2357246060@qq.com>
| | Date: Sat Jul 15 12:59:18 2023 +0800
| |
| | md ReadMe
| |
* | commit a8d6985
|/ Author: Lxy <2357246060@qq.com>
| Date: Sat Jul 15 13:05:11 2023 +0800
|
| md ReadMe
|
* commit 2690f7f
| Author: Lxy <2357246060@qq.com>
| Date: Sat Jul 15 12:40:01 2023 +0800
Git支持我们强制禁用Fast forword模式，那么就会在merge时生成一个新的commit,这样，从分支历史上就可以看到分支信息。
说明一下：
--no--ff参数，表示禁用Fast forward模式，禁用Fast forward模式后会合并会创建一个新的commit，所以加上-m参数，把描述写进去。合并后可以查看历史分支：
git log --graph --pretty=oneline --abbrev-commit
不使用Fast forward模式，merge后就像这样：
所以在合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是 非常稳定的，也就是仅用发布新版本，平时不能在上面干活：因此，我们平时开发都是在dev分支上面的，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本.
所以，每个人都有自己的分支，时不时地往dev分支上合并就可以了。所以团队合作的分支看起来就像这样：
假如我们现在正在dev2分支上进行开发，开发到一半，突然发现master分支上有bug，需要解决。在Git中，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。可现在dev2的代码在工作区中开发了一般，还无法提交，Git提供了git stash命令，可以将当前的工作区信息进行储藏，被储藏的内容可以在将来某个时间恢复出来。
[Lxy@aliyun gitcode]$ git branch dev2 #创建dev2分支
[Lxy@aliyun gitcode]$ git checkout dev2 #切换至dev2分支
Switched to branch 'dev2'
[Lxy@aliyun gitcode]$ vim ReadMe #修改ReadMe文件
[Lxy@aliyun gitcode]$ cat ReadMe #查看ReadMe文件
hello git
hello world
hello ReadMe
I am Codeing in dev2............
[Lxy@aliyun gitcode]$ git checkout master #切换至master
M ReadMe
Switched to branch 'master'
[Lxy@aliyun gitcode]$ cat ReadMe #查看ReadMe文件
hello git
hello world
hello ReadMe
I am Codeing in dev2............
[Lxy@aliyun gitcode]$ git status #查看状态
# On branch master
# 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: ReadMe
#
no changes added to commit (use "git add" and/or "git commit -a")
[Lxy@aliyun gitcode]$ git checkout dev2
M ReadMe
Switched to branch 'dev2'
[Lxy@aliyun gitcode]$ git stash #储存文件
Saved working directory and index state WIP on dev2: 9c17f2d merge dev1
HEAD is now at 9c17f2d merge dev1
[Lxy@aliyun gitcode]$ git status #再查看状态
# On branch dev2
nothing to commit, working directory clean
[Lxy@aliyun gitcode]$ cat ReadMe #再次查看master的ReadMe文件内容发现恢复到之前
hello git
hello world
hello ReadMe
git --version
I am Coding in dev!
i am Coding in master ......
I am Coding in dev1.....
I am Coding in dev1..................
用git status查看工作区，就是干净的（除非拥有 - 没有被Git管理的文件），因此可以放心地创建分支来修复bug。
储藏dev2工作区之后，由于我们要基于master分支，在创建临时分支来修复bug。
[Lxy@aliyun gitcode]$ git checkout master #切回master
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git checkout -b fix_bug #新建并切换到fix_bug分支
Switched to a new branch 'fix_bug'
[Lxy@aliyun gitcode]$ vim ReadMe
[Lxy@aliyun gitcode]$ cat ReadMe
hello git
hello world
hello ReadMe
git --version
I am fixing bug ......... #修复bug
[Lxy@aliyun gitcode]$ git add . #重新add commit
[Lxy@aliyun gitcode]$ git commit -m "fix bug"
[fix_bug 76fef0d] fix bug
1 file changed, 1 insertion(+), 7 deletions(-)
修复完毕后，切换到master分支，并完成合并，最后删除fix_bug分支：
[Lxy@aliyun gitcode]$ git merge --no-ff -m "merge fix_bug" fix_bug
Merge made by the 'recursive' strategy.
ReadMe | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
[Lxy@aliyun gitcode]$ cat ReadMe
hello git
hello world
hello ReadMe
git --version
I am fixing bug .........
至此，bug地修复工作已经做完了，我们还要继续回到dev2分支进行开发，切换回dev2分支：
[Lxy@aliyun gitcode]$ git checkout dev2
Switched to branch 'dev2'
[Lxy@aliyun gitcode]$ git status
# On branch dev2
nothing to commit, working directory clean
工作区是干净的？？？刚才我们的工作现场存到哪儿去了？可以使用git stash list命令查看
[Lxy@aliyun gitcode]$ git stash list
stash@{0}: WIP on dev2: 9c17f2d merge dev1
工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，如何恢复现场呢？我们可以使用git stash pop命令，恢复的同时会把stash也删了：
[Lxy@aliyun 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: ReadMe
#
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (c6b7e92f49a38afc1461bcedbaa558aa7ecd0500)
[Lxy@aliyun gitcode]$ cat ReadMe
hello git
hello world
hello ReadMe
I am Codeing in dev2............
再次查看的时候，我们已经发现没有现场可以恢复了
[Lxy@aliyun gitcode]$ git stash list
[Lxy@aliyun gitcode]$
另外，恢复现场也可以采用git stash apply 恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除。你可以多次stash，恢复的时候，先用``git stash list查看，然后恢复指定的stash，用命令git stash apply stash@{0}`恢复完代码之后我们便可以继续完成开发，开发完成后便可以进行提交。例如：
[Lxy@aliyun gitcode]$ cat ReadMe
hello git
hello world
hello ReadMe
I am Codeing in dev2............
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[dev2 477994a] md ReadMe
1 file changed, 1 insertion(+), 9 deletions(-)
但我们注意到了，修复bug的内容，并没有在dev2上显示，此时的状态图为：
master分支目前最新的提交，是要领先于新建dev2时基于的master分支的提交的。所以我们在dev2中当然看不见修复bug的相关代码。我们的最终目的时让master合并dev2分支的，那么正常情况下我们切回master分支直接合并即可，但这样其实是有一定风险的。是因为合并分支时可能会有冲突，而代码冲突需要我们手动解决（在master上解决）我们无法保证对于冲突问题可以正确的一次性解决掉，因为在实习的项目中，代码冲突不只一两行那么简单，有可能几十上百行，甚至更多，解决的过程中难免手误出错，导致错误的代码被合并到master上，此时的状态为：
解决这个问题有一个好的建议是，最好现在自己的分支上合并下master，再让master去合并dev，这样做的目的是有冲突可以再本地分支解决并进行测试，而不影响master
此时的状态为：
对应的实操显示为：（要说明的是，以下演示的merge操作，没有使用--no-ff,但上述的图示是禁用Fast forward了模式后得出的，主要是为了方便解释问题。）
[Lxy@aliyun gitcode]$ git branch #查看当前分支
dev1
* dev2
fix_bug
master
[Lxy@aliyun gitcode]$ git merge master #合并master分支到dev2
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
[Lxy@aliyun gitcode]$ cat ReadMe #查看代码
hello git
hello world
hello ReadMe
<<<<<<< HEAD
I am Codeing in dev2............
=======
git --version
I am fixing bug .........
>>>>>>> master
[Lxy@aliyun gitcode]$ vim ReadMe #修改代码
[Lxy@aliyun gitcode]$ cat ReadMe #再次查看
hello git
hello world
hello ReadMe
I am Codeing in dev2.........
git --version
bug is fixed .........
[Lxy@aliyun gitcode]$ git add . #add 并且 commit
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[dev2 8bdc3c9] md ReadMe
至此dev2上面的代码无需冲突解决，我们再切回master合并dev2即可
[Lxy@aliyun gitcode]$ git checkout master #切换回master
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git merge dev2 #合并dev2
Updating ac63583..8bdc3c9
Fast-forward
ReadMe | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
[Lxy@aliyun gitcode]$ cat ReadMe #查看ReadME代码
hello git
hello world
hello ReadMe
I am Codeing in dev2.........
git --version
bug is fixed .........
[Lxy@aliyun gitcode]$ git branch -d dev2 #删除dev2
Deleted branch dev2 (was 8bdc3c9).
[Lxy@aliyun gitcode]$ git branch -d fix_bug #删除fix_bug
Deleted branch fix_bug (was 76fef0d).
[Lxy@aliyun gitcode]$ git branch -d dev1 #删除dev1
Deleted branch dev1 (was f41d236).
[Lxy@aliyun gitcode]$ git branch
* master
软件开发中，总有⽆穷⽆尽的新的功能要不断添加进来。 添加⼀个新功能时，你肯定不希望因为⼀些实验性质的代码，把主分⽀搞乱了，所以，每添加⼀个新功能，最好新建⼀个分⽀，我们可以将其称之为 feature 分⽀，在上⾯开发，完成后，合并，最 后，删除该feature 分⽀。 可是，如果我们今天正在某个feature 分⽀上开发了⼀半，被产品经理突然叫停，说是要停⽌新功能的开发。虽然⽩⼲了，但是这个feature 分⽀还是必须就地销毁，留着⽆⽤了。这时使⽤传统 的git branch -d命令删除分⽀的⽅法是不⾏的。演⽰如下：
#新建并且切换到dev3分支
[Lxy@aliyun gitcode]$ git checkout -b dev3
M ReadMe
Switched to a new branch 'dev3'
#开始开发新功能并提交
[Lxy@aliyun gitcode]$ vim ReadMe
[Lxy@aliyun gitcode]$ cat ReadMe
hello git
hello world
hello ReadMe
I am Codeing in dev2.........
git --version
bug is fixed .........
hello dev3
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[dev3 00a37ca] md ReadMe
1 file changed, 2 insertions(+)
#此时新功能叫停
#切回master准备删除dev3
[Lxy@aliyun gitcode]$ git checkout master
Switched to branch 'master'
#常规删除dev3分支时失败
[Lxy@aliyun 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'.
直接使用传统的删除分支的方法不行，按照提示，有了如下方式：
[Lxy@aliyun gitcode]$ git branch -D dev3
Deleted branch dev3 (was 00a37ca).
[Lxy@aliyun gitcode]$ git branch
* master
分⽀在实际中有什么⽤呢？假设你准备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50% 的代码，如果⽴刻提交，由于代码还没写完，不完整的代码库会导致别⼈不能⼲活了。如果等代码全 部写完再⼀次提交，⼜存在丢失每天进度的巨⼤⻛险。
现在有了分⽀，就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀，别⼈看不到，还继续在原来的分⽀上 正常⼯作，⽽你在⾃⼰的分⽀上⼲活，想提交就提交，直到开发完毕后，再⼀次性合并到原来的分⽀ 上，这样，既安全，⼜不影响别⼈⼯作。
并且Git⽆论创建、切换和删除分⽀，Git在1秒钟之内就能完成！⽆论你的版本库是1个⽂件还是1万个⽂件。
(本篇完)