Git--分支的原理与使用

一、理解分支

  开始介绍Git的杀⼿级功能之⼀（注意是之⼀，也就是后⾯还有之⼆，之三……）：分⽀。分⽀就是科幻电影⾥⾯的平⾏宇宙，当你正在电脑前努⼒学习C++的时候，另⼀个你正在另⼀个平⾏宇宙⾥努⼒学习JAVA。
  如果两个平⾏宇宙互不⼲扰，那对现在的你也没啥影响。不过，在某个时间点，两个平⾏宇宙合并了，结果，你既学会了C++⼜学会了JAVA！

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

  每次提交，master分⽀都会向前移动⼀步，这样，随着你不断提交，master分⽀的线也越来越⻓,⽽HEAD只要⼀直指向master分⽀即可指向当前分⽀。

[zl@VM-16-2-centos lesson]$ cat .git/HEAD
ref: refs/heads/master

[zl@VM-16-2-centos lesson]$ cat .git/refs/heads/master
b879e4f12400129cedabecb18f4f15238558f539

二、创建、切换、合并分支

2.1 创建分支

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

[zl@VM-16-2-centos lesson]$ git branch
* master
[zl@VM-16-2-centos lesson]$ git branch dev
[zl@VM-16-2-centos lesson]$ git branch
  dev
* master

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

[zl@VM-16-2-centos lesson]$ cat .git/refs/heads/master
b879e4f12400129cedabecb18f4f15238558f539
[zl@VM-16-2-centos lesson]$ cat .git/refs/heads/dev
b879e4f12400129cedabecb18f4f15238558f539

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

2.2 切换分支

git checkout – （撤销工作区内容）
git checkout 切换分支

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

[zl@VM-16-2-centos lesson]$ git checkout dev
Switched to branch 'dev'
[zl@VM-16-2-centos lesson]$ git branch
* dev
  master
[zl@VM-16-2-centos lesson]$ cat .git/HEAD
ref: refs/heads/dev

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

