git版本控制 - 技术栈

一、版本控制

1.版本控制在实际开发中应用

如果你用Microsoft Word写过长篇大论，那你一定有这样的经历：想删除一个段落，又怕将来想恢复找不回来怎么办？有办法，先把当前文件"另存为......"一个新的Word文件，再接着改，改到一定程度，再"另存为......"一个新文件，这样一直改下去，最后你的Word文档变成了这样：

问题产生：

过了一段时间，你想找回被删除的文字，但是已经记不清删除前保存在哪个文件里了，只好一个一个文件去找，就会觉得很麻烦。看着这样一大堆乱七八糟的文件，想保留最新的一个，然后把其他的删掉，又怕哪天会用上，还不敢删。于是你就会想，如果有一个软件，不但能自动帮我记录每次文件的改动（类似于腾讯的TIM在线文档编辑），这样就不用自己管理一堆类似的文件了。如果想查看某次改动，只需要在软件里瞄一眼就可以，这样是不是很方便？这样，就结束了手动管理多个"版本"的史前时代，进入到版本控制时代。

2.版本控制分类

集中式版本控制系统

集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要看一本书，必须先从图书馆借出来，然后回家自己看，看完了，再放回图书馆。集中式版本控制系统最大的缺点就是必须联网才能工作，如果在局域网内还好。

分布式版本控制系统（已经成为主流）

分布式版本控制系统根本没有"中央服务器"，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

与集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。

两种版本系统对比

|------------|---------------------------------------------------------------|-----------------------------------------------------------------------------|
| 区别 | 集中式（SVN） | 分布式（Git） |
| 1.是否有中央服务器 | 有。开发人员需要从中央服务器获得最新版本的项目然后在本地开发，开发完推送给中央服务器。因此脱离服务器开发者是几乎无法工作的 | 没有中央服务器，开发人员本地都有 Local Repository |
| 2.网络依赖 | 必须要联网才能工作，而且对网络的依赖性较强，如果推送的文件比较大而且网络状况欠佳，则提交文件的速度会受到很大的限制。 | 分布式在没有网络的情况下也可以执行commit、查看版本提交记录、以及分支操作，在有网络的情况下执行 push 到 Remote Repository |
| 3.文件存储格式 | 按照原始文件存储，体积较大 | 按照元数据方式存储，体积很小 |
| 4.是否有版本号 | 有 | 没有 |
| 5.分支操作的影响 | 创建新的分支则所有的人都会拥有和你一样的分支 | 分支操作不会影响其他开发人员 |
| 6.提交 | 提交的文件会直接记录到中央版本库 | 提交是本地操作，需要执行push操作才会到主要版本库 |

二、Git环境安装及入门操作

1.安装Git、Git小乌龟

Git以及Git客户端安装包（一直点击执行安装，不需要任何设置填写）

2.Git入门操作

- 目标：把本地test文件夹下文件纳入版本管理

- 初始化本地仓库：说白了就是创建一个本地仓库用于版本管理

- 添加要纳入版本管理的文件：itheima.txt文件

- 最后还需要真正提交一次记录提交文件内容

- 多次修改文件的版本提交都会记录下来

3.Git操作远程服务器

思考：A同学itheima.txt文件可以纳入版本管理，B同学也需要对itheima.txt进行编写，该如何办呢？

如果A同学itheima.txt文件提交到远程服务器，B同学可以从该远程服务器下载下来使用继续编写提交。

远程服务器

- 国内

码云

- 国外

github

- 公司内部

将本地代码提交到gitee国内远程服务器

- 注册gitee账号Gitee - 基于 Git 的代码托管和研发协作平台

- 创建远程服务器仓库

- 把本地仓库代码(纳入版本管理的代码，例如：test文件夹)推送到远程服务器仓库中

- 从远程仓库中克隆到本地仓库

- 从远程仓库中拉取最新版本到本地仓库

三、Git几张重要的图

1.Git重要概念

.git文件夹：文件夹下存在.git，说明该文件纳入版本控制

- 工作区： 就是你在电脑里能看到的目录。例如：test文件夹
- **暂存区：**英文叫stage, 或index。一般存放在 ".git目录下" 下的index文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。
- **版本库：**工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

git工作原理

- 图中左侧为工作区，右侧为版本库。在版本库中标记为 "index" 的区域是暂存区（stage, index），标记为 "master" 的是 master 分支所代表的目录树。
- 图中我们可以看出此时 "HEAD"实际是指向master 分支的一个"游标"。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。
- 图中的 objects 标识的区域为 Git 的对象库，实际位于".git/objects" 目录下，里面包含了创建的各种对象及内容。
- 当对工作区修改（或新增）的文件执行 "git add" 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。
- 当执行提交操作（git commit ）时，暂存区的目录树写到**版本库（对象库）**中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。
- 当执行"git reset HEAD"命令时暂存区的目录树会被重写，被master分支指向的目录树所替换，但是工作区不受影响。
- 当执行 "git rm --cached <file>" 命令时，会直接从暂存区删除文件，工作区则不做出改变。
- 当执行 "git checkout" 或者 "git checkout -- <file>" 命令时，会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险，会清除工作区中未添加到暂存区的改动。
- 当执行 "git checkout HEAD " 或者 "git checkout HEAD <file>" 命令时，会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。