1. 需求目的
软件开发在日常开发的过程中，分为个人开发和团队协作，无论是哪一个，代码总是不停的更新。
从个人的角度来说，在开发过程中，难免要修改代码或者更换框架等等。虽然可以在IDE中执行撤销操作，但是一直撤销显然不现实，最好是根据主观意愿时不时地备份一份代码，可以随时切换不同的备份，这就是版本控制。
从团队的角度来说，每个人都有自己的分工，并且可能会有分工交叉的地方，比如共同开发一个接口等等，这时候每个人都有自己单独的版本。比如A先开发了一个版本，并上传了，然后B下载该版本，并在此基础上继续开发自己的版本，然而同时A可能会继续更新自己的版本，这时由于B是在A原来的版本基础上开发的，此时成员之间的版本就会混乱，这方面也需要版本控制。
需要一个版本控制工具，既可以备份不同的版本，也可以管理不同版本之间的异同。主要有以下几个功能：
协同修改
即多人并行不悖的修改服务器端的同一个文件。即不同的人修改同一个文件的不同地方，提交后可以自动合并多个修改的地方。
数据备份
不仅保存目录和文件的当前状态，还能够保存每一个提交过的历史状态。即以便于后续在不同版本的基础上进行修改。
版本管理
在保存每一个版本的文件信息的时候要做到不保存重复数据，以节约存储空间，提高运行效率。这方面SVN采用的是增量式管理的方式（仅仅保存修改的地方，缩写详情见下面），而Git采取了文件系统快照的方式。因为在备份的时候，总会有重复的数据，那么此时如果每次都备份所有的内容的话，则会浪费很多空间，其实完全可以不用每次都全部保存，比如百度网盘，其实那种会员式的一键上传，有可能就是仅仅是计算了其哈希值，然后和自己数据库中的哈希值比较，如果有一样的，就说明其实已经备份了一份，如果用户下载的时候，直接指向那个已经备份的就好了。
权限控制
对团队中参与开发的人员进行权限控制；对团队外开发者贡献的代码进行审核（这是Git独有的）。即每个人在团队中的分工不一样，也就没必要有其他部分的权限，只拥有自己在自己分工内的权限即可。
历史记录
查看修改人、修改时间、修改内容、日志信息；将本地文件恢复到某一个历史状态。有了版本管理，自然就生成了历史记录，通过历史记录可以查看修改人等相关信息。并且能够把本地文件恢复到某一个历史状态。
分支管理
允许开发团队在工作过程中多条生产线同时推进任务，进一步提高效率。
2. 工具介绍
鉴于上述的需求，目前版本控制主要有集中式版本控制和分布式版本控制两种思路。
集中式版本控制
集中式指的是数据存储在一个服务器（远程库）中，整个系统就是相当于是集中式的，所有的用户都和服务器进行交互。和传统DNS类似，都存储在服务器中。集中式的缺点就是如果中央服务器坏了，那么所有的版本数据就都丢失了。代表工具是CVS、SVN、VSS等等。
分布式版本控制
分布式指的是可以在本地进行版本控制，也就是说本地上运行了一套机制，不需要和服务器进行连接，直接本地进行版本备份等操作，数据存储在本地。任何一个人都可以把自己的数据传给其他人，这样就避免了单点故障的缺点。（但是为了方便，一般还是要有远程库）。这个分布式有点像区块链DNS的机制。代表工具是Git、Mercurial、Bazaar等等。
3. Git介绍
3.1 Git历史
Git发展源于Linux系统版本控制。Linus开发Linux的时候，由于是开源的，很多人加入开发中，属于团队协作，最初由Linus本人手动合并代码。后来随着开源参与人员的增加，Linus逐渐应付不过来。之后BitMover公司授权Linux社区可以免费试用BitKeeper版本控制系统，但是社区人员试图破解该软件，被该公司发现，然后收回了免费试用权。2005年，Linus使用C语言开发了一个分布式版本控制系统：Git。2008年GitHub上线，称为一个知名的代码托管平台。Git官网和GitHub官网。
Git具有以下优势：
- 大部分操作在本地完成，不需要联网（因为有本地库）。
- 完整性保证（在拿到数据后，可以进行哈希操作得到哈希值，并与版本库中的哈希值进行对比，查看自己拿到的数据是否被别人篡改过/丢失）。
- 尽可能添加数据而不是删除或修改数据（即每次备份后，不会删除原来备份的数据）。
- 分支操作非常快捷流畅（以快照的方式进行管理）。
- 与Linux命令全面兼容。
3.2 Git安装
官网下载对应系统的安装包安装即可。
3.3 结构
Git本地结构，主要有三个区，分别是工作区、暂存区、本地库。工作区就是写代码的地方，代码文件存储在工作区。暂存区就是打算要提交的东西，但是还没有提交，将来可以提交到本地库，也可以把它撤回来，也就是临时存储的地方。本地库就是实实在在地存储每一个历史版本。总体来说，在工作区新建文件并写代码，然后用git add命令将其添加到暂存区，然后用git commit命令将其从暂存区提交到本地库。具体指令参考后续文章。
3.4 Git和GitHub
经常见到GitHub，其实GitHub只是Git的一种代码托管中心，相当于前面提到的远程库平台，就是一种具体的实现形式，一款落地产品。其实Git有很多种形式的代码托管中心，如下所示：
- 在局域网环境下，可以搭建GitLab服务器作为其代码托管中心。
- 在外网环境下，有GitHub、码云（Gitee）等作为代码托管中心。
前面已经介绍，前面已经有了本地库，那么这个代码托管中心有什么用呢？其实就是为了维护远程库。那么本地的本地库和代码托管中心的远程库是怎么交互的呢？本地库和远程库的交互方式主要分为团队内部协作和跨团队协作两种方式。
团队内部协作
团队开发，首先肯定要有本地库，为了将本地库推送到代码托管中心，需要在代码托管中心创建远程库。这个时候，如果需要将本地库的数据（文件、代码、历史记录等）推送到远程库，则需要一个
push操作。如果其他成员想要开发，则需要将远程库的数据下载到本地库，即需要一个clone的操作，clone其实不仅仅是下载数据，还会把本地库初始化。另外，如果不是远程库的团队成员，push操作不会成功，只有团队成员才有权限推送push。接着，如果某位成员push之后，其他成员可以pull拉取，即将远程库中的修改拉取到本地，从而达到协同开发的效果。跨团队协作
有时候，开发不仅仅是一个团队进行开发，可能是多个，也可能是找了外援。这个时候就不能像前面的那样做了，因为前面的都是一个团队内部的，有相关权限。
因此，如果有另两个团队A和B，各自有各自的远程库。如果B协同A开发，那么B可以
fork一份A的远程库，即复制一份，然后和上面一样，clone到本地进行开发，然后再push到远程库。注意，此时仅仅是修改的B自己的远程库。接着，可以发起一个pull request的请求，即请求A拉取自己的远程库；然后A对B的远程库进行审核，即审核所做的修改，如果没问题则进行一个在线合并的操作。这样，A的远程库就有了B所做的修改了。其实跨团队合作相比团队协作多了一个请求拉取和审查的操作。
4. Git操作
经过上述介绍，Git操作主要分为本地库操作和远程库操作。
- Git命令行操作
- 本地库操作
- 远程库操作
- Git图形化界面操作
5. 备注
参考教程，B站《尚硅谷》。
