day18学习总结

一、两种类型的版本控制工具

1. 集中式版本控制工具：Svn

2. 分布式版本控制工具：Git

二、远程仓库

1. GitHub

2. Gitee

三、Git诞生记

Git 诞生于 2005 年 4 月，由 Linux 的作者 Linus Torvalds 花费了两周的时间用 C 写了一个分布式版本控制系统，这就是 Git1.0 ，大牛写代码就是这么 666666 。其实早在 Git 之前，这个世界就已经有一些非常流行的版本控制工具（VCS），比如 CVS ，SVN， ClearCase 等，然而这些工具要么运行慢，要么要收费，都不是 Linus Torvalds 的菜。当时，有一个公司叫做 BitMover ，该公司有一款产品叫做 BitKeeper ，这是一个分布式版本控制工具，但是这是收费的，不过这是一个有情怀的公司，老板 Larry 说服 Linus Torvalds 使用 BitKeeper 来管理 Linux 内核源码，于是，在 2002 到 2005 年之间，Linux 内核开发团队一直使用 BitKeeper 来管理 Linux 源码。可是在开发的过程中， Linus Torvalds 有一个叫做安德鲁·垂鸠的小伙伴不安分了，他写了一个简单程序，可以连接 BitKeeper 的存储库，BitKeeper 著作权拥有者拉里·麦沃伊认为安德鲁·垂鸠对 BitKeeper 内部使用的协议进行逆向工程，决定收回无偿使用 BitKeeper 的授权。合作无法继续，于是 Linus Torvalds 决定自己开发一套分布式版本控制工具，就是 Git ，至于这个分布式版本控制工具为什么叫 Git，Linus Torvalds 并没有给出一个让所有人满意的解释，倒是很多开发者一直尝试去给 Git 一个合理的解释，常见的一个解释就是 Global Information Tracker （中文译作全局信息追踪器）。如果当年不是 BitMover 公司的逼迫，估计我们还不一定见到这么优秀的分布式版本控制工具。值得一说的是， 2016 年 5 月 11 日 BitKeeper 宣布以 Apache 2.0 许可证开源（新闻链接 http://www.solidot. org/story?sid=48171），我很好奇 BitKeeper 宣布开源的时候他的老板心中是何感受？

四、Git优势

Git 一出世立马就成为最流行的分布式版本控制工具，2008 年 4 月，GitHub 正式上线，GitHub 是一个利用 Git 进行版本控制，专门用于存放代码与内容的共享虚拟主机服务，GitHub 上线之后，许多开源项目都移植到 GitHub 上了，不管你从事那门语言的研发，都会在 GitHub 上找到你需要的项目吧！ OK，说了这么多，接下来我们也该说说 Git 这个分布式版本控制工具的优势了。Git 主要有以下几个优势： 1. 与传统的集中式版本控制工具不同，分布式版本控制工具不需要联网就可以工作，每台电脑都是一个完整的版本仓库。 2. Git 可以胜任上万人的开发规模，这个大家看看 GitHub 中的开源项目就知道了，不需要我多说。 3. 性能优异。我们前面说过 Linus Torvalds 之所以不愿意使用 CVS、SVN 等版本控制工具就是因为这些工具的性能太差。所以 Linus Torvalds 在开发 Git 时就决定要革除积弊，确保 Git 的运行效率。笔者在上家公司做开发时，深受 SVN 的毒害，但是公司还是不愿意迁移到 Git 上，我猜测是由于项目经理不会用。 4. 保证项目的安全。我们知道，在 SVN 之前还有一个集中式版本控制工具叫做 CVS ，这个 CVS 有一个问题，就是你的文件有的时候会莫名其妙的丢失，做开发的各位筒子都知道，如果你的项目中突然有一个文件不见了，你不出一身汗才怪。所以，Git 使用 SHA1 这种通用的加密散列函数来对数据库中的对象进行命名，从而来确保文件的安全。 5. 好用的分支。用过 Git 的人都知道 Git 中的分支用起来有多么爽，分支在我们的项目中用的非常普遍，可是 SVN 虽然也有分支，但是却不能像 Git 用的这么爽。这个做过项目的筒子都知道。我们到后文会给大家详细介绍分支的用法。 OK，Git 的优势还有很多种，这里我就不再一一列举了，有兴趣的大家自行搜索。

五、Git安装

step01

step03

step05

step07：

step09

step11

step13

打开git命令窗口输入：

git --version

验证是否安装成功

六、基本配置

不管是 Windows 安装还是 Linux 安装，安装好之后，我们都先通过如下两行命令做一个基本配置,配置的信息将展示在我们每一次提交的后面，所以不要使用不方便公开的信息，如果不配置以后每次提交的时候都会让你输入用户名和密码，配置方式如下：

$ git config --global user.name "用户名"

$ git config --global user.email "邮箱"

然后会生成如下配置文件：

七、工作区

1. 工作区很好理解，就是我们能看到的工作目录，就是本地的文件夹。

2. 这些本地的文件夹我们要通过 git add 命令先将他们添加到暂存区中。

3. git commit 命令则可以将暂存区中的文件提交到本地仓库中去。

八、初始化仓库

简介：

仓库的初始化有两种方式：

A.一种是直接从远程仓库克隆

