【Git】3. 分支管理【命令大全】

哈茶真的c

已于 2024-08-08 15:08:09 修改

阅读量1.3k

点赞数 48

分类专栏： Git 文章标签： git 开发语言

于 2024-08-07 23:26:31 首次发布

本文链接：https://blog.csdn.net/weixin_60915103/article/details/140867134

版权

Git 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

分⽀管理

理解分⽀

本章开始介绍 Git 的杀⼿级功能之⼀（注意是之⼀，也就是后⾯还有之⼆，之三……）：分⽀。
分⽀就是科幻电影⾥⾯的平⾏宇宙，当你正在电脑前努⼒学习 C++ 的时候，另⼀个你正在另⼀个平⾏宇宙⾥努⼒学习 JAVA。

如果两个平⾏宇宙互不⼲扰，那对现在的你也没啥影响。不过，在某个时间点，两个平⾏宇宙合并了，结果，你既学会了 C++ ⼜学会了 JAVA！
在这里插入图片描述
在版本回退⾥，你已经知道，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀个分⽀。
截⽌到⽬前，只有⼀条时间线，在Git⾥，这个分⽀叫主分⽀，即 master 分⽀。
再来理解⼀下HEAD，HEAD 严格来说不是指向提交，⽽是指向master，master才是指向提交的，所以，HEAD 指向的就是当前分⽀。
在这里插入图片描述
每次提交，master分⽀都会向前移动⼀步，这样，随着你不断提交，master分⽀的线也越来越⻓,⽽HEAD只要⼀直指向master分⽀即可指向当前分⽀。
通过查看当前的版本库，我们也能清晰的理出思路:

hx@LAPTOP-H2EI4I6A:~/code/practice$ cat .git/HEAD 
ref: refs/heads/master
hx@LAPTOP-H2EI4I6A:~/code/practice$ cat .git/refs/heads/master 
9399e34c53f94e562762b9bef364766d20f1f68c

创建分⽀

查看当前本地所有分支 – git branch

新建分支 – git branch XXX

Git ⽀持我们查看或创建其他分⽀，在这⾥我们来创建第⼀个⾃⼰的分⽀ dev ，对应的命令为：

hx@LAPTOP-H2EI4I6A:~/code/practice$ git branch #查看当前本地所有分⽀
* master
hx@LAPTOP-H2EI4I6A:~/code/practice$ git branch hx  #新建分⽀dev
hx@LAPTOP-H2EI4I6A:~/code/practice$ git branch
  hx
* master

当我们创建新的分⽀后，Git 新建了⼀个指针叫 dev， * 表⽰当前 HEAD 指向的分⽀是 master 分⽀。
另外，可以通过⽬录结构发现，新的 hx 分⽀：

