【Git】分支

理解分支

本章开始介绍 Git 的杀手级功能之一（注意是之一，也就是后面还有之二，之三……）：分支。分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习 C++ 的时候，另一个你正在另一个平行宇宙里努力学习 JAVA。
如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了 C++ 又学会了 JAVA！

在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就可以理解为是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即 master 分支。
再来理解一下HEAD，HEAD 严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD 指向的就是当前分支。

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长，而HEAD只要一直指向master分支即可指向当前分支。

通过查看当前的版本库，我们也能清晰的理出思路:

[root@MyComputer:gitcode]# cat .git/HEAD
ref: refs/heads/master
[root@MyComputer:gitcode]# cat .git/refs/heads/master
d68ea84a1142d3d517478ff5715b428a5d32657d

创建分支

Git 支持我们查看或创建其他分支，在这里我们来创建第一个自己的分支 dev ，对应的命令为：

[root@MyComputer:gitcode]# git branch   # 查看当前本地所有分⽀
* master
[root@MyComputer:gitcode]# git branch dev  # 新建分⽀dev
[root@MyComputer:gitcode]# git branchdev
* master

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

[root@MyComputer:gitcode]# ls .git/refs/heads/
dev  master
[root@MyComputer:gitcode]# cat .git/refs/heads/*
d68ea84a1142d3d517478ff5715b428a5d32657d
d68ea84a1142d3d517478ff5715b428a5d32657d

发现目前 dev 和 master 指向同一个修改。并且也可以验证下 HEAD 目前是指向 master 的。

[root@MyComputer:gitcode]# cat .git/HEAD
ref: refs/heads/master

一张图总结：

切换分支

那如何切换到 dev 分支下进行开发呢？使用 git checkout 命令即可完成切换，示例如下：

[root@MyComputer:gitcode]# git branchdev
* master
[root@MyComputer:gitcode]# git checkout dev
Switched to branch 'dev'
[root@MyComputer:gitcode]# git branch
* devmaster
[root@MyComputer:gitcode]# cat .git/HEAD
ref: refs/heads/dev

我们发现 HEAD 已经指向了 dev，就表示我们已经成功的切换到了 dev 上！
接下来，在 dev 分支下修改 ReadMe 文件，新增一行内容，并进行一次提交操作：

[root@MyComputer:gitcode]# vim ReadMe
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev
[root@MyComputer:gitcode]# git add ReadMe
[root@MyComputer:gitcode]# git commit -m "modify ReadMe add dev"
[dev f36c45f] modify ReadMe add dev1 file changed, 1 insertion(+)

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

[root@MyComputer:gitcode]# git checkout master
Switched to branch 'master'
[root@MyComputer:gitcode]# cat .git/HEAD
ref: refs/heads/master
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3

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

[root@MyComputer:gitcode]# git checkout dev
Switched to branch 'dev'
[root@MyComputer:gitcode]# cat .git/HEAD
ref: refs/heads/dev
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev

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

[root@MyComputer:gitcode]# cat .git/refs/heads/dev
f36c45f7e5d5cd32453976357dda2e4a8d2067de
[root@MyComputer:gitcode]# cat .git/refs/heads/master
d68ea84a1142d3d517478ff5715b428a5d32657d
[root@MyComputer:gitcode]# git log --pretty=oneline
f36c45f7e5d5cd32453976357dda2e4a8d2067de (HEAD -> dev) modify ReadMe add dev
d68ea84a1142d3d517478ff5715b428a5d32657d (master) add version3

看到这里就能明白了，因为我们是在dev分支上提交的，而master分支此刻的提交点并没有变，此时的状态如图如下所示。

当切换到 master 分支之时，HEAD 就指向了 master，当然看不到提交了！

合并分支

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

[root@MyComputer:gitcode]# git branch
* devmaster
[root@MyComputer:gitcode]# git checkout master  # 必须要切换到 master 上进行合并
Switched to branch 'master'
[root@MyComputer:gitcode]# git merge dev    # 合并 dev 分支
Updating d68ea84..f36c45f
Fast-forward   # 代表“快进模式”ReadMe | 1 +1 file changed, 1 insertion(+)
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev

git merge 命令用于合并指定分支到当前分支。合并后，master 就能看到 dev 分支提交的内容了。此时的状态如图如下所示。

Fast-forward 代表“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
当然，也不是每次合并都能 Fast-forward，我们后面会讲其他方式的合并。

删除分支

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

[root@MyComputer:gitcode]# git branch
* devmaster
[root@MyComputer:gitcode]# git branch -d dev  # 删除分支的选项（等同于 --delete）
error: Cannot delete branch 'dev' checked out at '/root/gitcode'

