使用git（二）分支切换与合并

本来总结自极客学院git系列视频教程地址

本地分支与合并的主要命令：

1.git branch：创建分支

2.git tag：用给定的一个commit做标记

3.git checkout：在不同分支间进行切换

4.git stash：在切换分支前保存本地的修改

5.git merge：合并分支

一、分支切换的概念

当我们有一些其他的工作，不想直接在master分支上做的时候（例如，增加一些新的特性，或者做问题的修改和测试等），这是我们就需要新的一个分支。

（分支即是commit的不同引用，在这些分支上，会产生各自的历史。

分支切换即为HEAD引用的一个移动，以及暂存区与工作区的还原。）

我们用git branch 来创建一个新的分支。此时命令行提示中，还是处于原来的master分支上，这时我们需要使用 git checkout 来切换分支



我们在新的分支上做一些修改（创建文件并提交）





做完上述修改后，我们再切换回master分支，查看master.txt文件，发现，刚才在test分支上所做的修改都没有了。



我们在每个分支上所做的修改都是独立的，不会影响到其他分支。

切换分支的时候，会使用分支上最新的提交来还原暂存区和工作区，这样就可以在不同分支间独立的做我们想做的工作，并且可以再个分支间做无缝的来回切换。

分支名师当前分支的最新提交的那个commit的引用。

分支每提交一次，它就指向最新的那个提交。

那么，如何让一个引用指向一个固定的提交呢？

比如，一些提交是做版本release的，当一个release发生错误时，我们能根据这个引用，轻松地切换回那个提交，而不是去查看历史记录然后再去修改。我们可以使用tag来完成。

二、tag的使用

tag分类

tag分为轻量级tag和annot带注解的tag

1.轻量级：只是本地的引用

2.带注解：实际上是git tag对象，存储在git仓库中，当你需要的时候，可以推送到服务器共享。

我们来查看一下当前历史



看到有3个提交以及指向这些提交的引用，一个test分支，一个HEAD标签，指向master分支。

tag的创建

1.创建轻量级tag

现在，我们对master分支上的第一个提交（22dcf2c）做一个轻量级的tag。

git tag "v0" 22dcf2c

其中“vo”为tag名称，现在，我们对master分支上的第一个提交（22dcf2c）做一个轻量级的tag。

22dcf2c为hash（一个5-7位的hash就够表示一个git对象了，git会帮我们自动不起其余的）。

若不指定hash，则默认使用当前指向的commit，即此时HEAD指向的master分支。

2.创建带注解的tag

git tag -a "INITIAL_COMMIT" 22dcf2c

一般用大谢来标注这些tag，这时会提示我们输入一些tag信息



3.使用 git tag 来查看当前tag列表



4.git show tagName

当再次查看commit信息时，我们发现，这些commit上多了两个tag，分别是

tag: v0 和 tag: INITIAL_COMMIT



用git show 来查看tag的具体信息



可以看到，v0实际上直接指向了一个commit，也就是22dcf2chege commit



而INITIAL_COMMIT实际上是一个tag对象，指向22dcf2c这个commit

三、分支切换checkout

当需要回到那些tag时，也可以直接使用tag名切换，因为它们实际上也是指向了一个提交。如：git checkout v0



这里提示我们处于一种“detached HEAD”的状态，也就是说，HEAD直接指向了一个commit，而不是一个分支名，此时若我们继续在当前分支下工作，当切换到其他分支时，前面所做的修改的历史记录可能就被丢弃了。这时可以使用：git checkout -b new_branch_name （new_branch_name 为新的分支名）来用当前的commit创建一个分支，并且切换到这个分支页面。它实际上是git branch 和git checkout的一个组合。

git checkout -b new_v0;



切换到new_v0分支，其实实际上它指向的还是原来那个v0 tag，此时便可以继续工作了。

四、切换分支前保存本地修改

有时，我们修改了工作区去暂存区，比如，我们修改了master.txt文件的内容，并将其添加到暂存区，此时，如果我们切换回master分支，会提示报错。



提示我们本地的一些修改还没有被提交，若梅提交这些修改，在checkout时就会被覆盖，妖气commit或者把它们stash起来。我们使用git stash 命令

1.保存暂存区

git stash save -a "stash1"

使用 -a 参数来说明 保存暂存区， “stash1”是stash的信息。

执行完该命令后，使用git status查看状态，发现暂存区与工作区都原来的历史一样了。



2.还原暂存区

使用git stash list 查看当前stash列表



里面有一个stash0的引用，它指向了我们之前的stash。

在切换到别的分支完成工作后，再切换回原来的分支时，需要把存储的东西还原出来

git stash pop --index stash@{0}

用 –index 表示还原暂存区，stash@{0} 为stash的引用，若不加上stash的引用，则默认使用栈顶的引用。

此时master.txt文件已经在暂存区准备提交了，查看master.txt文件，发现添加的stash one信息也在里面，说明stash已经成功地被还原到暂存区与工作区了，这事我们就可以继续进行原来的工作了。





在执行stash pop命令后，stash list 被清空（即 stash#{0}），若需要保存stash，可以使用：

git stash apply –index stash@{0}

查看stash list：`git stash list`
删除一个stash：`git stash pop stash@{0}`
一次性清理所有stash：`git stash clear`

五、合并分支

分支合并分为两种：

1.fast-farword merge

2.non-fast-farword merge

fast-forward merge

在某个时间点，我们得把分支上的工作合并到我们需要的一个分支上，这样分支上做的工作才有意义。

首先，我们切换回master分支，然后用master指向的commit来创建一个分支，并切换到该分支。



然后修改master.txt文件，并将其提交到历史记录中，查看历史记录的树状图，我们发现，test_merge指向的commit实际上是master指向的commit锁衍生出来的。



切换回master分支，合并test_merge



此时，提示我们这是一个“fast-forward”的merge，也就是说，这个merge的操作和merge的内容都是它当前指向的commit所衍生出来的一些commit，这样的一个merge，并不需要新的提交，只需把工作区与暂存区回复到test_merge上的一个状态，然后把master指向test_merge所指向的呢个merge就可以了。

non-fast-forward merge

合并master与test

它会自动帮我们把文件合并，提示我们在test下的修改与test_merge下的修改有冲突，我们需要将冲突处理完后再将它添加到暂存区，也可以使用git merge –abort来放弃此次的合并。



这种merge与第一种“fast-forward”的不同之处在于，它增加了一个commit来曾在这个merge的信息。