git基础及工作原理

目录

前言

1. git是什么

2. 集中式版本控制与分布式版本控制

2.1 集中式版本控制

2.2 分布式版本控制

3. git基本原理

3.1 工作区

3.2 暂存区

3.3 仓库区

3.3.1 本地仓库

3.3.2 远程仓库

3.4 状态管理

3.4.1 已修改

3.4.2 已暂存

3.4.3 已提交

3.5 总结

---

前言

        好好写代码，好好的反思踩过的坑，然后尽量不要给别人挖坑。这是我对自己，以及每个刚入行或即将的小伙伴的建议。一个软件工程项目，是一个系统性极强且较为复杂的工作，会有很多人参与到这个工作中来，如何高效管理这么多人的提交的代码，就显得特别重要了。这就用到了版本控制管理系统。无论代码或其他文件是来自一个人，还是一个团队，忠实记录每一次的变更，还能在必要时候帮助还原任何一次历史变更，以及可以支持团队协作。而git就是版本控制管理系统中最好用的工具之一，对于每个前端或后端的程序员来说，使用git正确的提交代码、拉取代码、处理冲突、回滚代码、切换分支就成了必会的技能。

        git是一个版本控制工具，既然是工具，如何使用正确工具，提高工作效率，才是作用普通使用者更关心的内容。因此这个专栏里是实战性比较强的内容，不会长篇地分析git的原理，以及这样的设计是如何的优秀，只会重点介绍git正确使用方法以及为什么要这样用，而本篇的重点先大概认识一下git。

1. git是什么

        刚才已经提到了，git是一个版本控制工具，当然版本控制工具有很多，如SVN，但是Git是最流行，并且最好用的之一。关于git的诞生，还有一些小故事，感兴趣的小伙伴可以自行百度检索。我们需要知道的是，git是用C语言编写，是开源的分布式版本控制管理工具。大名鼎鼎的github就是用git来管理他们的网站上的代码的。这里需要特别强调一下，git和github是两个东西，git是版本控制系统或工具，github是一个社区网站，在这个社区网站上可以上传、下载自己或团队代码，但是因为其服务区在国外，所以网速会比较慢。那么国内有没有类似的网站？当然也有，比较有影响力就是gitee了。这里要特别警告一下新入行的小伙:不要把公司的代码或文档上传到github或gitee上！这是极其危险的行为。

2. 集中式版本控制与分布式版本控制

        主流的版本控制工具可以分为两类：集中式版本控制和分布式版本控制，两类的代表工具分别是svn和git。下面就两种方式作一些简单介绍。

2.1 集中式版本控制

        集中式版本控制就是把代码放在一个服务器上集中管理，每次你需要写代码的时候需要从服务器上拉取一份，写完代码后再提交到服务器，你的本地实际上相当于一个客户端。

        这种模式我认为有两个缺点：

第一、如果服务端与客户端不在一个局域网内，客户端的代码没有办法提交到服务端仓库；

第二、新建分支的时候，是把原分支的文件另外复制一份作为新分支，版本不断迭代，分支越来越多，就会造成版本库的体积越来越大。

2.2 分布式版本控制

        分布式版本控制系统理论上来说没有所谓的“服务端”,每个人的电脑本身即是服务端，也是客户端，并且都有一个完整的版本库，任意两台电脑都可以相互交换文件。不过这样在实际使用过程中不太方便，所以通常会有一台单独的主机充当服务端，用来方便每个人交换修改的内容。平时每个人的本地作为客户端可以正常的向服务端提交或拉取代码，当服务端故障不可用的时候，可以把任务一个客户端提升为为服务端，其他的客户端的远程仓库地址更新为新的服务端即可。

        我认为分布式版本控制解决了集中式版本控制的缺点：

第一、如果因为网络原因服务端与客户端连接不通或者暂时不想提交代码而又担心代码可能会丢失的时候，可以先把代码提交到本地仓库，待网络恢复或想提交的时候，再推送至远程仓库；

第二、每次的代码提交操作，都会生成一个版本号并记录与上一次提交相比的变更内容，切换分支也是一样，版本库实际只有一份代码，每一次的操作，对应的是一个版本号，一份变更内容记录，版本库会保存这些历史记录。

3. git基本原理

        通常情况下，对于新手来说，会使用git提交代码、拉取代码基本上就可以了，创建分支、合并代码、处理冲突这些高阶的技能有更专业的人来做，菜鸟们没什么好担心的。但是谁又愿意承认自己永远是只菜鸟呢？本着能靠自己，为什么要靠别人的原则，显然满足不了那些自我要求成长者的胃口。所以熟练掌握了常用提交代码、拉取代码这些技能之后，就需要掌握一下关于git的几个比较核心的概念。因为这几个概念很简单，也很重要，后面的代码合并、冲突处理、回滚、回退都与这几个概念有关。

3.1 工作区

        平时写代码的地方，所有代码的添加、删除、修改操作都发生在工作区中。

3.2 暂存区

        在工作区完成文件的添加、删除、修改操作后，通过add命令添加临时存储区域，等待被提交，这个区域就是摆在区。

3.3 仓库区

        仓库区是存储正式代码的地方，根据物理位置不同，分为本地仓库和远程仓库中。

3.3.1 本地仓库

        所谓本地仓库，就是工作区的代码通过commit命令后，文件就被存储在仓库区的本地仓库了。

3.3.2 远程仓库

        远程仓库是相对于本地仓库而言，可以理解为本地仓库的服务端，被commit到本地仓库的文件通过push命令推送到远程仓库。

3.4 状态管理

        在文件操作的过程中，文件的状态也会在不同的阶段呈现出不同的状态，总体上分为两种状态：受控状态和未受控状态，受控状态可以再细分为已修改、已暂存、已提交。

3.4.1 已修改

        修改了受控状态的文件，但是修改的结果还未添加到暂存区。

3.4.2 已暂存

        修改后的文件，被添加到了暂存区，等待被提交。

3.4.3 已提交

        文件已经被提交到了本地仓库。

3.5 总结

        所谓的工作区、暂存区、本地仓库的本质是根据文件的不同状态而进行的一个逻辑区分，实际指的是本地磁盘的同一个物理工作目录。最开始新增一个文件，文件本身未受到版本控制管理时，处于未受控状态，所在的地方称之为工作区，执行add命令后，文件纳入版本控制管理，处于已暂存状态，被存储在暂存区，再次执行commit命令后，文件处于已提交状态，文件被存储到仓库区的本地仓库，最后执行push命令本地仓库的内容会被推送到远程仓库。如果远程仓库有其他人提交的内容，可以通过pull命令拉取到本地。