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 <[email protected]>
Date: Mon Jun 2613: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]$ gitadd.[Lxy@aliyun gitcode]$ git commit -m"modify ReadMe"[dev 2690f7f] modify ReadMe
1file 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 <[email protected]>1689396001 +0800
committer Lxy <[email protected]>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 ++
1file 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, 1file
此时的状态如下图所示：
因为创建、合并、删除分支非常快，所以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]$ gitadd.#提交修改[Lxy@aliyun gitcode]$ git commit -m"md ReadMe"[dev1 50ba571] md ReadMe
1file 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]$ gitadd.[Lxy@aliyun gitcode]$ git commit -m"md ReadMe"[master a8d6985] md ReadMe
1file 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]$ gitadd.[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 addfile
* 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]$ gitadd.#提交修改[Lxy@aliyun gitcode]$ git commit -m"md ReadMe"[dev1 f41d236] md ReadMe
1file 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 +++
1file 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 <[email protected]>|| Date: Sun Jul 1618:21:49 2023 +0800
|||| merge dev1 #这里能够看到合并的信息||| * commit f41d236
|/ Author: Lxy <[email protected]>| Date: Sun Jul 1618:20:46 2023 +0800
|| md ReadMe
|
* commit 832d4a2
|\ Merge: a8d6985 50ba571
|| Author: Lxy <[email protected]>|| Date: Sat Jul 1513:10:06 2023 +0800
|||| md ReadMe
||| * commit 50ba571
|| Author: Lxy <[email protected]>|| Date: Sat Jul 1512:59:18 2023 +0800
|||| md ReadMe
||
* | commit a8d6985
|/ Author: Lxy <[email protected]>| Date: Sat Jul 1513:05:11 2023 +0800
|| md ReadMe
|
* commit 2690f7f
| Author: Lxy <[email protected]>| Date: Sat Jul 1512: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]$ gitadd.#重新add commit[Lxy@aliyun gitcode]$ git commit -m"fix bug"[fix_bug 76fef0d] fix bug
1file 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 +-------
1file 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]$ gitadd.[Lxy@aliyun gitcode]$ git commit -m"md ReadMe"[dev2 477994a] md ReadMe
1file 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]$ gitadd.#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 +++---
1file 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]$ gitadd.[Lxy@aliyun gitcode]$ git commit -m"md ReadMe"[dev3 00a37ca] md ReadMe
1file 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万个⽂件。
(本篇完)
版权归原作者 小白又菜 所有， 如有侵权，请联系我们删除。