Git 使用入门

1. 什么是Git

Git 是分布式版本控制软件。

1.首先Git是软件。

是软件就需要安装。安装可参考另一篇文章：(85条消息) Git安装配置_menergy-CSDN博客https://blog.csdn.net/menergy/article/details/122914545?spm=1001.2014.3001.5501

2.其次Git用于版本控制。

版本控制是一种记录一个或若干文件内容变化，以便将来查阅特 定版本修订情况的系统。我们对保存着软件源代码的文件作版本控制，但实际上，你可以对任何类型的文件进行版本控制。我们从最基本的版本控制说起：

纯人力版本控制系统

当我们没有使用版本控制软件进行版本控制时，为了保存版本，许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。，如下：

本地版本控制系统

但这样，有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的 文件。为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文 件的历次更新差异。如下：

 其中最流行的一种叫做 RCS，现今许多计算机系统上都还看得到它的踪影。 RCS 的工作原理是在硬盘上保存补 丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。

集中化的版本控制系统

本地版本控制系统只在于本机进行版本控制。接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？ 于是，集中化的版本控制系统 （Centralized Version Control Systems，简称 CVCS）应运而生。例如SVN（Subversion），CVS以及Perforce等。

这里有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端 连到这台服务器，取出最新的文件或者提交更新。（集中式版本控制的特点是：中心服务器维护所有版本，各客户端只维护当前的一个版本，不维护所有版本。）

但是问题来了，如果中央服务器的单点故障。 如果宕机一小时，那么在这一小时 内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无 疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。

分布式版本控制系统

为了解决集中式版本控制系统存在的弊端，于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。例如Git、Mercurial、Bazaar及Darcs等。区别在于客户端并不只提取最新版本的文件快照， 而是把代码仓库完整地镜像 下来，包括完整的历史记录。结构如下：

 至此我们明白了什么是版本控制，什么是分布式版本控制。

Git就是分布式版本控制的典范

2. Git 怎样开始版本控制

Git版本控制，通俗说就是Git管理文件夹。大概步骤如下：

1. 进入要管理的文件夹。（让Git知道要管理什么）

2. 初始化。（生成配置文件，声明Git开始管理）

3. 管理。

4. 生成版本。

例如如下：

首先第一步进入要被管理的文件夹，例如：

 第二步，初始化，在该文件夹中右键选择“Git Bash Here” 

然后输入“git init” 命令初始化。

执行命令后文件夹中生成了“.git” 文件夹。表明Git开始管理这个文件夹了。

第三步，开始管理文件。

 执行“git status”命令，查看所有要管理的文件。

 尝试新增两个文件，再用“git status” 检测：

 

 执行“git add GitLearnNote.txt” 开始管理 GitLearnNote.txt 文件：

红色的文件表示工作区中新增或修改的文件  执行“git add .” 把所有文件进行管理 ：

文件显示蓝色，表示Git已经对其进行管理，此时文件仍然在工作区中。

第四步，生成版本。

上面已经把文件管理起来了，接下来生成版本。执行“git commit -m 'V1' ”命令：

发现文件状态已经改变，本版已经生成。 可以执行“git log” 查看全部版本。

 版本v1 生成。

接下来试着改动 GitLearnNote.txt 文件的内容： 

 查看文件状态：

 Git 检查到文件变动，接着执行“git add .” 将其管理起来：

 生成版本v2：

 查看全部版本：

对上面总结：

1. 进入要管理的文件夹。

2.执行初始化命令：git init

3.管理目录下的文件状态：git status （新增或修改过的文件都是红色的）

4.管理指定文件（红变绿）

git add 文件名

git add .

5.生成版本：git commit -m '描述信息'

注： 如果安装时或者安装后没有设置个人信息，执行commit时可能会报错，我本机在安装Git时已经设置了，所以不报错。 如果报错，在commit前执行如下命令, 配置邮箱和用户名：

git config -global user.email "yourEmail@aaa.com"

git conifg -global user.name "your Name"

以上命令只需要执行一次即可。

3. Git 三大区域

Git 包括工作区、暂存区和版本库 三大区域。

