Git分支管理，多学点东西，总会有用的！

创建与合并分支

1、首先，我们创建dev分支，然后切换到dev分支：

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

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

然后，用git branch命令查看当前分支：

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

2、在dev分支上修改，然后正常提交

切换回master分支：

切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变。

3、把dev分支的工作成果合并到master分支上

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

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

法二：

最新版本的Git提供了新的git switch命令来切换分支：
创建并切换到新的dev分支，可以使用：

$ git switch -c dev

直接切换到已有的master分支，可以使用：

$ git switch master

使用新的git switch命令，比git checkout要更容易理解。

小结

Git鼓励大量使用分支：
查看分支：git branch
创建分支：git branch
切换分支：git checkout 或者git switch
创建+切换分支：git checkout -b 或者git switch -c
合并某分支到当前分支：git merge
删除分支：git branch -d
用带参数的git log也可以看到分支的合并情况：

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

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
详情请见：https://www.liaoxuefeng.com/wiki/896043488029600/900004111093344

分支管理策略

在实际开发中，我们应该按照几个基本原则进行分支管理：
1.首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
2.那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
3.你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：

小结

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

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

Bug分支

Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

$ git stash

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

$ git checkout master
$ git checkout -b issue-101

*开发一个新feature，最好新建一个分支；
如果要丢弃一个没有被合并过的分支，可以通过git branch -D 强行删除。

多人协作

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

多人协作的工作模式通常是这样：

1、首先，可以试图用git push origin 推送自己的修改；
2、如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
3、如果合并有冲突，则解决冲突，并在本地提交；
4、没有冲突或者解决掉冲突后，再用git push origin 推送就能成功！
如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to origin/。

推送分支

推送分支，就是把该分支上的所有本地提交推送到远程库。

$ git push origin master

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

$ git push origin dev

哪些分支需要推送？

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

后面的内容，稍微简略，如有不明白的地方，请去廖雪峰的官网