Git安装

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

Windows版本的Git安装除了安装路径需要修改一下，其他的地方都可以默认，然后一直next就安装完成了。
安装完之后，我们在Windows任意位置右键，如果出现下面红色框中的选项，就说明Git安装成功了。
在这里插入图片描述
我们点击Git Bash Here，然后输入Git --version，就能看到我们安装Git版本了。

Git简介

Git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。

什么是版本控制系统？

举个栗子：
我们今天上班敲了一天代码，然后关机下班。明天来的时候，可能因为某个原因要修改代码。修改之后发现，怎么比之前的还差。于是又得修改，一直一直修改下去，最后不知道修改了多少次，到头来可能觉得还是最初的代码写的好，最直接的方法就是手动敲代码恢复到最初的代码，这个过程实在是难受，于是Git就被广泛使用了。因为Git是版本控制系统，只要我们把代码交给了Git，我们就相当于拥有的后悔药，可以把代码恢复到任意的版本。Git还有一个特性就是分布式(这个接下来就会讲到)，由于这个特性，SVN逐渐被Git取代了。

Git与SVN的区别

上面我们说了Git是分布式的版本控制系统，而SVN是集中式的版本控制系统，下面画个图来讲解它们的区别：
在这里插入图片描述

首先，我们的代码需要交给Git仓库或者SVN仓库之后，才能管理我们的代码版本。
SVN只有中央仓库，每个人提交的代码都是在中央仓库。这样不太好，只要团队中的一个人提交了代码，那么中央仓库的代码就跟着改变，因为有时我们只是需要对我们自己的代码进行版本控制而已。
Git有本地仓库和中央仓库。我们自己的电脑就是本地仓库，我们只要把代码提交到本地仓库，也能让Git帮我们管理代码版本，而不用提交到中央仓库。这样中央仓库的代码不用改变，我们实现了只控制我们自己的代码版本。
因为Git是分布式的，所以我们每个人的电脑也能充当中央仓库，和其他人进行代码提交和拉取。

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

上面讲完了什么是Git，以及Git的特性。接下来我们就真正开始Git的旅程。首先我们操作Git之前，要让Git知道你是谁？

你是谁？

在代码的推送和拉取的时候，Git要知道你是谁，也就是能标识你身份的信息。这些信息就是用户名和邮箱。

设置全局身份信息，也就是对所有本地仓库有效。
git config --global user.name = 用户名
git config --global user.email = 邮箱
设置本地仓库身份信息，也就是只对改本地仓库起效。
git config user.name = 用户名
git config user.email = 邮箱
查看全局身份信息，查看本地仓库身份信息去掉–global即可。
git config --global user.name
git config --global user.email

一般设置全局身份信息。

Git本地仓库

我们需要创建Git本地仓库，然后把代码交给Git管理，这样才能让Git控制我们的代码版本，我们才算拥有了后悔药。
在Windows上，任意的Git命令都是在Git Bash Here中执行，我们通过git init命令来创建本地仓库。执行命令后会创建.git文件夹，该文件夹默认是隐藏的。不能手动对该文件夹做其他操作，否则会破坏本地仓库。
在这里插入图片描述

温馨提示
在Windows系统上，任意的文件夹只要执行上面命令后，并且成功创建.git文件夹，那么它就是本地仓库了。
虽然我们是安装Windows版本的Git，但是Git一开始是为合并Linux代码被诞生的，所以Git命令兼容Linux命令，
我们右键可以看到Git Bash Here，点击它出现控制台，可以看成是精简版的Linux终端，可以执行Git命令，也可以执行Linux命令。
在这里插入图片描述

上面我们学习了如何创建本地仓库，接下来画个图来说明一下Git本地仓库的构造。

本地仓库构造

