git的学习

1.  Git是什么？

　　Git是目前世界上最先进的分布式版本控制系统（没有之一）

　　如果你用Microsoft Word写过长篇大论，那你一定有这样的经历

　　想删除一个段落，又怕将来想恢复找不回来怎么办？有办法，先把当前文件“另存为……”一个新的Word文件，再接着改，改到一定程度，再“另存为……”一个新文件，这样一直改下去，最后你的Word文档变成了这样：　　

　　　　　　　　

 

　　过了一周，你想找回被删除的文字，但是已经记不清删除前保存在哪个文件里了，只好一个一个文件去找，真麻烦；

　　看着一堆乱七八糟的文件，想保留最新的一个，然后把其他的删掉，又怕哪天会用上，还不敢删，真郁闷。

　　更要命的是，有些部分需要你的财务同事帮助填写，于是你把文件Copy到U盘里给她（也可能通过Email发送一份给她），然后，你继续修改Word文件。一天后，同事再把Word文件传给你，此时，你必须想想，发给她之后到你收到她的文件期间，你作了哪些改动，得把你的改动和她的部分合并，真困难。

　　于是你想，如果有一个软件，不但能自动帮我记录每次文件的改动，还可以让同事协作编辑，这样就不用自己管理一堆类似的文件了，也不需要把文件传来传去。如果想查看某次改动，只需要在软件里瞄一眼就可以，岂不是很方便？

这个软件用起来就应该像这个样子，能记录每次文件的改动：

 

 

2.  版本管理工具的种类及特点

　　a：集中式的版本控制系统：例如svn，cvs

　　b：分布式版本控制系统：git

　　区别：

　　　　先说集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给　　　　中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。

　　

 

　　　　集中式版本控制系统最大的毛病就是必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，可能提交一个10M的文件就需要5分钟，这还不得把人给憋死啊。

 

　　　　分布式版本系统：

　　　　

 

 

 

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

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

　　　　在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。

3，git的安装

　　　　官网地址：https://git-scm.com/

4，创建版本库

　　　　什么是版本库呢？版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

　　　　

 

　　　　瞬间Git就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），细心的读者可以发现当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。

 

 5，把文件添加到版本库　

　　　　首先这里再明确一下，所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。

　　　　不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，前面我们举的例子只是为了演示，如果要真正使用版本控制系统，就要以纯文本方式编写文件。

　　　　因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。

言归正传，现在我们编写一个readme.txt文件，内容如下：

　　　　

 

把一个文件放到Git仓库只需要两步：

　　第一步: 用命令git add告诉Git，把文件添加到仓库;

　　

 

 　　第二步，用命令git commit告诉Git，把文件提交到仓库;

　　

　　 

 　　

 

 　　修改文件之后，运行git status命令看看结果：

 　　

 

 　　git status命令可以让我们时刻掌握仓库当前的状态，上面的命令输出告诉我们，readme.txt被修改过了，但还没有准备提交的修改

　　虽然Git告诉我们readme.txt被修改了，但如果能看看具体修改了什么内容，自然是很好的。比如你休假两周从国外回来，第一天上班时，已经记不清上次怎么修改的readme.txt，所以，需要用git diff这个命令看看：

　　

 

 　　git diff顾名思义就是查看difference，显示的格式正是Unix通用的diff格式，可以从上面的命令输出看到，知道了对readme.txt作了什么修改后，再把它提交到仓库就放心多了，提交修改和提交新文件是一样的两步，第一步是git add

　　同样没有任何输出。在执行第二步git commit之前，我们再运行git status看看当前仓库的状态：

　　

 

 　　git status告诉我们，将要被提交的修改包括readme.txt，下一步，就可以放心地提交了：

　　

 

 　　提交后，我们再用git status命令看看仓库的当前状态：

　　

 

 　　Git告诉我们当前没有需要提交的修改，而且，工作目录是干净（working tree clean）的

 4，版本回退

　　我们回顾一下readme.txt文件一共有几个版本被提交到Git仓库里了：

　　git log命令显示从最近到最远的提交日志，我们可以看到3次提交，分别为，最近一次，上一次，最早的一次

　　如果嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数：

　　

 

 　　你看到的一大串类似1094adb...的是commit id（版本号），是一个SHA1计算出来的一个非常大的数字，用十六进制表示，而且你看到的commit id和我的肯定不一样，以你自己的为准。

　　在我们启动时光穿梭机，准备把readme.txt回退到上一个版本

　　首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交1094adb...（注意我的提交ID和你的肯定不一样），上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

　　可以使用git reset命令对版本进行回退（回退上一个版本）

　　

 

 　　用git log再看看现在版本库的状态，发现刚才的那个版本已经不见了，如果想要再回到刚才的那个版本怎么办呢？

　　办法其实还是有的，只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个third submit的commit id是，于是就可以指定回到未来的某个版本：

　　

 

 　　版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。

解析：

　　Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向third submit：

　　

 

 　　然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。

　　现在，你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？

　　Git提供了一个命令git reflog用来记录你的每一次命令：

　　

 　　有了以上的id就可以回退任意版本

5，工作区和暂存区

　　工作区（Working Directory）

　　　　就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区：

　　　　

 

 

 　　版本库（Repository）：

　　　　工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

　　　　Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

　　　　

　　　　前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：

　　　　第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；

　　　　第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

　　　　因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。

　　　　你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

　　　　

 

 

 　　　　Git非常清楚地告诉我们，readme.txt被修改了，而add.txt还从来没有被添加过，所以它的状态是Untracked。

　　　　现在，使用两次命令git add，把readme.txt和add.txt都添加后，用git status再查看一下：

　　　　

 

　　　　

 

 

 　　　　所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。

　　　　

 

　　　　一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的：

　　　　

 

 　　　　

　　　　现在版本库变成了这样，暂存区就没有任何内容了：

　　　　

 

 

 容易迷惑的地方

　　　　第一次修改 -> git add -> 第二次修改 -> git commit

　　　　你看，我们前面讲了，Git管理的是修改，当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次　　　　的修改不会被提交。

修改的内容不想要了

　　　　命令git restore -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：

 　　　　一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

　　　　一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

　　　　总之，就是让这个文件回到最近一次git commit或git add时的状态。

增加到暂存区后要进行复原操作

　　　　

 

 　　 Git同样告诉我们，用命令git restore --staged <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区

　　　　

 

 　　　再通过git restore <file> 将添加的内容移除掉

文件的删除（也可以理解为文件的修改）　　

　　　　

 

　　　　如果添加了add.html 文件；

 　　　　

 

 　　　　之后我们将add.html删除

　　　　

 

 　　　　

 

 　　　　现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit：

　　　　

 

 　　　　文件就真的删除了

　　　　另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

　　　　

 

 　　　　文件又回来了

6，远程仓库

　　　　Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。

　　　　实际情况往往是这样，找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。

　　　　在继续阅读后续内容前，请自行注册GitHub账号。由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：

　　　　　　第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：

　　　　　　　　　你需要把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。

　　　　　　　　    如果一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。

　　　　　　第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面：

　　　　为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。

　　　　当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。

　　　　最后友情提示，在GitHub上免费托管的Git仓库，任何人都可以看到喔（但只有你自己才能改）。所以，不要把敏感信息放进去。

　　　　如果你不想让别人看到Git库，有两个办法，一个是交点保护费，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）。另一个办法是自己动手，搭一个Git服务器，因为是你自己的Git服务器，所以别人也是看不见的。

　　　　公司内部开发必备。