浅尝GIT - 掘金

关键词

版本控制、分布式VS集中式、版本回退、工作区&暂存区、分支管理

GIT是啥？

git是分布式版本管理系统

什么是版本控制，为什么需要以git为代表的版本控制系统？

想必经历过毕业的人都有过写毕业论文的经历，一遍遍改论文，一遍遍折磨，一遍遍怀疑人生。。。 你写完初稿后，需要送交老师修改，你保存了一份毕业论文_初.doc。随后交由王老师修改，得到毕业论文_王.doc，再交给李老师毕业论文_李.doc，孙老师毕业论文_孙.doc，袁。。。

于是你的文件夹就变成了这样

参加答辩时，答辩老师指出你的正文缺少关键的实验数据，你记得有一位老师叫你加上过相关数据，但是你不记得是哪位老师了。怎么办呢？你只有一个文件一个文件的去找。

于是你就想，如果能有个系统能把各个版本的文件都整理起来，每次改动文件都记录下改动点和改动时间甚至是改动人等等，那该多好啊，巧了，git就是你想要的

分布式 VS 集中式

git是分布式版本管理系统的代表，而与之相对的集中式的代表是svn，他两最大的差异是什么呢？

借用廖雪峰老师的一句话： 分布式的核心是同步，集中式的核心是主从

• git

（ps：为了方便描述，简单地将本地版本和远端版本的维度的视作相等，实际上本地一个commit是一个版本，远端一个push即若干个commit是一个版本）

如图所示，每个人本地都有一份git版本库，远端（github、gitlab）还会有一份完整的版本库。

每个人在自己本地修改代码，add、commit只是在本地对改动做暂存、存储，push的时候才将改动上传到远端。所以每个人改了自己代码后，只需要push一次到远端，远端就结合你的改动生成了最新版本的代码。而其他人想要这个最新版本的代码，就pull从远端拉下来，并且他本地的git仓库也会存储他之前版本的代码，所以他本地是有历史版本和当前最新版本的代码的。

若是中央服务器突然崩溃，远端版本库全部丢失，其实完全可在本地的各个主机中找到完整或是最接近完整的版本库，再上传到全新的远端服务器即可。

所以 分布式的核心是同步

远端可同步本地，本地可同步远端，二者相辅相成，缺了一方可迅速重构另一方。

• svn

如图所示，每个人本地没有完整的版本库，本地只有从远端pull下来的当前最新版本代码。

每个人本地只有当前的开发版本，若是其他人修改了代码，推到远端生成了新版本，你从远端拉下最新版本，这会覆盖原有版本的代码。

虽然远端有完整的版本库，但是你本地没有对应的版本库，你想查看历史版本，就只能从远端去拉。

若是中央服务器突然崩溃，远端版本库全部丢失。本地都只有当前的开发版本，即使可以通过diff出本地改动，拿到远端最新版本代码，但是历史版本全部丢失，对项目也是极大地损害。

所以 集中式的核心是主从

远端可同步本地，本地不可同步远端，本地从属远端

版本回退

在本地版本库中，一次commit就会生成一个版本

git log 可查看commit记录（版本记录）

我们需要commit_id进行版本回退

进行版本回退可用两种命令： git reset commit_id、git revert commit_id

• git reset

上图是一个版本库，若想由版本D回到版本B，可使用命令git reset BBB1

git reset简单粗暴，回到版本B嘛，删掉他前面的版本C和版本D不就回到B了吗

这样做的确起了作用，但如果我们哪天想回到版本D咋办呢？删了还能回去吗？能，git reset虽粗暴，但可退可进。想要回到版本D的话，我们还是需要版本D的commit_id

此时需要git reflog命令去查找git命令的所有历史记录，查找可知版本D的commit_id是DDD1，git reset DDD1即可回到版本D。

使用git reset的关键就是需要知道版本的commit_id，若是不知道就回不去了。

• git revert

相比起git reset的简单粗暴，git revert要含蓄的多。

若是想回到版本C，则要使用git revert DDD1，代表需要回滚版本D，这可在不改变原有版本的前提下，生成一个最新的C’的版本，该版本和版本C代码相同，只是commit_id不同，是一个复制品。

且若想回到版本D，则git revert CCC2，则可生成代码和D相同的版本D‘，这样做的好处是保留了原始版本，相当于保留了完整的操作记录，可方便复盘、回退

工作区 && 暂存区

(待续)

分支管理

(待续)