Git的本地仓库分为工作区（存储我们的文件区域），暂存区（临时存储我们的文件），版本库（真正控制版本的区域）。
在这里插入图片描述
了解了Git本地仓库构造，接下来我们就真正行动起来，让Git控制我们任意文件的版本。
这里只是以简单的.txt文件来讲解Git是如何控制版本的。

摘自廖雪峰Git教程

所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。
版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。
图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。
不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，如果要真正使用版本控制系统，就要以纯文本方式编写文件。
因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。

我们输入pwd命令，打印我们所处的目录路径

$ pwd
/e/Learning Java/Git/Git-Learning/Git-First

我们在该目录下新建Git.txt文件，然后输入下面两行字：

Git is a version control system.
Git is free software.

将文件添加到暂存区

我们刚刚新建的Git.txt文件是存储在工作区，需要先把文件添加到暂存区，再提交到版本库中。才能产生文件版本信息。
我们上面还说了如果是新建的文件或者是修改的文件，那么它就会显示为红色，我们通过git status命令来证实我们所说的。
注意：我们不能直接将文件提交到版本库中。
在这里插入图片描述
好了，接下来我们就把工作区中的文件添加到暂存区中，添加的方式有多种，如下命令：

添加单个文件到暂存区
git add 文件名称
添加多个文件到暂存区
git add 文件名称文件名称 ...
添加该目录下所有文件到暂存区
git add .

在这里插入图片描述
将文件添加到暂存区后，我们再输入git status查看本地仓库状态，我们可以看到暂存区中的文件显示为绿色。
这也符合我们上面说的暂存区中所有的文件都会显示为绿色。

将文件提交到版本库

虽然我们把文件添加到暂存区了，但是Git还不能真正管理我们的文件，只有我们把文件提交到暂存区，Git才算真正管理我们的文件，因为我们每一次提交，都会产生一个版本号，我们就是通过版本号来任意切换不同的版本。

git commit -m <commit message>

在这里插入图片描述
简单解释一下git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。这时我们再输入git status命令，如下图，发现什么都没有了。说明工作区和暂存区没有要提交的文件了。
在这里插入图片描述

git diff

我们尝试修改以下Git.txt文件，修改为如下内容：

Git is a distributed version control system.
Git is free software.

我们再使用git status命令查看本地仓库的状态，下面图说明Git.txt被修改了，但是还没提交到版本库中，这时我们就得遵守上面的流程再次将Git.txt提交到版本库中。文件一旦被修改，就需要这两个步骤：先添加到暂存区，然后再提交到版本库中。
在这里插入图片描述
那我们查看两次提交文件的区别呢？或者说文件被修改哪些内容了，这时我们就用到git diff 文件名称命令。

git diff顾名思义就是查看difference，显示的格式正是Unix通用的diff格式。
可以从上面的命令输出看到，红色表示为被修改的内容，绿色表示修改后的内容，黑色表示没有变化的内容。
画个图来回顾我们上面的操作
在这里插入图片描述

版本回退

Git会记录我们提交的次数以及每次提交产生的版本号，我们就是通过版本号来对文件进行版本回退。
为了产生很多的版本号，我修改了很多次Git.txt文件并提交到版本库中。

git log

说个笑话，我们可能明天起床后，就忘记了昨天我们往版本库提交过多少次了。
哎，别担心，Git就知道我们会出现这种情况，它很贴心，为我们准备了git log命令，该命令显示从最近到最远的提交日志。
在这里插入图片描述

如果嫌输出信息太多，看得眼花缭乱的，可以试试加上–pretty=oneline参数：
在这里插入图片描述
温馨提示

我们看到的一大串类似41ec51f8324d…的就是commit id（版本号），和SVN不一样，Git的commit id不是1，2，3……递增的数字，而是一个SHA1计算出来的一个非常大的数字，用十六进制表示，每个人的commit id肯定是不一样的。
为什么commit id需要用这么一大串数字表示呢？因为Git是分布式的版本控制系统，后面我们还要研究多人在同一个版本库里工作，如果大家都用1，2，3……作为版本号，那肯定就冲突了。每提交一个新版本，实际上Git就会把它们自动串成一条时间线。