而可以在其他分支下删除当前分支，如：

[root@MyComputer:gitcode]# git checkout master
Switched to branch 'master'
[root@MyComputer:gitcode]# git branch -d dev
Deleted branch dev (was f36c45f).
[root@MyComputer:gitcode]# git branch
* master

此时的状态如图如下所示。

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

合并冲突

可是，在实际分支合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。
为了演示这问题，创建一个新的分支 dev1 ，并切换至目标分支，我们可以使用 git checkout -b dev1 一步完成创建并切换的动作，-b：它是 --branch 的简写形式，其功能是在切换分支之前先创建新分支，示例如下：

[root@MyComputer:gitcode]# git branch
* master
[root@MyComputer:gitcode]# git checkout -b dev1
Switched to a new branch 'dev1'
[root@MyComputer:gitcode]# git branch
* dev1master

在 dev1 分支下修改 ReadMe 文件，更改文件内容如下，并进行一次提交，如：

[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev
[root@MyComputer:gitcode]# vim ReadMe
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev aaa
[root@MyComputer:gitcode]# git add .
[root@MyComputer:gitcode]# git commit -m "modify add aaa"
[dev1 4935122] modify add aaa1 file changed, 1 insertion(+), 1 deletion(-)

切换至 master 分支，观察 ReadMe 文件内容:

[root@MyComputer:gitcode]# git branchdev1
* master
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev

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

[root@MyComputer:gitcode]# vim ReadMe
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
[root@MyComputer:gitcode]# git add .
[root@MyComputer:gitcode]# git commit -m "modify add bbb"
[master 0e50368] modify add bbb1 file changed, 1 insertion(+), 1 deletion(-)

现在， master 分支和 dev1 分支各自都分别有新的提交，变成了这样：

这种情况下，Git 只能试图把各自的修改合并起来，但这种合并就可能会有冲突，如下所示：

[root@MyComputer:gitcode]# git branchdev1
* master
[root@MyComputer:gitcode]# git merge dev1
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
[root@MyComputer: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:   ReadMeno changes added to commit (use "git add" and/or "git commit -a")

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

  1 Hello lwz2 Hello lwz3 Hello world!!!!4 Hello Git5 Hello version16 Hello version27 Hello version38 <<<<<<< HEAD                                                                                                                                                             9 Hello dev bbb10 =======11 Hello dev aaa12 >>>>>>> dev1                   

此时我们必须要手动调整冲突代码，并需要再次提交修正后的结果！！（再次提交很重要，切勿忘记）

[root@MyComputer:gitcode]# vim ReadMe
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
[root@MyComputer:gitcode]# git add .
[root@MyComputer:gitcode]# git commit -m "fix over"
[master 2fa65b5] fix over

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

用带参数的 git log也可以看到分支的合并情况，git log --graph --pretty=oneline --abbrev-commit下面是各部分参数的具体解释：

1. git log：基础命令，用于显示提交历史记录。
2. --graph：
- 功能：以 ASCII 图形方式展示分支合并历史，用竖线和斜杠表示提交之间的关系。
- 效果：让分支结构更加直观，便于理解提交的分叉和合并点。
3. --pretty=oneline：
- 功能：将每个提交压缩为一行显示，默认格式为 提交哈希 提交信息。
- 替代参数：--pretty=format:"%h %ad | %s%d [%an]"：自定义格式（如哈希、日期、提交信息等）。--oneline：--pretty=oneline --abbrev-commit 的简写。4. --abbrev-commit：- 功能：将提交哈希值缩写为最短唯一长度（通常 7 位字符），提高可读性。- 注意：若不指定该参数，--pretty=oneline 会显示完整的 40 位哈希值。

[root@MyComputer:gitcode]# git log --graph --pretty=oneline --abbrev-commit
*   2fa65b5 (HEAD -> master) fix over
|\  
| * 4935122 (dev1) modify add aaa
* | 0e50368 modify add bbb
|/  

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

[root@MyComputer:gitcode]# git branchdev1
* master
[root@MyComputer:gitcode]# git branch -d dev1
Deleted branch dev1 (was 4935122).
[root@MyComputer:gitcode]# git branch
* master

分支管理策略

通常合并分支时，如果可能，Git 会采用 Fast forward 模式。还记得如果我们采用 Fast forward 模式之后，形成的合并结果是什么呢？回顾一下

在这种 Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是 merge 进来的还是正常提交的。

但在合并冲突部分，我们也看到通过解决冲突问题，会再进行一次新的提交，得到的最终状态为：

那么这就不是 Fast forward 模式了，这样的好处是，从分支历史上就可以看出分支信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分支，但依旧能看到 master 其实是由其他分支合并得到：

[root@MyComputer:gitcode]# git log --graph --pretty=oneline --abbrev-commit
*   2fa65b5 (HEAD -> master) fix over
|\  
| * 4935122 modify add aaa
* | 0e50368 modify add bbb
|/  

Git 支持我们强制禁用 Fast forward 模式，那么就会在 merge 时生成一个新的 commit ，这样，从分支历史上就可以看出分支信息。
下面我们实战一下 --no-ff 方式的 git merge 。首先，创建新的分支 dev2 ，并切换至新的分支:

[root@MyComputer:gitcode]# git checkout -b dev2
Switched to a new branch 'dev2'
[root@MyComputer:gitcode]# git branch
* dev2master

修改 ReadMe 文件，并提交一个新的 commit :

[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
[root@MyComputer:gitcode]# vim ReadMe
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
TTTTTTTTTTTTTTTT
[root@MyComputer:gitcode]# git add .
[root@MyComputer:gitcode]# git commit -m "add TTTTTT"
[dev2 a3198a4] add TTTTTT1 file changed, 1 insertion(+)

切回 master 分支，开始合并:

[root@MyComputer:gitcode]# git branchdev2
* master
[root@MyComputer:gitcode]# git merge --no-ff -m "merge with no-ff" dev2
Merge made by the 'ort' strategy. # 提示合并已完成，使用了'ort'合并策略（ORT是Git 2.33+的默认策略）
# 显示合并修改的文件：ReadMe文件被修改
# "1 +"表示该文件新增了1行内容ReadMe | 1 +
# 合并统计：1个文件被修改，新增了1行内容1 file changed, 1 insertion(+)[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
TTTTTTTTTTTTTTTT

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

*   134ea9a (HEAD -> master) merge with no-ff
|\  
| * a3198a4 (dev2) add TTTTTT
|/  

可以看到，不使用 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 的代码在工作区中开发了一半，还无法提交，怎么办？例如：

[root@MyComputer:gitcode]# git branchdev2
* master
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
TTTTTTTTTTTTTTTT
[root@MyComputer:gitcode]# git checkout dev2
Switched to branch 'dev2'
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
TTTTTTTTTTTTTTTT
[root@MyComputer:gitcode]# vim ReadMe
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
TTTTTTTTTTTTTTTT
i am coding...
[root@MyComputer:gitcode]# git checkout master
M       ReadMe
Switched to branch 'master'
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
TTTTTTTTTTTTTTTT
i am coding...
[root@MyComputer:gitcode]# git status
On branch master
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:   ReadMeno changes added to commit (use "git add" and/or "git commit -a")

我们惊奇的发现dev2分支中的代码跑到master分支去了，但是我们还是提交的状态下，虽然只是在工作区修改了，没有对本地仓库有影响，但是我们还是不想让他出现在master分支上，怎么办呢？
要切回当前开发的分支上，Git 提供了 git stash 命令，可以将当前的工作区信息进行储藏，被储藏的内容可以在将来某个时间恢复出来。

[root@MyComputer:gitcode]# git checkout dev2
M       ReadMe
Switched to branch 'dev2'
[root@MyComputer:gitcode]# git stash
Saved working directory and index state WIP on dev2: a3198a4 add TTTTTT
[root@MyComputer:gitcode]# git status
On branch dev2
nothing to commit, working tree clean

用git status 查看工作区，就是干净的（除非有没有被 Git 管理的文件），因此可以放心地创建分支来修复bug。

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

[root@MyComputer:gitcode]# git branchdev2
* master
[root@MyComputer:gitcode]# git checkout -b fix_bug  # 新建并切换到 fix_bug 分支
Switched to a new branch 'fix_bug'
[root@MyComputer:gitcode]# vim ReadMe
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
TTTTTTTTTTTTTTTTYYY   # 修复bug--忘记写YYY了
[root@MyComputer:gitcode]# git add .  # 重新add，commit
[root@MyComputer:gitcode]# git commit -m "fix YYY"
[fix_bug dcc0212] fix YYY1 file changed, 1 insertion(+), 1 deletion(-)

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

[root@MyComputer:gitcode]# git checkout master
Switched to branch 'master'
[root@MyComputer:gitcode]# git merge --no-ff -m "merge fix_bug YYY" fix_bug
Merge made by the 'ort' strategy.ReadMe | 2 +-1 file changed, 1 insertion(+), 1 deletion(-)
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
TTTTTTTTTTTTTTTTYYY
[root@MyComputer:gitcode]# git branch -d fix_bug
Deleted branch fix_bug (was dcc0212).

至此，bug 的修复工作已经做完了，我们还要继续回到 dev2 分支进行开发。切换回 dev2 分支：

[root@MyComputer:gitcode]# git checkout dev2
Switched to branch 'dev2'
[root@MyComputer:gitcode]# git status
On branch dev2
nothing to commit, working tree clean

工作区是干净的，刚才的工作现场存到哪去了？用git stash list 命令看看：

[root@MyComputer:gitcode]# git stash list
stash@{0}: WIP on dev2: a3198a4 add TTTTTT

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

[root@MyComputer: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:   ReadMeno changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (99f3d6b036650df55ff0fdd8b93f2847e5ae2315)

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

[root@MyComputer:gitcode]# git stash list
[root@MyComputer:gitcode]# 

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

你可以多次stash，恢复的时候，先用 git stash list 查看（1. 查看 stash 列表：显示当前仓库中所有 stash 的记录，包括 stash 的名称、创建时间、关联的分支以及简短描述。2. stash 命名规则：默认格式为 stash@{n}，其中 n 是一个数字，表示 stash 的顺序（例如 stash@{0} 是最近创建的 stash）。），然后恢复指定的stash，用命令git stash apply stash@{0} ,这部分请自行使用哦。

恢复完代码之后我们便可以继续完成开发，开发完成后便可以进行提交，例如：

[root@MyComputer:gitcode]# vim ReadMe
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
TTTTTTTTTTTTTTTT
i am coding...  Done!!!!!
[root@MyComputer:gitcode]# git add .
[root@MyComputer:gitcode]# git commit -m "coding Done!!"
git commit -m "coding Donegit add ."
[dev2 91503fd] coding Donegit add .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
[root@MyComputer:gitcode]# git branch
* dev2master
[root@MyComputer:gitcode]# git merge master
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.# 发生冲突
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
<<<<<<< HEAD
TTTTTTTTTTTTTTTT
i am coding...  Done!!!!!
=======
TTTTTTTTTTTTTTTTYYY
>>>>>>> master
# 解决冲突并重新提交
[root@MyComputer:gitcode]# vim ReadMe
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
TTTTTTTTTTTTTTTTYYY
i am coding...  Done!!!!!
[root@MyComputer:gitcode]# git add .
[root@MyComputer:gitcode]# git commit -m "merge master"
[dev2 b7350df] merge master
[root@MyComputer:gitcode]# git status
On branch dev2
nothing to commit, working tree clean# 切回master
[root@MyComputer:gitcode]# git checkout master
Switched to branch 'master'# master 合并 dev2---无需解决冲突问题！！
[root@MyComputer:gitcode]# git merge dev2
Updating c275380..b7350df
Fast-forwardReadMe | 1 +1 file changed, 1 insertion(+)
[root@MyComputer:gitcode]# git status
On branch master
nothing to commit, working tree clean# 删除dev2分支
[root@MyComputer:gitcode]# git branch -d dev2
Deleted branch dev2 (was b7350df).

删除临时分支

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

演示如下：

# 新增并切换到dev3分支
[root@MyComputer:gitcode]# git branch
* master
[root@MyComputer:gitcode]# git checkout -b dev3
Switched to a new branch 'dev3'# 开始开发新功能并提交
[root@MyComputer:gitcode]# vim ReadMe
[root@MyComputer:gitcode]# cat ReadMe
Hello lwz
Hello lwz
Hello world!!!!
Hello Git
Hello version1
Hello version2
Hello version3
Hello dev bbb
TTTTTTTTTTTTTTTTYYY
i am coding...  Done!!!!!long  long  long
[root@MyComputer:gitcode]# git add .
[root@MyComputer:gitcode]# git commit -m "add long"
[dev3 41fbfec] add long1 file changed, 2 insertions(+)# 此时新功能叫停# 切回master准备删除dev3
[root@MyComputer:gitcode]# git checkout master
Switched to branch 'master'# 常规删除dev3分支失败
[root@MyComputer: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'.

直接使用传统的删除分支的方法不行，按照提示，有了如下方式:

[root@MyComputer:gitcode]# git branch -D dev3
Deleted branch dev3 (was 41fbfec).
[root@MyComputer:gitcode]# git branch
* master

done!

小结

分支在实际中有什么用呢？
假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
并且 Git 无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个无件还是1万个文件。