• 工作区：就是你在电脑里能看到的目录。
• 暂存区：英文叫 stage 或 index。一般存放在 .git 目录下的 index 文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。
• 版本库：工作区有一个隐藏目录 .git，这个不算工作区，而是 Git 的版本库。

图中我们可以看出此时 "HEAD" 实际是指向 master 分支的一个"游标"。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。

图中的 objects 标识的区域为 Git 的对象库，实际位于 ".git/objects" 目录下，里面包含了创建的各种对象及内容。

当对工作区修改（或新增）的文件执行 git add 命令时，暂存区（index）的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引（index）中。

当执行提交操作（git commit）时，暂存区的目录树写（copy）到版本库（对象库）中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。

当执行 git reset HEAD 命令时，暂存区的目录树会被 master 分支指向的目录树所替换，但是工作区不受影响。

当执行 git rm --cached <file> 命令时，会直接从暂存区删除文件，工作区则不做出改变。

当执行 git checkout . 或者 git checkout -- <file> 命令时，会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险，会清除工作区中未添加到暂存区中的改动。

当执行 git checkout HEAD . 或者 git checkout HEAD <file> 命令时，会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。

注意：上面谈到的版本库，一般是指本地版本库，其实除了本地版本库外，我们还经常用到远程版本库。

加上远程版本库， git的完整区域和一般命令可以表示如下图：

 

 

下面通过一些实战示例来展示上图的区域和命令：

3.1 回滚示例

首先在git管理的目录新建一个html文件，内容如下：

 浏览器运行结果：

 下面开始生成版本"test v1"：

修改文件内容：

 浏览器显示：

 再生成新版本“test v2”：

 

接下来回滚至之前版本"test v1"：

 浏览器显示：

 接下来回滚至之后版本“test v2”：

 浏览器显示：

总结上面的操作：

1. 回滚到之前版本：

 git log 

git reset --hard 版本号（工作区和暂存区都会被回滚的版本覆盖）

2. 回滚到之后版本：

git reflog

git reset --hard 版本号 （工作区和暂存区都会被回滚的版本覆盖）

3.2 reset 和 checkout 命令案例

接着上面案例GitVersionTest.html文件，对该文件进行修改，添加“test reset and check out v3” 内容，具体如下：

 Git自动检测到更改（显示红色）如下：

执行“git add” 命令，将变动放到暂存区（显示蓝色），如下：

 执行“git commit”命令，将变动提交到本地仓库，如下：

 

 执行“git reset --soft 版本号” 命令，将提交后的变动回滚到暂存区状态（即上一个版本“test v2” 版本）， 如下：

 

 可以看到文件显示蓝色，即未commit之前的状态，处于暂存区。

接下来执行“git reset HEAD” 命令，将文件回滚到工作区，但仍然处于变更状态，如下：

 

 接下来执行“git checkout -- 文件名” 命令，将工作区的修改也回滚，回到上个版本状态（即未改变内容之前），如下：

查看文件内容，发现变回来了：

接下来测试“git reset --mix 版本号” 命令，从本地版本库直接回滚到工作区，但文件仍然处于修改状态

首先修改文件，增加"reset --mix v4"内容，如下：

 执行一系列命令，提交到本地版本库，如下：

 接下来执行“git reset --mix 版本号” 回到工作区中的已经改变状态，如下：

 

 接下来在执行“git checkout -- 文件名”命令，回到内容更改前状态，如下：

 

 本案例结束。

总结本案例新用到的命令：

1. 从本地仓库回滚到暂存区

git reset --soft 版本号

2. 从暂存区回滚到工作区（文件仍处于新增或改动状态）

git reset HEAD

3. 工作区内回滚（文件回滚至未新增或更改状态，即上一版本内容）

git checkout -- 文件名称

 4. 从本地仓库直接回滚至工作区（文件仍处于新增或改动状态）

git reset --mix 版本号

5. 从本地仓库直接回滚至工作区（新增或变动内容回滚）（上个案例中用到该命令）

git reset --hard 版本号 （工作区和暂存区都会被回滚的版本覆盖）

至此，我们已经实践了如下命令（尚未涉及远程仓库）：

 

接下来的文章将晋级远程仓库等其他功能的实践。

参考：Git 教程 | 菜鸟教程 (runoob.com)https://www.runoob.com/git/git-tutorial.html