知道了每一次提交的版本号之后，我们就可以使用时光穿梭机，在多个版本中任意切换。

首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交41ec51f8324d…（每个人提交的版本号肯定是不一样的），上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^不现实，所以写成HEAD~100。

git reset

我们已经知道怎么查看提交日志，以及了解什么是版本号了。接下来就开始使用时光穿梭机。git reset命令就是版本回退的命令。
在回退之前我们先看看当前Git.txt的内容，cat 文件名称命令是打印指定文件内容。
在这里插入图片描述
git reset --hard head^：回退到上一个版本。

回退之后我们再次查看当前文件内容，发现文件内容已经改变了。Git太强大了。

我们再看看提交日志信息，git log --pretty=oneline。发现之前最新的版本（提交信息为：再再次修改Git.txt文件）已经看不到了。

好比你从21世纪坐时光穿梭机来到了19世纪，想再回去已经回不去了，肿么办？办法其实还是有的，只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到（提交信息为：再再次修改Git.txt文件）的commit id是41ec51f8324d…，于是就可以指定回到未来的某个版本，版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。
git reset --hard 41ec51f8324d
然后我们再查看Git.txt文件内容，发现真的穿梭到未来了…
在这里插入图片描述
Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针。当你回退版本的时候，Git仅仅是把HEAD指向你恢复的版本。然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。
在这里插入图片描述

git reflog

假设你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？
在Git中，总是有后悔药可以吃的。当你用$ git reset --hard HEAD^回退到之前版本时，再想恢复到未来版本，就必须找到commit id（版本号），可是不知道版本号？Git提供了git reflog命令用来记录你的每一次命令。
在这里插入图片描述
我们可以通过git reflog命令知道所有的版本号，然后再通过上面的版本回退命令就可以了。

Git中的修改

为什么Git比其他版本控制系统设计得优秀？因为Git跟踪并管理的是修改，而非文件。在Git中，修改体现在多方面：

你新增了一行，这就是一个修改
删除了一行，也是一个修改
更改了某些字符，也是一个修改
删了一些又加了一些，也是一个修改
甚至创建一个新文件，也算一个修改

当我们修改了一个文件，但是没把这次修改添加(git add)到暂存区，执行git commit是没效果的，因为git commit只能提交暂存区中的修改，而不能提交工作区中的修改。
在这里插入图片描述

撤销修改

我们修改了Git.txt文件，一开始是工作区的修改，此时Git会给我们两个选择，我们使用git status命令来查看

将此次修改添加到暂存区中：use “git add <file>”
撤销此次修改：use "git checkout – <file>

在这里插入图片描述
因为添加到暂存区的命令我们已经测试很多次了，所有这次只测试撤销修改的命令。
我们执行git checkout -- Git.txt命令之后，再执行git status命令，发现我们上一次的修改确实被撤销了。

还有一种情况就是，当我们修改了文件，已经把此次修改添加到暂存区了，如果我们再次修改之后，然后再执行撤销命令git checkout -- Git.txt会怎样？这种情况Git只会将文件恢复到上一次添加到暂存区之后的状态。(有可能添加到暂存区之后修改很多次)

对于修改的最后一种情况，就是我们将工作区的修改已经添加到暂存区之后，我们怎么撤销此次添加呢？
我们还是使用git status命令查看，Git给我们两个选择：

提交到版本库：git commit -m message
把暂存区的修改撤销掉，重新放回工作区：use “git reset HEAD <file>”

git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。
git reset head Git.txt
在这里插入图片描述
假设你不但改错了东西，还从暂存区提交到了版本库，怎么办呢？那就使用版本回退，可以回退到上一个版本。前提是你还没有把自己的本地仓库推送到远程仓库。一旦你修改了什么错误信息提交推送到远程仓库，那么别人可都会知道了…