Marco's Java【Git入门(一) 之 Git简介及文件管理(上)】

前言

什么是Git？相信大家或多或少会听说过版本库，在还没有分布式概念的时候，程序猿们使用的最广泛的就是SVN集中式版本控制中心。

SVN是subversion的缩写，是一个开放源代码的版本控制系统，通过采用分支管理系统的高效管理，简而言之就是用于多个人共同开发同一个项目，实现共享资源，实现最终集中式的管理

但是SVN有个很明显的缺陷就是它离不开网络，也就是说如果离开了网络的话，各个PC端的Java项目就不能实现代码的同步，因此Git就诞生了！巧的是，Git的创始人也就是Linux的创始人Linus Torvalds！
所以本节就带大家初步认识一下Git，入个门儿啦。

Git的诞生

相信用过Linux操作系统的大多数人都知道，Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。

Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？

事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码！

你也许会想，为什么Linus不把Linux代码放到版本控制系统里呢？不是有CVS、SVN这些免费的版本控制系统吗？因为Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。

不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，毕竟这种方式处理的效率极低，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。

安定团结的大好局面在2005年就被打破了，原因是Linux社区牛人聚集，不免沾染了一些梁山好汉的江湖气息，这一点可能随它们的老板… 开发Samba的Andrew试图破解BitKeeper的协议（这么干的其实也不只他一个），结果被BitMover带了个正着！于是BitMover公司怒了，要收回Linux社区的免费使用权。

Linus表面上向BitMover公司道个歉，保证以后严格管教弟兄们，不再犯错。但是以李纳斯的性格，你觉得可能吗？毕竟是diss天，diss地，diss到你老母都不认识你的牛人…

于是这位兄弟花了两周时间用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！(PS:膜拜！！！！)

Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。

