Git 后续——分支与协作
本文写于 2020 年 9 月 1 日
之前一篇文章写了 Git 的基础用法，但那其实只是「单机模式」，Git 之所以在今天被如此广泛的运用，是脱不开分支系统这一概念的。
最近几天在滴滴实习，第一次接触到了团队是如何利用 Git 进行协作的。可以说分支系统对于协作来说是重要的一环，接下来就让我们来一窥究竟吧。
什么是分支
首先，什么是分支？
我们之前说了，Git 会记录你的文件修改。你修改了哪一行哪一个字符，只要你进行了 commit 操作，Git 都会帮你记录的清清楚楚。
而这一系列的 commit 提交是有先后的。所以根据时间，我们可以排出一个时间轴。
--> 第一次提交 --> 第二次提交 --> 第三次提交 --> ... --> 第 n 次提交
这就是主分支 master。如果你是在命令行里打开存在 git 的目录就会发现，在文件目录的最后显示了一个 master。
为什么需要分支
这个时候我们的开发团队突然不是一个人了，有另一个同学加入了项目，你需要和他进行协同开发。
我们现在面临的是两个需求，A 和 B。你负责 A，他负责 B。
但是有一个问题，他的 B 需求比较好解决，只需要 1 天就可以完成，可你的 A 需求则需要 5 天时间。
如果你们俩同时在 master 分支上进行合作就会出现问题。
比如说你的 A 需求是可以拆分成 3-5 个小块进行 commit 的。（请保证您的每个 commit 不会进行太多的修改，这样便于项目管理与后续查看）那么当你 commit 之后，他面对的将会是你的 A 需求的某一个或者某几个小块的更新，即他的代码会变成不完整的代码。
具体点来说，你的需求需要 5 天才能完成，第一天你写了 20% 的代码，如果立刻 commit，由于代码还没写完，不完整的代码库会导致另外一个人不能干活。
还有一点就是代码丢失的风险，如果等你的代码全部写完再一次提交，会存在丢失每天进度的巨大风险！
这个时候就该分支出场了。
如何使用分支
分支就是「平行宇宙」。当你此刻使用 git checkout -b my-first-branch 就会创建一条名为 my-first-branch 的分支，并且切换过去。
这个分支可以用于记录你这段时间的 commit。
--> 第一次提交 -------> 第二次提交 ----> 第三次提交 --> ... --> 第 n 次提交
↓
分支my-first-branch ----> 分支的第三次提交 ----> 分支的第四次提交
当你完成之后，分支即可通过 git merge <branch-name> 和其他分支进行合并，这样所有在该分支上的操作就会被合并到另一个分支上了。
这这个分支是属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样一来既安全、又不影响别人工作。
处理合并冲突
如果你在 readme.txt 中修改了一行，另一个人也修改了 readme.txt 中的同一行。
这个时候你们合并文件会出现问题吗？
肯定会呀！Git 会告诉你：
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
为了英文不太好的同学，我来翻译一下：readme.txt 文件存在冲突，必须手动解决冲突后再提交。
我们该怎么查看这个冲突呢？不错，就是 git status，顾名思义嘛，各种状态都可以由他查看。
除此之外，我们还可以直接看文件，Git 已经帮我们放了点东西上去：
<<<<<<< HEAD
明月几时有，把酒问青天
=======
明月都没有，喝酒不问天
>>>>>>> my-first-branch
Git 会告诉我们几条分支分别在这一句上改了什么，让我们自行判断，自行删除。
我们分别删掉半句，变成这个样子后：明月几时有，喝酒不问天。再进行 git commit -m 'merge conflict'，就可以了。
这就是分布式管理系统的好处。
（完）