动画：扫盲 Git 版本控制（下）

简单回顾上一篇内容，讲解了一些最基本的创建仓库、提交代码、版本回退、删除文件、添加远程仓库、克隆仓库等。

动画：扫盲 Git 版本控制（上）

之所以花费两篇文章来给大家扫盲，理由竟然是有关鹿哥的一段黑历史。

但是为了能够赶上时代潮流，我和团队小伙伴说，咱们也用用 git 吧。这一用不打紧，但是把自己连带团队成员拉下了水，那是玩得不亦乐乎、无中生有，暗度陈仓，凭空想象，凭空捏造，无言无语...

别人刚费劲两天修改的 bug，让我几行命令就回到解放前，反而不知道如何恢复，不说了，说起来都是泪~

上一篇扫盲的最基本的几个操作以及 git 原理，就是为了从根上去了解认识 git 版本控制。这篇文章也是更加深入分享一些更加难以理解的概念。

但是鹿哥会尽量大白话和用动画图解方式去讲，我跳过的坑，不能让你们再跳进去了。

什么是分支管理？

咱们先来看一下分支的概念。为什么会用到分支，我们还是需要还原一下场景。

一般我们正常开发是有一个主分支的，也就是 master 分支，一般我们之前所有的改动都是在这个 master 分支上改动的。每次提交，都会有一个记录，然后形成一条时间线。

但是我们来看另一个场景，比如团队共同开发一个小程序项目，每个人都负责一个功能，只有当每个人开发完成自己的完整功能后才能进行提交合并，发布上线。

但是我在开发的时候，发现这个功能需要几个月完成，每天我都会写一点内容，下班后，我怕我写的内容丢失，这时我选择提交。

但是问题来了，我提交之后是不完整的代码，别人进行开发时，肯定导致项目不能完整运行，所以我不能选择提交，为了能够保留当前的进度，所以分支概念出现了。

为了不影响别人开发进度，同时保留自己的每天开发的进度，我可以创建一个分支 dev1，在这个分支 dev1 上，相当于一个独立的空间线。我想怎么玩就怎么玩，别人也看不到，也影响不到别人开发。

几个月后，我的功能全部开发完成了，然后我把我的分支合并到项目总分支上去，这样就完美得到解决。

分支操作

创建一个独立分支(dev)，命令如下：

git 中的进度是通过指针指向来控制的，虽然当前创建了一个新的分支，但是当前 HEAD 指针指向是 master 分支。

如果我们不知道当前指针指向哪个分支上，我们通过下边命令查看。

为了能够在自己分支上提交代码，所以我们要切换分支到 dev 上，命令如下：

然后我们开始提交代码，提交完后，我们再切回到原来的 master 主分支。

你会发现，你的文件内容是没改动之前的状态。因为我们所有的改动是在 dev 分支上改变的。

我们想要将 dev 改动合并到 master 分支上，必须执行以下合并的命令。

你会发现，当前的文件就是修改之后的状态。

合并完成之后，我们可以删除 dev 分支了，执行下边的命令。

解决冲突

虽然上边看起来操作行云流水，清晰易懂，但是在真正的开发项目中，会出现各种各样的情况。

比如代码合并冲突，遇到这种情况，尤其是刚接触 git 的同学，经常会措手不及，弄好了，很多就能够解决，弄不好，整个项目就麻烦了。

当时在合并项目的时候，我就入了这个坑，强制提交导致了同伴修改的功能全部丢失，所以合并冲突需谨慎。

什么情况下会导致合并冲突呢？

当我们两个人同时去修改一个文件，进行提交时，当前 git 不知道你两个人以谁修改的为主，就导致了冲突。

所以需要我们手动修改冲突之后，我们再进行提交。

我们可以通过 git status 命令查看发生冲突的文件。

我们打开文件，会提示我们两个不同分支提交内容，我么你通过手动修改，来选择其中一个分支内容，从而解决冲突，重新提交就 OK。

分支管理

通常我们用 master 分支来发布项目新的版本，所有的开发会创建一个 dev 分支来进行项目开发。

每个人都会创建自己的分支，每个功能完成之后，我们所有人先合并到 dev 分支上。

当测试完项目没有问题之后，我们再合并到 master 分支上，用于版本的迭代更新。

同步远程分支

这只是在本地进行分支操作，我们想把这些操作对应到远程分支上，需要进行关联，上一篇中，我们进行本地分支和远程分支关联的命令为：

git push -u origin master

-u 参数就是把本地 master 分支和远程的 master 分支进行关联起来，以后推送再进行推送至远程仓库，不用增加 -u 参数。

小结

Git 有非常多的玩法，剩下的就靠自己去探索。上边分享到了和之前分享的一篇在开发中足以够用。

扫盲 Git 算是完结了，具体的还是要在团队合作和项目开发中实践，一谈起 GIt，就想起自己的黑历史，今天到这了，如果觉得文章对你有帮助，欢迎在看转发，感谢各位小伙伴的厚爱！