05 分支管理

1 创建与合并分支

1.1 创建 dev 分支并切换到dev分支

git checkout -b dev

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

git branch dev
git checkout dev

1.2 git branch命令查看当前分支

git branch命令会列出所有分支，当前分支前面会标记*号

现在在dev分支上进行修改：
在readme.txt文件上加上一行内容：

Creating a new branch is quick.

然后进行添加提交

1.3 现在 dev 分支工作已经完成，切换到创建 master 分支

git checkout master

1.4 查看 readme.txt 文件内容

查看当前master 分支readme.txt 文件内容：

可以看出并没有发现在 dev 分支下修改的内容！因为那个提交是在dev 分支下进行的，而master 分支此刻的提交点并没有改变

1.5 合并分支

现在我们把dev分支上的成果合并到master分支上

git merge dev

git merge 命令用于合并指定分支到当前分支，上面 Fast-forward 表示这次合并是“快进模式”，也就是直接把master指向dev的提交，所以合并速度很快。

然后再查看 readme.txt 内容，就可以看到和 dev 分支的最新提交是一样的

1.6 删除分支

合并完成后，就可以放心的删除dev 分支了

git branch -d dev

再查看branch，只剩下master分支了

命令小结：

查看分支：git branch
创建分支：git branch 分支名
切换分支：git checkout 分支名
创建并切换分支：git checkout -b 分支名
合并某分支到当前分支：git merge 分支名
删除分支：git branch -d 分支名

2 解决冲突

2.1 准备新的分支

git checkout -b fea

修改readme.txt最后一行

2.2 提交新分支

2.3 切换到master分支

git checkout master

修改readme.txt最后一行内容

2.4 在master分支上提交

2.5 合并分支

git merge fea

这种情况下合并分支会出现冲突！必须手动解决之后再提交
git status告诉我们冲突的文件

此时查看readme.txt文件内容：

vi readme.txt

Git用<<<<<<<,>>>>>>>表示不同的分支，用=======分割分支

现在修改readme.txt内容如下

2.6 修改后再提交

由上图可以看出修改后再提交的变化
用带参数的git log可以看到分支的合并情况

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

git log --graph可以看到分支合并图

2.7 删除分支

最后完成工作后删除分支

git branch -d fea

3. 分支管理策略

通常合并分支时，Git用Fast forward模式，但是这种模式在删除分支以后会丢掉分支信息。
如果强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样从分支历史上就可以看出历史信息。

下面开始实战 --no-ff 方式的git merge

3.1 创建并切换分支

git checkout -b dev

3.2 修改文件并提交

修改 readme.txt文件内容并提交

3.3 切换到master分支并合并dev分支

git merge --no-ff -m "merge with no-ff" dev

因为本次要创建一个新的commit，所以加上 -m参数，把commit描述添加进去

再用git log 参数查看一下分支历史

分支策略：
1.master分支非常稳定，仅用来发布新版本，平时不能在上面干活
2.干活在dev分支上，发布版本时再合并到master分支，然后在master分支上发布

4. bug分支

软件开发中，经常出现bug，在Git中，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除

4.1 假设现在有一个代号为100的bug任务

需要通过创建一个分支issue-100来修复它，但是当前在dev上进行的工作还没有提交：

并不是不提交，而是完成工作还需要一天时间，现在需要两小时内修复bug，这就需要把当前工作现场“隐藏”起来，等修复bug后在恢复现场继续工作，Git提供了一个stash功能可以做到。

git stash

4.2 临时分支

首先需要确定在哪个分支上修复bug，假设在 master 分支上

1. 切换到master并创建临时分支
   
2. 修复bug并提交
   在 readme.txt 文件最后一行添加 fix bug 100 ，然后提交

git add readme.txt
git commit -m "fix bug 100"

3. 修复完成后，切换到master分支，并完成合并，最后删除issue-100分支
   

4.3 回到 dev 分支，继续干活

bug修复完成后，接着回到dev分支继续干活

现在工作区是干净的，之前的工作现场不见了，用 git stash list命令查看一下：

工作现场还在，Git把stash内容存放到某处了，需要恢复一下：
方法一：用 git stash apply命令恢复，stash内容并不删除，需要用git stash drop来删除。
方法二：用git stash pop，恢复的同时把stash也删了

这时再用 git stash list查看，就看不到任何stash内容了

另外可以多次stash，恢复的时候用git stash list查看，然后回复指定的stash，用命令：

git stash apply stash@{0}

4.4 在dev分支上修改bug
参考学习：https://www.liaoxuefeng.com/wiki/896043488029600/900388704535136

5. Feature分支

软件开发中总有无穷无尽的功能不断添加进来，添加新功能时，为了不把主分支搞乱，每添加一个新功能，就新建一个feature分支，在上面开发完成合并，最后删除。

丢弃一个没有被合并过的分支，可以通过 git branch -D 分支名强行删除。

6. 多人协作

当从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，远程仓库的名称默认是origin

查看远程仓库的信息用：git remote
或者用git remote -v显示更详细的信息

上面显示了可以推送和抓取的origin的地址，如果没有推送权限就看不到push地1地址

6.1 推送分支

推送分支就是把该分支上的所有本地提交推送到远程仓库。推送时要指定本地分支，这样Git就会把该分支推送远程库对应的远程分支上：

git push origin master

如果要推送其他分支，比如dev，就改成：

git push origin dev

但是并不是一定要把本地分支往远程推送，哪些需要哪些不需要呢？

master分支是主分支，因此要时刻与远程同步
dev分支是开发分支，团队所有成员都在上面工作，因此也需要与远程同步
bug分支只用于在本地修复，就没必要推送到远程了，除非老板要看你每周修复了多少bug
feture分支是否推送到远程，取决于你是否和的小伙伴在上面开发

6.2 抓取分支
目前还没有实践，需要实践操作可以参考一下文章：https://www.liaoxuefeng.com/wiki/896043488029600/900375748016320

7. Rebase

目前还没有遇到，日后添加
需要实践参考：https://www.liaoxuefeng.com/wiki/896043488029600/1216289527823648