简单回顾上一篇内容，讲解了一些最基本的创建仓库、提交代码、版本回退、删除文件、添加远程仓库、克隆仓库等。
动画：扫盲Git版本控制（上）
之所以花费两篇文章来给大家扫盲，理由竟然是有关鹿哥的一段黑历史。
但是为了能够赶上时代潮流，我和团队小伙伴说，咱们也用用git吧。这一用不打紧，但是把自己连带团队成员拉下了水，那是玩得不亦乐乎、无中生有，暗度陈仓，凭空想象，凭空捏造，无言无语...
别人刚费劲两天修改的bug，让我几行命令就回到解放前，反而不知道如何恢复，不说了，说起来都是泪~
上一篇扫盲的最基本的几个操作以及git原理，就是为了从根上去了解认识git版本控制。这篇文章也是更加深入分享一些更加难以理解的概念。
但是鹿哥会尽量大白话和用动画图解方式去讲，我跳过的坑，不能让你们再跳进去了。
什么是分支管理？
咱们先来看一下分支的概念。为什么会用到分支，我们还是需要还原一下场景。
一般我们正常开发是有一个主分支的，也就是master分支，一般我们之前所有的改动都是在这个master分支上改动的。每次提交，都会有一个记录，然后形成一条时间线。
但是我们来看另一个场景，比如团队共同开发一个小程序项目，每个人都负责一个功能，只有当每个人开发完成自己的完整功能后才能进行提交合并，发布上线。
但是我在开发的时候，发现这个功能需要几个月完成，每天我都会写一点内容，下班后，我怕我写的内容丢失，这时我选择提交。
但是问题来了，我提交之后是不完整的代码，别人进行开发时，肯定导致项目不能完整运行，所以我不能选择提交，为了能够保留当前的进度，所以分支概念出现了。
为了不影响别人开发进度，同时保留自己的每天开发的进度，我可以创建一个分支dev1，在这个分支dev1上，相当于一个独立的空间线。我想怎么玩就怎么玩，别人也看不到，也影响不到别人开发。
几个月后，我的功能全部开发完成了，然后我把我的分支合并到项目总分支上去，这样就完美得到解决。
分支操作
创建一个独立分支(dev)，命令如下：
git中的进度是通过指针指向来控制的，虽然当前创建了一个新的分支，但是当前HEAD指针指向是master分支。
如果我们不知道当前指针指向哪个分支上，我们通过下边命令查看。
为了能够在自己分支上提交代码，所以我们要切换分支到dev上，命令如下：
然后我们开始提交代码，提交完后，我们再切回到原来的master主分支。
你会发现，你的文件内容是没改动之前的状态。因为我们所有的改动是在dev分支上改变的。
我们想要将dev改动合并到master分支上，必须执行以下合并的命令。
你会发现，当前的文件就是修改之后的状态。
合并完成之后，我们可以删除dev分支了，执行下边的命令。
解决冲突
虽然上边看起来操作行云流水，清晰易懂，但是在真正的开发项目中，会出现各种各样的情况。
比如代码合并冲突，遇到这种情况，尤其是刚接触git的同学，经常会措手不及，弄好了，很多就能够解决，弄不好，整个项目就麻烦了。
当时在合并项目的时候，我就入了这个坑，强制提交导致了同伴修改的功能全部丢失，所以合并冲突需谨慎。
什么情况下会导致合并冲突呢？
当我们两个人同时去修改一个文件，进行提交时，当前git不知道你两个人以谁修改的为主，就导致了冲突。
所以需要我们手动修改冲突之后，我们再进行提交。
我们可以通过gitstatus命令查看发生冲突的文件。
我们打开文件，会提示我们两个不同分支提交内容，我么你通过手动修改，来选择其中一个分支内容，从而解决冲突，重新提交就OK。
分支管理
通常我们用master分支来发布项目新的版本，所有的开发会创建一个dev分支来进行项目开发。
每个人都会创建自己的分支，每个功能完成之后，我们所有人先合并到dev分支上。
当测试完项目没有问题之后，我们再合并到master分支上，用于版本的迭代更新。
同步远程分支
这只是在本地进行分支操作，我们想把这些操作对应到远程分支上，需要进行关联，上一篇中，我们进行本地分支和远程分支关联的命令为：
gitpush-uoriginmaster
-u参数就是把本地master分支和远程的master分支进行关联起来，以后推送再进行推送至远程仓库，不用增加-u参数。
小结
Git有非常多的玩法，剩下的就靠自己去探索。上边分享到了和之前分享的一篇在开发中足以够用。
扫盲Git算是完结了，具体的还是要在团队合作和项目开发中实践，一谈起GIt，就想起自己的黑历史，今天到这了，如果觉得文章对你有帮助，欢迎在看转发，感谢各位小伙伴的厚爱！推荐阅读动画：浅谈后台MVC模型与MVVM双向绑定模型吭哧吭哧写了两年，所有文章分类汇总！一个三本混出来的程序员，维护着一个既有技术又有温度的原创号，一直认为能把复杂的东西讲明白是一件很牛逼的事情。
熬肝不易求个在看，拜谢！预览时标签不可点收录于合集#个上一篇下一篇