7. 分支管理
创建与合并分支
分支的概念：分支就是每次提交创建的点所连接成的时间线。这条时间线就是一个分支，默认的话只有一个主分支master分支。HEAD严格来说不是指向提交，而是指向master,master才是指向提交，HEAD指向的就是当前分支。
一开始的时候，master分支就是一条线，Git用master指向最新的提交，再用HEAD指向master,就能够确定当前的分支以及当前分支的提交点。
每次提交,master分支都会向前进移动一步，这样随着你不断提交，master分支的线也会越来越长。其结构如下图所示：
1. 创建dev分支
当我们新创建一个分支dev时，Git会创建一个指针dev指向master分支当前的提交点。当切换到dev分支后，HEAD指针会指向dev。也就是说HEAD始终是指向当前分支的。
git checkout -b dev
git checkout 加上-b参数表示创建并切换到dev分支上，相当于下面两条命令。
$ git branch dev $ git checkout dev
执行该上面的命令之后的git的提交时间线如下图所示：
当在dev分支上提交代码（未改变master分支）之后，dev分支会不断的向后推进。而master指针的指向则不会变。
git checkout命令是一个比较特殊的命令，传入不同的参数会有截然不同的效果。例如：git checkout -- file 命令，表示的意思是撤销file文件中所有的修改。所以Git还提供了git switch命令用于创建和切换分支。
## 创建并切换到新的dev分支 git switch -c dev ## 切换到已有的master分支 git switch master
2. 查看所有分支
分支创建好之后，可以通过git branch命令进行查看。
3. 分支合并
当团队成员在dev分支上开发完毕之后，就可以将dev分支上的内容合并到master分支上，合并分支的原理就是将master指针指向dev的当前提交。Git合并分支只是改了下指针，工作区的内容没有改变。
其合并的命令分两步，第一步是切换到master分支，第二步是合并dev分支
#切换到master分支 git checkout master #合并dev分支 git merge dev
通过merge合并的话会有两个分支路径，如果觉得这样不好看的话，可以通过rebase来合并
#切换到master分支 git checkout master #合并dev分支 git rebase origin/dev
这样同样可以将dev分支合并到master分支上。
4. 删除dev分支
现在dev分支的内容也合并到了master分支上了，可以将dev分支删除了。Git删除dev分支其实就是删除dev指针。删除之后又只剩下master分支了。需要注意的是必须要先切换到master分支上再进行删除dev分支的操作。删除dev分支的命令如下:
git branch -d dev
解决冲突
在团队协作过程中，难免会碰到各种修改冲突。那么该如何解决这些冲突呢? 例如：你和你同事分别修改了readme.txt文件，那么当你们同时提交时就会出现冲突。又或者在你在master分支和feature1分支上分别修改了readme.txt文件。那么当你合并feature1分支到master分支时就会出现冲突。举个栗子吧：
1.在feature1分支上给readme.txt文件中加上了文本处理冲突。然后提交到feature1分支。
2.切换到master分支，给readme.txt文件中加上文本
冲突处理 master有冲突
然后提交到master分支上。
3. 将feature1分支合并到master分支，此时就会出现合并冲突。如下图所示：
冲突之后，Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容。如下图所示：
处理冲突的方式就是编辑冲突内容。然后重新提交。
$ git add README.md $ git commit -m "解决冲突"
比较差异
1.比较两个提交之间的差异 git diff 36e4fd7 b55da38
- 比较工作区与仓库区的不同，HEAD表示最新的那次提交
git diff HEAD
分支管理策略
通常情况下，Git在合并分支时，会使用Fast forward模式。但是，这种模式下，删除分支后，会丢掉分支信息。如下图所示，删除dev分支之后，分支的信息也就就丢失了
如果要强制禁用Fast forward模式，Git会在merge时生成一个新的commit。当删除分支时就不会丢失分支信息。其命令是
git merge --no-ff -m "merge with no-ff" dev
准备合并dev分支，其中--no-ff参数，表示禁用Fast forward,因为本次合并要创建一个新的commit，所以加上-m参数。把commit描述写进去。
Bug分支
当你接到一个修复代号为01的bug的任务时，很自然地，你会创建一个分支issue-01来修复它，但是，如果这是你正在dev分支上进行的工作还没有提交,提交吧，可是你在dev上的工作只进行了一般，还没法提交，预计完成还需1天的时间。但是，现在必须要在两个小时内修复代号01的bug。这时候该怎么办呢？你不是期望有一个功能可以隐藏你当前在dev上未提交的工作，然后，切换到issue-01分支修改bug呢。
通过stash功能可以满足你的愿望，将当前工作现场隐藏起来。如下图所示：执行git stash命令之后，新建的hello.html文件就从工作区中消失了。
保存工作现场
git stash
git stash命令可以将当前未提交的工作隐藏起来。让你的工作区变的干净清爽。
查看工作现场
git stash list 可以查看当前仓库所有已经保存的工作现场。
git stash list
恢复工作现场
现在代号为01的bug已经修复好了，你可以继续切换到dev分支上进行开发了。那么这时候你需要做的第一件事就是恢复之前保存的工作现场。恢复工作现场的命令是：
git stash apply
删除工作现场
通过git stash apply 命令可以恢复工作现场。但是，恢复之后工作现场还在。那么这时候我们还需要一个命令来删除工作现场。其命令是：
git stash drop
恢复并删除工作现场
恢复工作现场一条命令，删除工作现场又是一条命令。未免有点繁琐了吧。有没有将两者合二为一的命令呢?答案是有的：通过下面的命令就可以实现：
git stash pop
在master分支上修复了bug后，我们想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？这种方法也不是不行，如果该BUG涉及的修改过多，这样的方式就显得有点捉襟见肘了。那么我们能不能把修改BUG做的提交复制到当前的dev分支呢？答案是有的：
合并某一次的提交
git cherry-pick 821ea4d
通过git cherry-pick 命令可以将单个的提交复制到当前分支。可以通过 git log 查看提交的提交的版本号。
feature分支
添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。
前面介绍可以通过git branch -d branchname 命令删除分支。但是，如果被删除的分支还没有合并到主分支的话，用该命令删除的话分支的话，Git会抛出一个错误提示并不能删除该分支。如下：要删除一个名为feature-01的分支。但是该分支还没有被merge。这时候就需要强制删除分支的命令了。
git branch -D feature-01
其中feature-01为待删除的分支名。其实就是将-d参数换成-D参数。