hx@LAPTOP-H2EI4I6A:~/code/practice$ ls .git/refs/heads/
hx  master
hx@LAPTOP-H2EI4I6A:~/code/practice$ cat .git/refs/heads/*
9399e34c53f94e562762b9bef364766d20f1f68c
9399e34c53f94e562762b9bef364766d20f1f68c

发现⽬前 hx 和 master 指向同⼀个修改。并且也可以验证下 HEAD ⽬前是指向 master 的。

hx@LAPTOP-H2EI4I6A:~/code/practice$ cat .git/HEAD 
ref: refs/heads/master

⼀张图总结：
在这里插入图片描述
新建分支是在当前的HEAD所指向的分支上再创建出来的，所以此时master和dev指向同一次提交

HEAD也可以指向其他分支，被指向的就是当前正在工作的分支

切换分⽀

那如何切换到 dev 分⽀下进⾏开发呢？使⽤ git checkout 命令即可完成切换，⽰例如下：

切换分支 – git checkout [分支名]

hyb@139-159-150-152:~/gitcode$ git checkout dev
Switched to branch 'dev'
hyb@139-159-150-152:~/gitcode$ git branch
* dev
 master
hyb@139-159-150-152:~/gitcode$ cat .git/HEAD
ref: refs/heads/dev

新建并切换 – git branch -b [分支名]

在这里插入图片描述
我们发现 HEAD 已经指向了 dev，就表⽰我们已经成功的切换到了 dev 上！
接下来，在 dev 分⽀下修改 ReadMe ⽂件，新增⼀⾏内容，并进⾏⼀次提交操作：

hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[dev 3740dce] modify ReadMe
 1 file changed, 1 insertion(+)

现在，dev 分⽀的⼯作完成，我们就可以切换回 master 分⽀：

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3

切换回 master 分⽀后，发现ReadMe⽂件中新增的内容不⻅了！！！赶紧再切回 dev 看看:

hyb@139-159-150-152:~/gitcode$ git checkout dev 
Switched to branch 'dev'
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch

在 dev 分⽀上，内容还在。为什么会出现这个现象呢？
我们来看看 dev 分⽀和 master 分⽀指向，发现两者指向的提交是不⼀样的：

hyb@139-159-150-152:~/gitcode$ cat .git/refs/heads/dev
bdaf528ffbb8e05aee34d37685408f0e315e31a4
hyb@139-159-150-152:~/gitcode$ cat .git/refs/heads/master 
5476bdeb12510f7cd72ac4766db7988925ebd302

看到这⾥就能明⽩了，因为我们是在dev分⽀上提交的，⽽master分⽀此刻的提交点并没有变，此时的状态如图如下所⽰。
在这里插入图片描述
当切换到 master 分⽀之时，HEAD 就指向了 master，当然看不到提交了！

合并分⽀

为了在 master 主分⽀上能看到新的提交，就需要将 dev 分⽀合并到 master 分⽀，⽰例如下：

合并指定分⽀到当前分⽀ – git merge [分支名]

hyb@139-159-150-152:~/gitcode$ git branch 
* dev
 master
hyb@139-159-150-152:~/gitcode$ git checkout master # 切换到 master 上进⾏合并
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git merge dev # 合并 dev 分⽀
Updating 16623e1..3740dce
Fast-forward
 ReadMe | 1 +
 1 file changed, 1 insertion(+)
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch

git merge 命令⽤于合并指定分⽀到当前分⽀。合并后，master 就能看到 dev 分⽀提交的内容了。
此时的状态如图如下所⽰：
在这里插入图片描述
Fast-forward 代表“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度⾮常快。
当然，也不是每次合并都能 Fast-forward，我们后⾯会讲其他⽅式的合并。

删除分⽀

合并完成后, dev 分⽀对于我们来说就没⽤了，那么dev分⽀就可以被删除掉，注意如果当前正处于某分⽀下，就不能删除当前分⽀，如：

删除分支 – git branch -d [分支名]

hyb@139-159-150-152:~/gitcode$ git branch
* dev
 master
hyb@139-159-150-152:~/gitcode$ git branch -d dev
error: Cannot delete branch 'dev' checked out at '/home/hyb/gitcode'

⽽可以在其他分⽀下删除当前分⽀，如：

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git branch -d dev 
Deleted branch dev (was bdaf528).
hyb@139-159-150-152:~/gitcode$ git branch
* master

此时的状态如图如下所⽰
在这里插入图片描述
因为创建、合并和删除分⽀⾮常快，所以Git⿎励你使⽤分⽀完成某个任务，合并后再删掉分⽀，这和直接在master分⽀上⼯作效果是⼀样的，但过程更安全。

合并冲突

可是，在实际分⽀合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。
为了演⽰这问题，创建⼀个新的分⽀ dev1 ，并切换⾄⽬标分⽀，我们可以使⽤ git checkout -b dev1 ⼀步完成创建并切换的动作，⽰例如下：

hyb@139-159-150-152:~/gitcode$ git checkout -b dev1
Switched to a new branch 'dev1'
hyb@139-159-150-152:~/gitcode$ git branch
* dev1
 master

在 dev1 分⽀下修改 ReadMe ⽂件，更改⽂件内容如下，并进⾏⼀次提交，如：

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch # 将 aaa 该为 bbb
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[dev1 0854245] modify ReadMe
 1 file changed, 1 insertion(+), 1 deletion(-)

切换⾄ master 分⽀，观察 ReadMe ⽂件内容:

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch

我们发现，切回来之后，⽂件内容由变成了⽼的版本，这种现象很正常，我们现在也完全能理解。
此时在 master 分⽀上，我们对 ReadMe ⽂件再进⾏⼀次修改，并进⾏提交，如下：

hyb@139-159-150-152:~/gitcode$ git branch 
 dev1
* master
hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write ccc for new branch 
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[master c10f6d0] modify ReadMe
 1 file changed, 1 insertion(+), 1 deletion(-)

现在， master 分⽀和 dev1 分⽀各⾃都分别有新的提交，变成了这样：
在这里插入图片描述
这种情况下，Git 只能试图把各⾃的修改合并起来，但这种合并就可能会有冲突，如下所⽰：

hyb@139-159-150-152:~/gitcode$ git merge dev1 
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
hyb@139-159-150-152:~/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")

发现 ReadMe ⽂件有冲突后，可以直接查看⽂件内容，要说的是 Git 会⽤<<<<<<<，=======，>>>>>>>
来标记出不同分⽀的冲突内容，如下所⽰：

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
<<<<<<< HEAD
write ccc for new branch 
=======
write bbb for new branch 
>>>>>>> dev1

此时我们必须要⼿动调整冲突代码(必须手动调整，正常开发场景中不同分支的代码merge合并不可能忽略冲突，以某个分支为准，要做出调整)，并需要再次提交修正后的结果！！（再次提交很重要，切勿忘记）

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch 
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"merge ReadMe"
[master 2976afc] merge ReadMe

到这⾥冲突就解决完成，此时的状态变成了

在这里插入图片描述
⽤带参数的 git log也可以看到分⽀的合并情况，具体⼤家可以⾃⾏搜索 git log 的⽤法:

树状git – git log --graph --pretty=oneline --abbrev-commit

hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit
* 2976afc (HEAD -> master) merge ReadMe
|\ 
| * c594fd1 (dev1) modify ReadMe
* | c10f6d0 modify ReadMe
|/

最后，不要忘记 dev1 分⽀使⽤完毕后就可以删除了：

hyb@139-159-150-152:~/gitcode$ git branch 
* master
hyb@139-159-150-152:~/gitcode$ git branch -d dev1 
Deleted branch dev1 (was c594fd1).

分⽀管理策略

Fast forward 模式

通常合并分⽀时，如果可能，Git 会采⽤ Fast forward 模式。
还记得如果我们采⽤ Fast forward 模式之后，形成的合并结果是什么呢？回顾⼀下
在这里插入图片描述
在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是 merge 进来的还是正常提交的。

no - ff 模式

但在合并冲突部分，我们也看到通过解决冲突问题，会再进⾏⼀次新的提交，得到的最终状态为：
在这里插入图片描述
那么这就不是 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 ，并切换⾄新的分⽀:

hyb@139-159-150-152:~/gitcode$ git checkout -b dev2
Switched to a new branch 'dev2'

修改 ReadMe ⽂件，并提交⼀个新的 commit :

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[dev2 41b082f] modify ReadMe
 1 file changed, 1 insertion(+)

切回 master 分⽀，开始合并:

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git merge --no-ff -m "merge with no-ff" dev2
Merge made by the 'recursive' strategy.
 ReadMe | 1 +
 1 file changed, 1 insertion(+)
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d

请注意 --no-ff 参数，表⽰禁⽤ Fast forward 模式。
禁⽤ Fast forward 模式后合并会创建⼀个新的 commit ，所以加上 -m 参数，把描述写进去。
合并后，查看分⽀历史：

hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit
* 5bd16b4 (HEAD -> master) merge with no-ff
|\ 
| * 41b082f (dev2) modify ReadMe
|/

可以看到，不使⽤ Fast forward 模式，merge后就像这样：
在这里插入图片描述
所以在合并分⽀时，加上 --no-ff 参数就可以⽤普通模式合并，合并后的历史有分⽀，能看出来曾经做过合并，⽽ fast forward 合并就看不出来曾经做过合并。

分⽀策略

在实际开发中，我们应该按照⼏个基本原则进⾏分⽀管理：
⾸先，master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平时不能在上⾯⼲活；
那在哪⼲活呢？⼲活都在dev分⽀上，也就是说，dev分⽀是不稳定的，到某个时候，⽐如1.0版本发布时，再把dev分⽀合并到master上，在master分⽀发布1.0版本；
你和你的⼩伙伴们每个⼈都在dev分⽀上⼲活，每个⼈都有⾃⼰的分⽀，时不时地往dev分⽀上合并就可以了。
所以，团队合作的分⽀看起来就像这样：
在这里插入图片描述

bug 分⽀

假如我们现在正在 dev2 分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有 bug，需要解决。
在Git中，每个 bug 都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分⽀删除。
可现在 dev2 的代码在⼯作区中开发了⼀半，还⽆法提交，怎么办？例如：

hyb@139-159-150-152:~/gitcode$ git branch 
* dev2
 master
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d
i am coding ...
hyb@139-159-150-152:~/gitcode$ git status
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")

将工作区信息存储 – git stash

Git 提供了 git stash 命令，可以将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来。

hyb@139-159-150-152:~/gitcode$ git stash
Saved working directory and index state WIP on dev2: 41b082f modify ReadMe
hyb@139-159-150-152:~/gitcode$ git status
On branch dev2
nothing to commit, working tree clean

⽤ git status 查看⼯作区，就是⼲净的（除⾮有没有被 Git 管理的⽂件），因此可以放⼼地创建分⽀来修复bug。

储藏 dev2 ⼯作区之后，由于我们要基于master分⽀修复 bug，所以需要切回 master 分⽀，再新建临时分⽀来修复 bug，⽰例如下：

hyb@139-159-150-152:~/gitcode$ git checkout master # 切回master
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git checkout -b fix_bug # 新建并切换到 fix_bug 分⽀
Switched to a new branch 'fix_bug'
hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e # 修复bug--忘记写e
hyb@139-159-150-152:~/gitcode$ git add ReadMe # 重新add，commit
hyb@139-159-150-152:~/gitcode$ git commit -m"fix bug"
[fix_bug 4bbc0c4] fix bug
 1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后，切换到 master 分⽀，并完成合并，最后删除 fix_bug 分⽀：

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git merge --no-ff -m"merge fix_bug branch" fix_bu
Merge made by the 'recursive' strategy.
 ReadMe | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e
hyb@139-159-150-152:~/gitcode$ git branch -d fix_bug 
Deleted branch fix_bug (was 4bbc0c4).

⾄此，bug 的修复⼯作已经做完了，我们还要继续回到 dev2 分⽀进⾏开发。切换回 dev2 分⽀：

hyb@139-159-150-152:~/gitcode$ git checkout dev2 
Switched to branch 'dev2'
hyb@139-159-150-152:~/gitcode$ git status
On branch dev2
nothing to commit, working tree clean

⼯作区是⼲净的，刚才的⼯作现场存到哪去了？⽤ git stash list 命令看看：

查看存储的工作区信息 – git stash list

hyb@139-159-150-152:~/gitcode$ git stash list
stash@{0}: WIP on dev2: 41b082f modify ReadMe

⼯作现场还在，Git 把 stash 内容存在某个地⽅了，但是需要恢复⼀下，如何恢复现场呢？我们可以使⽤ git stash pop 命令，恢复的同时会把 stash 也删了，⽰例如下：

恢复存储工作区1 – git stash pop

hyb@139-159-150-152:~/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} (4f873250b3503687b5efd26196776aee7e3724c2)

再次查看的时候，我们已经发现已经没有现场可以恢复了

hyb@139-159-150-152:~/gitcode$ git stash list
hyb@139-159-150-152:~/gitcode$

恢复存储工作区2 – git stash apply

另外，恢复现场也可以采⽤ git stash apply 恢复，但是恢复后，stash内容并不删除，你需要⽤ git stash drop 来删除；

删除存储工作区 – git stash drop

你可以多次stash，恢复的时候，先⽤ git stash list 查看，然后恢复指定的stash，⽤命令git stash apply stash@{0}
恢复完代码之后我们便可以继续完成开发，开发完成后便可以进⾏提交，例如：

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d
i am coding ... Done!
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[dev2 ed0916d] modify ReadMe
 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
hyb@139-159-150-152:~/gitcode$ git branch 
* dev2
 master
hyb@139-159-150-152:~/gitcode$ git merge master 
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
# 发⽣冲突
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
<<<<<<< HEAD
a,b,c,d
i am coding ... Done!
=======
a,b,c,d,e
>>>>>>> master
# 解决冲突并重新提交
hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e
i am coding ... Done!
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"merge master"
[dev2 447d29f] merge master
hyb@139-159-150-152:~/gitcode$ git status
On branch dev2
nothing to commit, working tree clean
# 切回master
hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
# master 合并 dev2---⽆需解决冲突！！
hyb@139-159-150-152:~/gitcode$ git merge dev2 
Updating 193421f..447d29f
Fast-forward
 ReadMe | 1 +
 1 file changed, 1 insertion(+)
 hyb@139-159-150-152:~/gitcode$ git status
On branch master
nothing to commit, working tree clean
# 删除 dev2 分⽀
hyb@139-159-150-152:~/gitcode$ git branch -d dev2 
Deleted branch dev2 (was 447d29f).

删除临时分⽀

软件开发中，总有⽆穷⽆尽的新的功能要不断添加进来。
添加⼀个新功能时，你肯定不希望因为⼀些实验性质的代码，把主分⽀搞乱了，所以，每添加⼀个新功能，最好新建⼀个分⽀，我们可以将其称之为 feature 分⽀，在上⾯开发，完成后，合并，最后，删除该 feature 分⽀。
可是，如果我们今天正在某个 feature 分⽀上开发了⼀半，被产品经理突然叫停，说是要停⽌新功能的开发。虽然⽩⼲了，但是这个 feature 分⽀还是必须就地销毁，留着⽆⽤了。这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的。演⽰如下：

# 新增并切换到 dev3 分⽀
hyb@139-159-150-152:~/gitcode$ git checkout -b dev3
Switched to a new branch 'dev3'
# 开始开发新功能并提交
hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e
i am coding ... Done!
i am writing new features ...
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe for new features"
[dev3 cd2f149] modify ReadMe for new features
 1 file changed, 1 insertion(+)
# 此时新功能叫停
# 切回master准备删除dev3
hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
# 常规删除dev3分⽀时失败
hyb@139-159-150-152:~/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'.

直接使⽤传统的删除分⽀的⽅法不⾏，按照提⽰，有了如下⽅式:

强制删除分支 git branch -D [分支名]

hyb@139-159-150-152:~/gitcode$ git branch -D dev3 
Deleted branch dev3 (was cd2f149).
hyb@139-159-150-152:~/gitcode$ git branch 
* master

done!

⼩结

分⽀在实际中有什么⽤呢？
假设你准备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50%的代码，如果⽴刻提交，由于代码还没写完，不完整的代码库会导致别⼈不能⼲活了。如果等代码全部写完再⼀次提交，⼜存在丢失每天进度的巨⼤⻛险。

现在有了分⽀，就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀，别⼈看不到，还继续在原来的分⽀上正常⼯作，⽽你在⾃⼰的分⽀上⼲活，想提交就提交，直到开发完毕后，再⼀次性合并到原来的分⽀上，这样，既安全，⼜不影响别⼈⼯作。

并且 Git ⽆论创建、切换和删除分⽀，Git在1秒钟之内就能完成！⽆论你的版本库是1个⽂件还是1万个⽂件。