分支管理
分支就是平行时空，但是可以随时合并。
创建和合并分支
我们将HEAD（当前分支）、master都理解为指针，Git用master指向最新的提交，再用HEAD指向master。
创建一个dev分支，此时dev和master指向相同的提交，HEAD指向dev。
这是你在dev分支上工作，提交会更新dev的指向，master就停在原地，当你想合并dev和master怎么做呢？最简单的方法是将master指向dev。
很简单，也很快，只是指针的修改。让我们看看怎么通过命令实现：
创建分支：$ git branch dev 切换分支：$ git switch dev （旧版本用checkout） 以上两条命令可以用一条代替：$ git switch -c dev（旧版本用checkout）
合并合并指定分支到当前分支：$ git merge dev 因此要先让HEAD指向master
删除dev分支：$ git branch -d dev
这种合并分支很快，叫做 Fast-forward ，不是所有的工作都可用快合并，还有其他的合并方式。
冲突了怎么办？
现在你创建了一个新分支feature1，并且在feature1上修改并提交了1次，这时你又切回master分支，稀里糊涂的在master分支上修改了同一个文件并提交了，现在分支就变成这样：
这时合并，Git不知道要保存那个版本，就会提示冲突。此时要手动解决冲突，提交后就能自动合并。
$ git merge feature1 提示冲突 $ git status 可查看冲突 手动修改readme到想要的内容 $ git add readme.txt $ git commit -m "conflict fixed" 提交，自动合并
实际的分支管理策略
如果分支采用快速合并，那么删除分支后，会丢失分支信息，一般我们希望保存分支信息。因此合并时要禁用FF，命令格式：
$ git merge --no-ff dev
我们可以用下面代码查看分支历史：
$ git log --graph
如果是FF模式，删除分支后就看不到分支历史了。
实际开发时，会有一支分支（如master分支）作为稳定版本，可发布版本。通常我们不在master分支上干活，我们会在一条develop分支上工作。
工作模式通常是这样的：
你和小伙伴都在dev分支干活；
每有一个新功能要实现，从dev分出featureX分支，完成后合并到dev；
dev功能实现得差不多时，检查无bug，合并到master，通常合并到master后就会发布新版本。
用图表示就这样:
Bug分支 *
有的时候，你正在干活，老板突然说：小c，我下去买杯咖啡，有个bug你改一下。
那么这时你肯定要停下手中工作，火速搞定bug，向老板展示你超高的效率。但是，你正在做一个feature，还要两天才能做完，不能直接切到别的分支，不然你活白干了。
这时，stash功能派上用场。
$ git stash
Saved working directory and index state WIP on dev: da809c3 first submit
这个命令将你现在的工作现场保护起来，相当于bug是中断，这是中断保护。
这时你就可以放心切到其他分支修复bug。
修复完后，回到你刚刚干活的feature分支，
$ git stash pop 恢复的同时把stash内容也删了
$ git stash apply 恢复后，stash内容并不删除
$ git stash drop 删除stash内容
$ git stash list 可以多次stash，该命令查看stash列表
回到feature分支工作后，你发现那个bug在你这个分支也是存在的，怎么办，难道二二三四再来一次吗？不，Git提供了便捷操作，cherry-pick命令可以复制一个特定的提交到当前分支。
$ git cherry-pick 版本号
这个版本号就是上一次你为bug开了一个分支，在分支上提交一次的版本号。
这样，就简单的只把bug修复部分复制到了现在的分支。
多人协作
推送分支命令：
$ git push origin master(分支名)
克隆库：
$ git clone https/ssh地址
克隆到本地的库，只能看到master分支，要想在dev上开发，还要创建远程的dev分支对应到本地，命令为：
$ git switch -c dev origin/dev
加入两个小伙伴都对同一个文件进行修改后推送，就会造成冲突，解决方法是，后面那个推送的先pull下对应的分支，修改文件解决冲突，再push。
参考：廖雪峰的Git教程