@(139 - Environment Settings | 环境配置)

一、Why？

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

二、创建与合并分支

2.1 Why? - Git高效原因 - 指针操作

Git高效原因：指针操作
HEAD指向的就是当前分支。

Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

原理图参考-廖雪峰git

2.2 分支操作代码

Git鼓励大量使用分支：

查看所有分支：git branch

创建分支：git branch <branch_name>

切换分支：git checkout <branch_name>

创建+切换分支：git checkout -b <new_branch_name>

合并某分支到当前分支：git merge <name>

删除分支：git branch -d <name>

2.3 Demo

1.我们把dev分支的工作成果合并到master分支上：

$ git merge devUpdating d17efd8..fec145a
Fast-forwardreadme.txt |    1 +1 file changed, 1 insertion(+)

2.合并完成后，就可以放心地删除dev分支了：

$ git branch -d dev
Deleted branch dev (was fec145a).

3.删除后，查看branch，就只剩下master分支了：

$ git branch
* master

因为创建、合并和删除分支非常快，所以Git鼓励你

1.使用分支完成某个任务
2.合并后再删掉分支

这和直接在master分支上工作效果是一样的，但过程更安全。

三、解决冲突

P.S. Git Bash
1.查看文本内容cat <name>
2.修改文件内容vi <name>
3.vim 保存并退出:wq

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

用git log --graph命令可以看到分支合并图。

四、分支管理策略

4.1 默认 ：fast forward模式

通常合并分支时，如果可能，Git会默认用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

不使用Fast forward模式，merge后就像这样：

4.2 实际分支策略

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.readme.txt |    1 +1 file changed, 1 insertion(+)

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

4.3 分支管理小结

Git分支十分强大，在团队开发中应该充分应用。

合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

五、Bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，

修复bug时，我们会通过创建新的临时 bug分支进行修复，然后合并，最后删除；

1. 保存工作现场 ：git stash
2. 查看stash：git stash list
3. 恢复现场Method1(stash内容并不删除)

$git stash apply
$git stash drop;删除

4.恢复现场Method2(恢复＋删除)：git stash pop

小结：
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场。

六、多人协作

6.1 推送分支

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

master分支是主分支，因此要时刻与远程同步；

dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

6.2 多人协作的工作模式

1.首先，可以试图用git push origin branch-name推送自己的修改；

2.如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

3.如果合并有冲突，则解决冲突，并在本地提交；

4.没有冲突或者解决掉冲突后，再用git push origin branch-name推送就能成功！

5.如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

6.3 多人协作小结

查看远程库信息，使用git remote -v；

本地新建的分支如果不推送到远程，对其他人就是不可见的；

从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；

在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；

建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；

从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。

• 整理转载自 廖雪峰博客 https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000