其实我们也得感谢BitMover，如果不是当年BitMover公司威胁Linux社区，可能现在我们就没有免费而超级好用的Git了。所以这个故事也告诉我们，不逼自己一把，根本不知道自己的能力有多强！(PS:一波鸡汤送给各位）

---

Git下载安装

以上带大家简单的认识了一下Git，接下来咱们下载Git实操一下吧！
给大家提供一下Git的下载地址 Git Download

安装相当简单，一路next就可以了，没有难度… 偷个懒，我就不放图啦，唯一需要注意的就是安装完成之后设置自己的名字和邮箱，在Git的最后阶段学习我们会用到。

$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"

---

Git仓库初始化

第一步：创建git仓库目录
首先在D盘下创建D:/git/repository目录，接下来我们要把这个目录变成一个版本库

第二步：初始化git仓库
执行仓库的初始化命令，只需要git init指令即可完成初始化，非常简单对吧！细心的朋友会发现，下面多了一行文字Initialized empty Git repository in D:/git/repository/.git/，告诉你这是一个空的仓库（empty Git repository）

顺着我们创建目录的路径，我们可以找到一个.git文件，这个目录是Git用来跟踪管理版本库的，因此闲着没事千万不要手动修改个个目录里面的文件(改乱了会破坏Git仓库)，不然你懂的！(千万不要删库跑路啊… )

当然如果你没有看到.git目录，原因是此目录默认隐藏，使用Linux命令ls -ah就可以看到隐藏文件！

---

Git添加文件

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

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

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

好啦，说了这么多，我们来尝试在仓库中添加一个txt文件，输入以下内容（PS:我个人很喜欢 Eason的歌，特别是"陀飞轮"，真的是一首非常走心的歌，哎，年纪大了，听什么歌都有感触，哈哈…）

歌名：《陀飞轮》

填词：黄伟文
谱曲：Vincent Chow
歌曲原唱：陈奕迅

过去十八岁 没戴表 不过有时间
够我 没有后顾 野性贪玩
霎眼廿七岁 时日无多方不敢偷懒
宏愿纵未了 奋斗总不太晚 然后突然今秋
望望身边 应该有 已尽有...

创建文件并提交

敲击如下command，创建tuofeilun.txt文件，并键入内容

一定要放到D:\git\repository目录下（子目录也行），因为这是一个Git仓库，放到其他地方Git再厉害也找不到这个文件。把一个文件放到Git仓库只需要两步。
第一步，用命令git add告诉Git，把文件添加到暂存仓库

执行上面的命令，没有任何显示，这就对了，Unix的哲学是“没有消息就是好消息”，说明添加成功。
接着我们使用git status查看提交的状态，根据提示No commit yet 可知，文件添加到了暂存区还不行，依然得commit到master分支区。

所以，紧接着第二步，用命令git commit告诉Git，把文件提交到本地Master仓库

简单解释一下git commit命令，-m后面输入的是本次提交的说明(我的理解m就是mark备注的意思)，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。

git commit命令执行成功后会告诉你两个内容

• file changed：1个文件被改动（我们新添加的readme.txt文件）
• insertions：插入了两行内容（readme.txt有两行内容）

那为什么Git添加文件需要add，commit一共两步呢？
因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：$ git add file2.txt file3.txt同时添加两个文件，然后执行$ git commit -m "add 2 files." 就会一次性提交两个文件到主分支区了。

好啦，提交之后再次查看提交状态，提示我们说，目前暂存区没有文件需要提交了。

修改文件内容并提交

还没完呢！
接着修改并查看我们之前创建的tuofeilun.txt文件

此时查看文件提交状态，文件标红了？文件标红的意思就是你的磁盘工作区中的文件内容和master主分支区中的同名的文件的内容不一致，并且没有提交到暂存区中！

教大家一个新指令git diff，diff全称为difference，顾名思义就是差异的意思，那么这个指令就是查看主分支中该文件的内容和我们本地磁盘中的文件(一般指修改后的文件) 的内容的差异。大家看，我在文件中添加了一句 “我想去看Eason的演唱会” (PS:吐露了我的心声！) 之后，查看git diff指令，下面多了一行绿色的文字，这个内容也就是我们修改过后的内容。

我直接提交行不行呢？Oh…no，好像不行，原因是我还没有add到暂存区

这样就没问题了，所以修改文件之后，一定要先添加到暂存区之后再commit到主分支区！

此时再查看git的状态，是不是显示working tree都被清空啦！注意了，什么情况下查看git status会显示clean状态呢？
只有当本地磁盘中的文件内容和主分支中的文件内容一致，并且暂存区中没有暂存文件时，才会显示clean

小结

添加文件到Git仓库，分两步：
1）使用命令git add ，注意，可反复多次使用，添加多个文件；
2）使用命令git commit -m ，完成。
要随时掌握工作区的状态，使用git status命令。
如果git status告诉你有文件被修改过，用git diff可以查看修改内容

---

Git版本回退

说到Git的版本回退不得不先了解下git log指令，log就是日志的意思，所以这个指令很明显就是查看文件修改的日志记录，查看log最大的好处就是你可以清晰的看到你提交了多少次，以及每次提交的生成版本号是多少。

那有的朋友会问了，这版本号写在哪啊？没看到啊，使用SVN的时候版本号是1、2、3、4这样一个个的往上升级的，在Git里面我们怎么查看啊?

Git的版本号就是上面的黄色字体commit后的一连串字符串，这一串是不是和我们的UUID非常相似？当然它肯定不是使用UUID的算法，但是用途都是一样，目的是避免每一个版本号不重复，那问题又来了？SVN中的版本号那么好记，Git的版本号像老太太的裹脚布，又臭又长！为什么要这么设置啊？或者说这么设置的好处是什么？

大家细想，SVN是集中式版本控制中心，我们每次提交上去的修改过后的文件是必须要和远程仓库里的内容同步的吧？也就是说所有的PC端都是公用同一个版本库，那么这种情况下，我们相当于是只修改同一个远程文件，所以每修改一次，版本上就向上升级一次，完全不用考虑到版本的冲突。但是Git就不一样了，本质原因是Git是分布式的版本控制系统，也就是说不同的PC端在本地都有着这么一个仓库，也就是我们之前建立的本地的版本仓库，此时每个人好比都在单机操作一个同一个游戏角色(假设都叫一个名字marco)，那么角色的状态肯定不一样吧？角色的级别也不一样吧？那么当这些本地版本仓库里的内容需要同步到共享仓库，也就是远程仓库时，我们怎么才能区分这些修改之后的版本是谁创建的呢？(就好像你不知道这几个游戏角色，是由谁来操控的)。

因此Git为了将这些修改后的并且极有可能是同一个文件的版本号加以区分，就是为了方便后期的管理(比方说版本回退，试想如果大家使用了重复的version，那么届时到底该回退哪个文件呢？)。

Ok，讲了这么多，相信各位应该很清楚，什么是Git的版本号，以及为什么版本号会这么设计了吧~ 接下来我们就实操一下吧。比方说我想回退到上一个版本(第一版 )，因为我文件中的Eason的名字敲错了，写成了Eson，我想修改一下。

方式一：
我这里说明一下，下面这个指令就是回退到上一个版本，如果使用$ git reset --hard HEAD^^就是回退两个版本，同理，加多少个^就是回退多少个版本。

$ git reset --hard HEAD^

方式二：
当然我们还可以使用版本号回退的方式，在hard后面跟版本号，不一定要写全，但是一定不能和其他的版本号重复，当然这种几率可以说是非常小了。

修改成功之后我们再看，是不是回退到第一个版本啦？

这种感觉就好像是乘坐哆啦A梦的时光机，穿梭了时空！从现在回到了过去，虽然显示中是没有后悔药是可以吃的，但是程序却可以！而且Git把这一点做到了极致！
因为我的版本不仅可以追溯到过去，还可以穿梭到未来，嗯… 说的很玄乎，比如说咱们刚才不是吃了后悔药回来了吗？但是我又后悔了，想从过去的时空回到未来，能做到吗？

Git显然可以办到！使用指令git reflog可以查看未来的 “时空地址” ，也就是我们的版本号。

找到之后使用 “时光机” $ git reset --hard 424c519就可以回到未来了！

当当当当… 我又回来啦，$ git reset --hard version指令真的就是Java界的 “月光宝盒” !