你好! Git——分支管理

在Git里，master分支也叫主分支。
HEAD 严格来说不是指向提交，⽽是指向master，master才是指向提交的，所以，HEAD 指向的就是当前分⽀。

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

一、创建、切换、合并、删除分支

创建分支并切换的指令：

git checkout -b dev1

1.1 创建分支

HEAD指向的分支就是我们当前工作的分支

查看当前所有分支指令：

git branch

创建分支指令：

git branch dev//创建dev分支

*代表的是当前指向的分支

1.2 切换分支

切换分支指令：

git checkout dev

在当前分支对文件进行add ，commit操作，HEAD指向了当前最新的提交，别的分支并没有这个提交，如果切换到别的分支，是看不到这个提交得。

1.2 合并分支

切换当前分支然后合并掉需要合并的分支。
合并分支的指令：

git merge 被合并分支的名字

git merge命令⽤于合并指定分⽀到当前分⽀。合并后，master 就能看到dev 分⽀提交的内容了。Fast-forward 代表“快进模式” ，也就是直接把master指向dev的当前提交，所以合并速度⾮常快。 当然，也不是每次合并都能 Fast-forward，我们后⾯会讲其他⽅式的合并。

1.2 删除分支

删除分支指令：

git branch -D 删除的分支名字

如图可知，使用git branch -D dev 指令后，dev分支就被删掉了

二、合并冲突

创建分支并切换的指令：

git checkout -b dev1

2.1 合并分支

1. 这是dev1分支
   
2. 这是master分支
   
3. 合并分支
   合并分支的指令：

git merge 分支名

merge冲突需要手动去解决，解决冲突后，需要进行一次add，commit提交操作。

合并分支，产生了合并冲突，我们需要进入文件，手动修改冲突。

手动解决冲突后，我们需要把改动的信息再次add、commit一下，然后查看在上次提交后有没有修改。

2.2 合并模式

1. 我们可以用图形化的方式查看分支情况

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

2. 合并有两种模式
通常合并分⽀时，如果可能，Git 会采⽤ Fast forward模式（合并后需要进行修改信息提交）。
删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是 merge 进来的还是正常提交的。

非 Fast forward模式（不需要进行提交）
指令是：

git merge --no-ff -m "描述修改文件的信息" 被合并的分支名

三、分支管理策略

3.1 分支策略

⾸先，master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平时不能在上⾯⼲活；那在哪⼲活呢？⼲活都在dev分⽀上，也就是说，dev分⽀是不稳定的，到某个时候，⽐如1.0版本发布时，再把dev分⽀合并到master上，在master分⽀发布1.0版本；你和你的⼩伙伴们每个⼈都在dev分⽀上⼲活，每个⼈都有⾃⼰的分⽀ ，时不时地往dev分⽀上合并就可以了。

团队合作的分⽀看起来就像这样：

3.2 bug分支

假如我们现在正在dev2分⽀上进⾏开发，开发到⼀ 半，突然发现 master 分⽀上⾯有 bug，需要解决。 在Git中，每个 bug 都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀ ，然后将临时分⽀删除。

1. dev2的代码在⼯作区中开发了⼀ 半，还⽆法提交，怎么办？
   Git 提供了git stash命令，可以将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来。（前提条件是工作区的信息，一开始就被git跟踪控制了，如果是新文件，没有add，commit进行提交，那么这个文件不能被控制，也就是说，git stash不能将工作区的信息进行存储）
2. 创建一个新的分支，用来处理bug（git checkout -b fix_bug），bug修复完毕后，需要add commit 操作。
3. 切换到master分支上，我们可以进行分支合并了（修复好bug的分支）git merge --no-ff -m"merge fix_bug branch" fix_bug，最后删除fix_bug分支。
4. bug 的修复⼯作已经做完了，我们还要继续回到dev2分⽀进⾏开发，怎么恢复工作区信息

1.刚才的⼯作现场存到哪去了？用git stash list命令看看
2.git stash pop命令可以恢复工作现场，恢复的同时会把stash也删掉。
3.恢复现场也可以采⽤git stash apply恢复，但是恢复后，stash内容并不删除，你要⽤ git stash drop 来删除。
4.可以多次使用stash来进行恢复，先用git stash list查看，恢复的时候可以指定stash，⽤命令git stash apply stash@{0}

5. 恢复完代码之后我们便可以继续完成开发，开发完成后便可以进⾏add，commit提交。
6. 因为master分⽀⽬前最新的提交，是要领先于新建 dev2 时基于的master分⽀的提交的，所以我们在 dev2 中当然看不⻅修复 bug 的相关代码。如何解决？

解决这个问题的⼀个好的建议就是：最好在⾃⼰的分⽀上（dev2）合并一下master分支，再让master分支去合并dev2，这样做的⽬的是有冲突可以在本地分⽀（dev2）解决并进⾏测试，而不影响master分支。

3.3 删除临时分支

如果我们开发一个功能开发到一半（每个功能都是不同分支），突然就不需要开发了，这时候feature分支必须销毁，传统的命令删除分支指令是不行得（git branch -d feature），我们需要用到强制删除分支的指令（git branch -D feature）。

创建分支并切换到feature分支，在该分支下写一个功能

假如我们功能写到一半，然后突然不需要这个功能了，这时候要删除这个功能
1.打印这个功能代码，让我们知道这里面有数据
2.这个些数据，我们已经提交一部分到版本库里了（已经被git版本库跟踪）
3.查看本地仓库有几个分支
4.切换分支到master
5.删除分支，我们发现删除不了分支
6.这时候我们用强制删除分支指令
7.查看本地仓库有多少分支，发现feature分支已经被强制删除了。

四、小结

分⽀在实际中有什么⽤呢？ 假设你准备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50% 的代码，如果⽴刻提交，由于代码还没写完，不完整的代码库会导致别⼈不能⼲活了。 如果等代码全 部写完再⼀次提交，⼜存在丢失每天进度的巨⼤⻛险。
现在有了分⽀ ，就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀ ，别⼈看不到，还继续在原来的分⽀上正常⼯作，⽽你在⾃⼰的分⽀上⼲活，想提交就提交，直到开发完毕后，再⼀次性合并到原来的分⽀上，这样，既安全，⼜不影响别⼈⼯作。
并且Git ⽆论创建、切换和删除分⽀，Git在1秒钟之内就能完成！⽆论你的版本库是1个⽂件还是1万个⽂件。