本地仓库的分支管理。
Git篇: 分支管理
此文章编写于笔者刚开始学习git之时，所以不会有很多深奥的知识与历史，如有疏漏与错误，尽管联系笔者，我会及时修改，避免影响读者观感与知识理解。
那么上一章我们已经学会了如何撤销删除文件或操作，接下来我们就来学习分支管理。
如果你是高中生，那么你一定遇到过假期快结束了，作业却还有一大堆没写，如果有分身就好了，语数英各一个分身去写，本体负责玩。
那么git的分支就与这个想法差不多，通过管理多个分支，最后与主分支合并，实现主分支不变，其他分支完成了不同功能的实现与测试。
听起来就不错！
分支策略
或者叫分支原则，意为在管理分支时所要遵守的原则。
master或main分支必须是稳定！ 分支的存在使多人协作开发成为显示，但是master分支是不可以在多人协作中让一个人单独修改的，只能是团队发布的稳定的新版本，一般是线上环境，如app、网站等，是面向大众的！而其他分支则是内部协作人员的开发环境，方便测试和修改bug，修完bug之后再合并到master分支上发布。
分支管理
查询
如果你想知道当前的主分支是哪条，那么就可以输入以下命令：
git branch
命令窗就会展示各个分支名，并在主分支前面标上一个*，让你明白谁才是老大主分支。
储藏
如果你担心master被别人偷偷修改而你自己又不能时刻盯着的话，不妨试试保存当前所有未提交的修改吧，使用以下命令：
git stash
这个命令可以保存你当前的工作区所有未提交的修改，一般用于任务做到一半，却因为别的分支的事情，而不得不放弃当前分支，切换到其他分支。可以多次存储哦！git会将每一次的stash以栈的形式保存起来。
实际开发中最好给stash加个message，用以下命令即可：
git stash save ""
双引号中填写message内容即可。
那么，你就可以使用git stash保存下来，如果你还想接着写可以用以下命令：
git stash pop
像栈一样pop出来。就可以恢复工作区的修改了。
如果你要查看现有的stash，可以使用以下命令：
git stash list
需要注意的是，stash只会保存你修改过的文件，没有修改过的文件和新添加的文件是不会保存的(被忽略的文件也是不会被保存的)
能用就行，太多的暂时就不必学了。
被忽略的文件指的是有.gitignore文件中所包含的文件名或目录，这个后面再写。
创建
如果你想创建一个dev分支，则可以使用以下命令：
git branch dev
切换
如果你想切换主分支为dev，则可以使用以下命令：
git checkout dev
也许你会不理解，主分支怎么可以切换呢？就像是本体和分身的身份怎么能切换？然而，git对于主分支的概念并不一样，主分支并不是独一无二的，它是由HEAD指针来指向的，HEAD指向谁，谁就是git概念上的主分支。
而我们在实际开发和使用过程中，通常会固定使用main或者master来充当本体，分支对应的功能开发和测试完毕再合并到主分支中，就像是分身把它写完的作业给你一样。
创建并切换
如果你想创建一个dev分支并切换到dev分支上，你可以使用以下命令：
git chechout -b dev
唯一的优点是简洁，毕竟一行命令就解决了。
合并
如果你想把dev分支合并到master分支上，你可以使用以下命令：
git checkout master
git merge dev
第一行表示切换master为主分支(本体)
第二行表示把分支dev(分身)合并到master上。
情况一：只有dev分支更新了
其合并模式为——Fast-forword，它是直接把master指向了dev所指向的版本，以此来快速合并。
情况二：dev和master分支都更新了
如果dev和master对相同的地方做了不同的修改，那么此时就会发生合并冲突。
假如原本有关readme文件，dev分支中它被添加了abc，master分支中它被添加了123。那么，此时git不知道也不能决定该保留水，那么此时就会发生合并冲突，并输出出来冲突的地方在readme文件。
而readme文件早已不是原本的模样了，原本abc或者123所在的地方已经变成了：
<<<<<<< HEAD
123
=======
abc
>>>>>>> dev
«<和===之间的内容是master分支所修改的内容，而===和»>之间的内容是dev分支所修改的内容。
只需要保留目标内容其他的都删掉即可，比如我们要保留dev分支所修改的内容，那么readme里的内容应该是：
abc
然后再使用add和commit命令重新提交冲突的地方即可。
合并总结：
情况一可以快速合并，也就是git自动帮我们合并了，而情况二就需要我们手动合并了，手动合并不要忘了再提交一次！！！
想更直观地了解情况二的合并流程可以使用
git log --graph --abbrev-commit --pretty=one
第三个参数(–pretty=one)只会显示版本ID、分支名(如果是主分支则不显示)和commit内容。
不带则会显示作者名、邮箱和时间等内容。
！！！时间线是从下往上的！！！
需注意，对于情况一，该命令是无法区分是合并操作还是直接提交操作的，如果以后出现了问题，想要查看日志追责时就可能查不到，万一你在那个时间也merge了，你就可能背一部分锅了。所以，我们对于情况一需要换一种命令：
git merge --no-ff -m "" dev
双引号里添加的你提交的信息，–no-ff表示不要fast-forword模式合并。
删除
删除分为两种，一种是分支已经被其他分支合并(merge)了，所以用普通删除，另一种是分支还在使用中，没有被完全合并(merge)，所以我们用强制删除。
如果你想删除dev分支，则可以使用以下命令：
git checkout master
git branch -d dev
git branch
第一行表示切换到master分支。
第二行表示删除dev分支。
第三行表示验尸查看所有的分支名和主分支。
为什么要切换到master分支再删除呢？——因为不能在dev分支里删除dev分支。就像你不能双手把自己举起来一样。
强制删除只是把-d改成-D就好，命令如下：
git checkout master
git branch -D dev
git branch
由于创建、合并和删除分支很快，所以我们可以先创建分支，在分支上完成某项功能，实现成功之后再合并该分支，然后再删除分支。也许你可以说这是多此一举，毕竟这和在main分支直接操作的效果是一样的。而这种操作实际上就只是比直接在master分支上直接操作更安全罢了。但是我喜欢卸磨杀驴
建议
在实际开发中，每个人都负责自己分支，实现多人共同协作，但是，如果说今天master出bug了，其他协作人员快速修好上线，但是，你的分支是昨天创建的，明天才能开发完，那么，你能直接在master分支合并你的分支吗？
不行！！！因为master的代码都是改过的！你不知道是否会有修改冲突的地方，也许你会说，那我再按照合并情况二 来修改不就好了？那我问你，你敢保证你改过之后不会出现新的bug吗？
所以，最好先合并master到你的分支中，在你的分支上修修改改，这样即不会影响master又可以随心所欲地改代码。
最后再合并到master上。