B.另一种则是直接从当前目录初始化

初始化仓库指令：

$ git init

九、查看状态

我们可以通过 git status 命令来查看仓库中文件的状态，比如，在我们仓库刚刚初始化完成之后，我们执行 git status 命令，执行效果如下：

执行结果首先展示了我们当前处于 master 分支下，然后又说暂时没有东西可以提交，因为当前仓库中还没有记录任何文件的任何状态。此时，我在当前目录下创建一个名为 git01.txt 的文件，然后再执行 git status 命令，如下：

十、添加文件到暂存区

git add 命令可以将一个文件添加到暂存区，我们现在已经有一个 git01.txt 文件了，接下来，执行如下命令将文件添加到暂存区中：

git add admin.txt

十一、提交到本地仓库

当文件提交到暂存区之后，此时我们可以通过 git commit 命令将当前暂存区的文件提交到本地仓

git commit - m "备注"

十二、查看日志

查看日志（全面）：

git log

查看日志（简单）:

git log --pretty=short

查看某个具体的日志

git log 文件名.文件类型

查看提交时文件的变化

git log -p 文件名.文件类型

注意点:

但是 git log 有一个局限性，就是不能查看已经删除的 commit 的日志，举个例子：下班了，我发现今天下午提交的代码全都是有问题的，于是做了一个版本回退，回退到今天早上的状态，然后关机回家，第二天来了后我发现搞错了，其实那些代码都是 OK 的，于是我又想让仓库版本前进到昨天下午的状态，却发现 git log 命令查看不到昨天下午提交的版本号。此时，我们可以使用 git reflog 命令来实现这一个请求， git reflog 命令可以显示整个本地仓库的 commit , 包括所有 branch 的 commit , 甚至包括已经撤销的 commit , 只要 HEAD 发生了变化, 就会在 reflog 里面看得到，而 git log 只显示当前分支的 commit ，并且不显示删除掉的 commi

十三、查看更改前后差异

使用 git diff 命令我们可以查看工作区和暂存区的区别以及工作区和最新提交的差别。我往 admin.txt 文件中再添加一行 hello world ，此时执行 git diff 命令，

此时这里显示我们新增了一行。此时我们执行 git add 命令，将文件提交到暂存区，然后再执行 git diff

此时没有任何信息输出，因此此时工作区的内容和暂存区的内容已经保持一致了。但是此时工作区和本地仓库中最新提交的内容还是不一致，我们可以通过 git diff HEAD 命令来查看，如下：

十四、撤销代码

工作区的代码想撤销：

可能有一天我正在写代码，写了很久发现写错了，想恢复到一开始的状态，一个笨办法就是把刚刚写的代码一行一行的删除，不过这种方式成本太高，我们可以通过 git checkout -- 命令来撤销工作区的代码修改

add 到暂存区的代码想撤销：

1.将暂存区的代码撤销到工作区 ===>指令 git reset head

2.将工作区的代码撤销(具体操作和'工作区的代码想撤销'一致)

提交到本地仓库的代码想撤销：

查看日志：

通过 git reset --hard HEAD^^ 向前回退两个版本：

通过版本号来进行回退 695ce1fe：

通过 git reset --hard HEAD~1 回到上一个版本：

十五、分支

分支的必要性：

小伙伴们都知道，我们在完成一个项目时，不可能是“单线程”开发的，很多时候任务是并行的，举个栗子：项目 2.0 版本上线了，现在要着手开发 3.0 版本，同时 2.0 版本可能还有一些 bug 需要修复，这些 bug 修复之后我们可能还会发 2.1，2.2，2.3 这些版本，我们不可能等所有 bug 都修复完了再去开发 3.0 版本，修复 2.0 的 bug 和开发 3.0 的新功能是两个并行的任务，这个时候我们 3.0 的功能开发直接在 master 分支上进行肯定不合适，我们要保证有一个稳定，可以随时发版本的分支存在（一般情况下这个角色由 master 分支来扮演），此时我们就可以灵活的使用 Git 中的分支管理功能：

查看分支：

git branch

创建分支：

git branch 分支名创建分支

git checkout 分支名切换到该分支

git checkout -b 分支名创建分支并切换到该分支

分支合并：

git merge --no-ff 分支名

如果是合并到主分支中，需要切换到主分支进行合并

解决冲突：

不过大多数情况下我们都是要解决冲突的，解决之后继续提交。此时我们用编辑器打开冲突的文件，看到的内容可能是这样的：

删除错误的符号重新进行提交

十六、配置 SSH KEY

简介：

SSH KEY 的配置不是必须的，不配置的话我们就只能使用 HTTPS 协议，这样每次提交时要输入用户名密码，略麻烦，所以还是配置一下。配置 SSH KEY 的原理很简单，采用非对称加密方式生成公钥和私钥，公钥告诉 GitHub ，私钥留在自己电脑上(私钥不可泄露)，当我们向 GitHub 上提交数据时， GitHub 会用我们留给它的公钥加密一段消息返回给我们的电脑，如果我们能够用私钥解密成功，说明是合法的用户，这样就避免我们输入用户名密码了。大致的原理就是这样，现在很多免登录的系统都采用了这种方式，比如 Hadoop 免登录配置也是这样。那我们就来看看这个 SSH KEY 要怎么生成。