git 工具使用--分支管理

git 工具使用–分支管理

理解分支

分支管理是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分支上合并就可以了。所以团队合作的分支看起来就像这样：

bug分支

假如我们现在正在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万个⽂件。

(本篇完)