[zl@VM-16-2-centos lesson]$ ls
file1  file2  file3  readme
[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ git add readme
[zl@VM-16-2-centos lesson]$ git commit -m "me readme"
[dev f679d41] me readme
 1 file changed, 2 insertions(+)
[zl@VM-16-2-centos lesson]$ cat readme
hello world
aaa  on dev branch

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

[zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'
[zl@VM-16-2-centos lesson]$ git branch
  dev
* master
[zl@VM-16-2-centos lesson]$ ls
file1  file2  file3  readme
[zl@VM-16-2-centos lesson]$ cat readme
hello world

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

[zl@VM-16-2-centos lesson]$ git checkout dev
Switched to branch 'dev'
[zl@VM-16-2-centos lesson]$ cat readme
hello world
aaa  on dev branch

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

[zl@VM-16-2-centos lesson]$ cat .git/refs/heads/dev
f679d4133a8bd022b86f65de3c311db3f9c3745b

[zl@VM-16-2-centos lesson]$ cat .git/refs/heads/master
b879e4f12400129cedabecb18f4f15238558f539

[zl@VM-16-2-centos lesson]$ git cat-file -p f679d4133a8bd022b86f65de3c311db3f9c3745b
tree b7b88491390cec3c832a0998e6d71a47429488ce
parent b879e4f12400129cedabecb18f4f15238558f539
author sushangzl <939712250@qq.com> 1713668297 +0800
committer sushangzl <939712250@qq.com> 1713668297 +0800

me readme

  看到这⾥就能明⽩了，因为我们是在dev分⽀上提交的，⽽master分⽀此刻的提交点并没有变，此时的状态如图如下所⽰。

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

2.3 合并分支

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

[zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'
[zl@VM-16-2-centos lesson]$ git merge dev
Updating b879e4f..f679d41
Fast-forward
 readme | 2 ++
 1 file changed, 2 insertions(+)
[zl@VM-16-2-centos lesson]$ cat readme
hello world
aaa  on dev branch

[zl@VM-16-2-centos lesson]$ cat .git/refs/heads/master
f679d4133a8bd022b86f65de3c311db3f9c3745b

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

  Fast-forward代表“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度⾮常快。当然，也不是每次合并都能Fast-forward。

三、删除分支

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

[zl@VM-16-2-centos lesson]$ git checkout master
Already on 'master'
[zl@VM-16-2-centos lesson]$ git branch -d dev
Deleted branch dev (was f679d41).

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

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

四、合并冲突

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

[zl@VM-16-2-centos lesson]$ git checkout -b dev1
Switched to a new branch 'dev1'
[zl@VM-16-2-centos lesson]$ git branch
* dev1
  master

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

[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ ls
file1  file2  file3  readme
[zl@VM-16-2-centos lesson]$ git add .
[zl@VM-16-2-centos lesson]$ git status
# On branch dev1
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   readme
#
[zl@VM-16-2-centos lesson]$ git commit -m "md readme: bbb"
[dev1 3dc0539] md readme: bbb
 1 files changed, 1 insertion(+), 1 deletion(-)
[zl@VM-16-2-centos lesson]$ cat readme
hello world
bbb  on dev branch

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

[zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'

  结果还是aaa on dev branch

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

[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ git add .
[zl@VM-16-2-centos lesson]$ git commit -m "md readme: ccc"
[master 9c88ce4] md readme: ccc
 1 file changed, 1 insertion(+), 1 deletion(-)
[zl@VM-16-2-centos lesson]$ git branch
  dev1
* master

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

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

[zl@VM-16-2-centos lesson]$ git merge dev1
Auto-merging readme
CONFLICT (content): Merge conflict in readme
Automatic merge failed; fix conflicts and then commit the result.

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

<<<<<<< HEAD
ccc  on dev branch
=======
bbb  on dev branch
>>>>>>> dev1

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

[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ 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
#

[zl@VM-16-2-centos lesson]$ git add .
[zl@VM-16-2-centos lesson]$ git commit -m "merge dev1"
[master c54f7be] merge dev1
[zl@VM-16-2-centos lesson]$ git status
# On branch master
nothing to commit, working directory clean
[zl@VM-16-2-centos lesson]$ cat readme
hello world
bbb  on dev branch

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

  ⽤带参数的git log也可以看到分⽀的合并情况，具体⼤家可以⾃⾏搜索 git log 的⽤法:

git log --graph --pretty=oneline --abbrev-commit

prapgh：表示使用图示的方式展示
abbrev：表示将长的commit id变成短的commit id

五、分⽀管理

  通常合并分⽀时，如果可能，Git会采⽤ Fast forward 模式。还记得如果我们采⽤ Fast forward 模式之后，形成的合并结果是什么呢

  在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是merge进来的还是正常提交的。
  但在合并冲突部分，我们也看到通过解决冲突问题，会再进⾏⼀次新的提交，得到的最终状态为：

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

  Git⽀持我们强制禁⽤Fast forward 模式，那么就会在merge时⽣成⼀个新的commit ，这样，从分⽀历史上就可以看出分⽀信息。下⾯我们实战⼀下 --no-ff ⽅式的git merge 。⾸先，创建新的分⽀ dev2 ，并切换⾄新的分⽀:

[zl@VM-16-2-centos lesson]$ git checkout dev2
Switched to branch 'dev2'

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

[zl@VM-16-2-centos lesson]$ git add .
[zl@VM-16-2-centos lesson]$ git commit -m "md readme"
[dev2 930c91c] md readme
 1 file changed, 1 insertion(+)

  切回 master 分⽀，开始合并:

zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'
[zl@VM-16-2-centos lesson]$ git merge --no-ff -m "merge dev2" dev2
Merge made by the 'recursive' strategy.
 readme | 1 +
 1 file changed, 1 insertion(+)

  请注意 --no-ff 参数，表⽰禁⽤Fast forward 模式。禁⽤ Fast forward 模式后合并会创建⼀个新的 commit ，所以加上 -m 参数，把描述写进去。
  可以看到，不使⽤ 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的代码在⼯作区中开发了⼀半，还⽆法提交，怎么办？

[zl@VM-16-2-centos lesson]$ git branch -d dev1
Deleted branch dev1 (was 3dc0539).
[zl@VM-16-2-centos lesson]$ git checkout dev2
Switched to branch 'dev2'
[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ git checkout master
M	readme
Switched to branch 'master'
[zl@VM-16-2-centos lesson]$ cat readme
hello world
bbb  on dev branch
abcde
abc
i am coding

[zl@VM-16-2-centos lesson]$ 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")

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

[zl@VM-16-2-centos lesson]$ git checkout dev2
M	readme
Switched to branch 'dev2'
[zl@VM-16-2-centos lesson]$ git stash
Saved working directory and index state WIP on dev2: 930c91c md readme
HEAD is now at 930c91c md readme

  ⽤ git status 查看⼯作区，就是⼲净的（除⾮有没有被Git管理的⽂件），因此可以放⼼地创建分⽀来修复bug。
  储藏 dev2 ⼯作区之后，由于我们要基于master分⽀修复bug，所以需要切回 master 分⽀，再新建临时分⽀来修复bug，⽰例如下：

[zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'
[zl@VM-16-2-centos lesson]$ git checkout -b fix_bug
Switched to a new branch 'fix_bug'
[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ git add .
[zl@VM-16-2-centos lesson]$ git commits -m "fix bug:f"
git: 'commits' is not a git command. See 'git --help'.

Did you mean this?
	commit
[zl@VM-16-2-centos lesson]$ git commit -m "fix bug:f"
[fix_bug 94c04ee] fix bug:f
 1 file changed, 1 insertion(+), 1 deletion(-)

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

[zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'
[zl@VM-16-2-centos lesson]$ git merge --no-ff -m "merge fix_bug" fix_bug
Merge made by the 'recursive' strategy.
 readme | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
[zl@VM-16-2-centos lesson]$ git status
# On branch master
nothing to commit, working directory clean
[zl@VM-16-2-centos lesson]$ cat readme
hello world
bbb  on dev branch
abcde
abcdef

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

[zl@VM-16-2-centos lesson]$ git checkout dev2
Switched to branch 'dev2'

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

[zl@VM-16-2-centos lesson]$ git stash list
stash@{0}: WIP on dev2: 930c91c md readme

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

[zl@VM-16-2-centos lesson]$ 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} (258adcb6cbf0227607699fa772e6c37cf78c1900)

  再次查看的时候，我们已经发现已经没有现场可以恢复了
  另外，恢复现场也可以采⽤ git stash apply 恢复，但是恢复后，stash内容并不删除，你需要⽤ git stash drop 来删除；
  你可以多次stash，恢复的时候，先⽤ git stash list 查看，然后恢复指定的stash，⽤命令git stash apply stash@{0} ,这部分请同学们⾃⾏使⽤。
  恢复完代码之后我们便可以继续完成开发，开发完成后便可以进⾏提交，例如：

[zl@VM-16-2-centos lesson]$ cat readme
hello world
bbb  on dev branch
abcde
abc
i am coding

[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ git add .
[zl@VM-16-2-centos lesson]$ git commit -m "md readme:done"
[dev2 2cdac41] md readme:done
 1 file changed, 1 insertion(+)
[zl@VM-16-2-centos lesson]$ git branch
* dev2
  fix_bug
  master
[zl@VM-16-2-centos lesson]$ git merge --no-ff -m "merge master" master
Auto-merging readme
CONFLICT (content): Merge conflict in readme
Automatic merge failed; fix conflicts and then commit the result.

  但我们注意到了，修复bug的内容，并没有在dev2 上显⽰。此时的状态图为：

  Master 分⽀⽬前最新的提交，是要领先于新建 dev2 时基于的 master 分⽀的提交的，所以我们在 dev2 中当然看不⻅修复bug的相关代码。
  我们的最终⽬的是要让 master 合并 dev2 分⽀的，那么正常情况下我们切回 master 分⽀直接合并即可，但这样其实是有⼀定⻛险的。
  是因为在合并分⽀时可能会有冲突，⽽代码冲突需要我们⼿动解决（在 master 上解决）。我们⽆法保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项⽬中，代码冲突不只⼀两⾏那么简单，有可能⼏⼗上百⾏，甚⾄更多，解决的过程中难免⼿误出错，导致错误的代码被合并到 master 上。此时的状态为：

  解决这个问题的⼀个好的建议就是：最好在⾃⼰的分⽀上合并下 master ，再让 master 去合并dev ，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响 master 。此时的状态为：


  对应的实操演⽰如下，要说明的是，以下演⽰的merge操作，没有使⽤ --no-ff ，但上述的图⽰是禁⽤ Fast forward了模式后得出的，主要是为了⽅便解释问题。

[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ git add .
[zl@VM-16-2-centos lesson]$ git commit -m "merge master fix"
[dev2 0cea538] merge master fix
[zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'
[zl@VM-16-2-centos lesson]$ git merge --no-ff -m "merge dev2" dev2
Merge made by the 'recursive' strategy.
 readme | 2 ++
 1 file changed, 2 insertions(+)
[zl@VM-16-2-centos lesson]$ cat readme
hello world
bbb  on dev branch
abcde

i am coding...done
abcdef

[zl@VM-16-2-centos lesson]$ git branch
  dev2
  fix_bug
* master
[zl@VM-16-2-centos lesson]$ git branch -d fix_bug
Deleted branch fix_bug (was 94c04ee).
[zl@VM-16-2-centos lesson]$ git branch -d dev2
Deleted branch dev2 (was 0cea538).

七、强制删除分支

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

[zl@VM-16-2-centos lesson]$ git checkout -b dev3
Switched to a new branch 'dev3'
[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ git add .
[zl@VM-16-2-centos lesson]$ git commit -m "md readme"
[dev3 bb0c00c] md readme
 1 file changed, 1 insertion(+)
[zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'
[zl@VM-16-2-centos lesson]$ 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'.

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

[zl@VM-16-2-centos lesson]$ git branch -D dev3
Deleted branch dev3 (was bb0c00c).
[zl@VM-16-2-centos lesson]$ git branch
* master