前言

我们在实现小组项目的时候，往往是一个人负责一个项目中的某个部分，然后再将完成的代码文件合并。其中每个人都有好多项目文件，往往会出现命名不规范，协作困难，文件丢失等问题。不用担心，现在版本控制系统就可以完美的解决这些问题，因为不停的迭代更新，分布式版本控制系统Git兼具各种有点，而且版本操作系统上手简单，接下来就让我们一起来了解一下版本控制系统吧 

目录

前言

Git起步

版本控制

👉文件的版本本地版本控制系统

 👉 版本软件控制

 👉 版本控制系统的分类 

Git基础概念

 👉什么是Git

 👉Git的特性

 👉 Git中的三个区域

 👉 Git中的三种状态

👉Git的基本工作流程

Git的基本操作 

👉获取Git仓库的两种方式

👉 在现有目录中初始化仓库

👉 工作区中文件的4种状态

👉  检查文件的状态

👉   跟踪新文件

👉  提交更新

 👉 暂存已修改的文件

 👉 提交已暂存文件

 👉 撤销对文件的修改

 👉 向暂存区中一次性添加多个文件

 👉 取消暂存的文件

 👉 跳过使用暂存区域

 👉移除文件

 👉 忽略文件

 👉  查看提交历史

 👉  回退到指定版本

💐Per aspera ad astra  循此苦旅，以觅繁星 💐

---

 

Git起步

版本控制

👉文件的版本本地版本控制系统

传统的文件管理凸显出的一些缺点：

1.     操作麻烦            每次操作需要复制->粘贴->重命名
2.     命名不规范        无法通过文件名知道具体做了哪些改变
3.     容易丢失            如果硬盘故障或不小心删除，文件很容易丢失
4.     协作困难            需要手动合并每个人岁项目文件的修改，合并时极易出现错误

 👉 版本软件控制

概念 

版本软件控制是一个用来记录文件变化，以便将来查阅特定版本修订情况的系统，因此优势也叫做“版本控制系统”

通俗的理解

把手工管理文件版本的方式，改为由软件管理文件的版本；这个负责管理文件版本的软件，叫做“版本控制软件”

 好处

1. 操作简便    只需记得机组简单的终端命令，即可快速上手常见的版本控制软件
2. 易于对比    基于版本控制软件提供的功能，能够方便的地比较文件的变化细节，从而查找出导致问题的原因
3. 易于回溯    可以将选定的文件回溯到之前的状态，甚至将整个项目都退回到过去某个时间点的状态
4. 不易丢失    在版本控制软件中，被用户误删除的文件，可以轻松的恢复回来
5. 协作方便    基于版本控制软件提供的分支功能，可以轻松实现多人协作开发的代码合并操作

 👉 版本控制系统的分类 

版本控制系统控制系统大致可分为三个大类：本地版本控制系统、集中化的版本控制系统、分布式版本控制系统. 大致就是一个成长史。

1. 本地版本控制系统

单机运行，使维护文件版本的操作工具化

特点

使用软件来记录文件的不同版本，提高工作效率，降低了手动维护版本的出错率

缺点

1. 单机运行，不支持多人协助开发
2. 版本数据库故障后，所有历史更新记录会丢失

2. 集中化的版本控制系统

 联网运行，支持多人协作开发，性能差，用户体验不好

特点

• 基于服务器、客户端的运行模式
• 服务器保存所有文件的所有更新记录
• 客户端只保留最新的文件版本

优点

联网运行，支持多人协作开发

缺点

• 不支持离线提交版本更新
• 中心服务器崩溃后，所有人无法正常工作
• 版本数据库故障后，所有历史更新记录回丢失

典型代表  SVN 

3. 分布式版本控制系统

联网运行，支持多人协作开发；性能优秀，用户体验好

特点

• 基于服务器、客户端的运行模式
• 服务器保存文件的所有更新版本
• 客户端是服务器的完整备份，并不是值保留文件的最新版本

优点

1. 联网运行，支持多人协作开发
2. 客户端断网后支持离线本地提交版本更新
3. 服务器故障或损坏后，可使用任何一个客户端的备份进行恢复

典型代表  Git 

Git基础概念

 👉什么是Git

Git是一个开源的分布式版本控制系统，是目前世界上最先进，最流行的版本控制系统。可以快速高效的处理从很小到非常大的项目版本管理

特点：项目越大越复杂，协同开发者越多，越能体现Git的高性能和高可用性

 👉Git的特性

Git拥有两个特性

1. 直接记录快照，而非差异比较
2. 近乎所有操作都是本地执行

什么是记录快照和差异比较？

1. SVN的差异比较
传统版本控制系统（例如SVN）使基于差异的版本控制，他们存储的是一组基本文件和每个文件随时间逐步积累的差异。

好处

节省磁盘空间

缺点

• 耗时，效率低
• 每次在切换版本对的时候，都需要在基础文件的基础上，应用每个差异，从而生成目标版本对应的文件

2. Git的记录快照

 Git快照是在原有文件版本的基础上重新生成一份新的文件，类似于备份。为了效率，如果文件没有修改，Git不在重新存储文件，而是只保留一个链接指向之前存储的文件

 缺点

 占磁盘空间大

优点

版本切换时非常快，因为每个版本都是完整的文件快照，切换版本直接混服目标版本的快照即可

特点： 空间换时间 

 👉 Git中的三个区域

使用Git管理的项目，拥有三个区域，分别是

1. 工作区           处理工作的区域
2. 暂存区           已完成的工作的临时存放区域，等待被提交
3. Git仓库          最终存放区域

 👉 Git中的三种状态

1. 已修改（modified）：表示修改了文件，但还没有键修改的结果放到暂存区
2. 已暂存（staged）：表示对已修改文件的当前版本做了标记，使之包含在下次提交的列表中
3. 已提交（committed）：表示文件已经安全地保存在本地的Git仓库中

注意：

•         工作区的文件被修改了，但还没有放到暂存区，就是已修改状态
•         如果文件已修改并放入暂存区，局势属于已暂存状态‘
•         如果Git仓库中保存着特定版本的文件，就是属于已提交状态 

👉Git的基本工作流程

•     在工作区中修改文件
•     将你想要下次提交的更改进行暂存
•     提交更新，找到暂存区的文件，将快照永久性存储到Git仓库 

Git的基本操作 

👉获取Git仓库的两种方式

1. 将尚未进行版本控制的本地目录转换为Git仓库
2. 从其他服务器克隆一个已存在的Git仓库

以上两种方式都能够在自己电脑上得到一个可用的Git仓库

👉 在现有目录中初始化仓库

如果自己有一个尚未进行版本控制的项目目录，想要用Git来控制它，需要执行如下两个步骤

1.  在项目目录中，通过鼠标右键打开“Git Bash”
2. 执行git init命令将当前的目录转化为Git仓库

git init

git init命令回创建一个名为.git 的隐藏目录，这个.git 目录就是当前项目的Git仓库，里面包含了初始化的必要文件，这些文件是Git仓库的必要组成部分

👉 工作区中文件的4种状态

工作区中的每一个文件可能有4种状态，这四种状态分为两大类
1. 违背Git管理

• 未跟踪（Untracked）： 不被Git做管理的文件

2. 已被Git管理

• 未修改（Unmodified）： 工作区中文件的内容和Git仓库中文件内容保持一致
• 已修改（Modified）：工作区中文件的内容和Git仓库文件的内容不一致
• 已暂存（Staged）：工作区中被修改的文件已被放到暂存区，准备将修改后的文件保存到Git仓库中

Git操作的终极结果：让工作区中的文件都处于”未修改“的状态

👉  检查文件的状态

可以使用git status 命令文件查看文件处于什么状态

• 在状态报告中可以看到新建的index.html文件出现在Untracked files（未跟踪的文件）下面
• 未跟踪的文件意味着Git在之前的快照（提交）中没有这些文件；Git不会自动将之纳入跟踪范围，除非明确地告诉他”我需要使用Git跟踪管理该文件“

以精简的方式显示文件状态

使用git status输出的状态报告很详细，但有些繁琐。如果希望以以精简的方式显示文件状态，可以使用以下两条完全等价的命令 ；其中 -s是--short的简写形式

• git status -s
• git status --short

•  未跟踪文件前面有红色的？？标记

👉   跟踪新文件

使用git add 开始跟踪一个文件。

git add index.html

此时再运行git status命令，会看到index.html文件再Changes to be committed这行下面，说明已被跟踪，并处于暂存状态

 以精简的方式显示文件的状态

新添加到暂存区中的文件前面有绿色的A标记 

👉  提交更新

现在暂存区中有一个Index.html文件等待被提交到Git仓库进行保存。git commit命令进行提交，其中-m选项后面是本次的提交消息，用来对提交的内容做进一步的描述
提交成功后证明工作区中所有文件都处于”未修改“的状态，没有任何文件需要被提交

git  commit -m "新建了index.html文件" 

 

👉对已提交的文件进行修改

目前，Index.html已经被Git跟踪，并且工作区和Git仓库中的index.html文件保持一致。当我们修改了工作区中的index.html的内容之后，再次运行git status  和 git status -s命令

文件index.html出现在Changes not staged for commit 这行下面，说明一跟踪文件的内容发生了变化，但还没有放到暂存区 

•  注意：修改过的，没有放入暂存区的文件前面有红色的M标记 

 👉 暂存已修改的文件

 目前工作区中的index文件已被修改，如果要暂存这次修改，需要再次运行git add命令

git add命令，这个命令是多功能的命令

1. 可以用它开始跟踪新文件
2. 把已跟踪，且已修改的文件放到暂存区
3. 把有冲突的文件标记为以解决状态

 注意：暂存的文件前面有绿色的M标记 

 👉 提交已暂存文件

再次运行git commit -m “提交消息”命令，即可将暂存区中记录的index的快照，提交到仓库中进行保存 

 👉 撤销对文件的修改

指的是把工作区中对应文件的修改，还原成Git仓库中所保存的版本

操作结果：所有的修改回丢失，且无法恢复，危险性比较高，慎重操作

撤销操作的本质： 用Git仓库中保存的文件，覆盖工作区中指定的文件 

 👉 向暂存区中一次性添加多个文件

如果需要被暂存的文件个数比较多，可以使用如下的命令，一次性将所有的新增和修改过的文件加入暂存区

git add .

  

 👉 取消暂存的文件

如果需要从暂存区中移除对应的文件，可以使用以下的命令

git reset HEAD 要移除的文件名称 

 

 👉 跳过使用暂存区域

Git标准的工作流程是工作区 -> 暂存区 -> Git仓库，但有时候这么做略显繁琐，此时可以跳过暂存区，直接将工作区中的修改提交到Git仓库，这时候Git工作的流程简化为了工作区 -> Git仓库

 Git提供了一个提供了一个跳过只用暂存区的方式，只要在提交的时候，给git commit 加上-a选项，Git就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过git add 步骤

git commit -a -m "描述消息" 

 

 👉移除文件

1. 从Git仓库和工作区中同时移除对应的文件

git rm -f "文件名"

2. 只从Git仓库中移除指定的文件，但保留工作区中对应的文件

git rm --cached "文件名" 

 👉 忽略文件

一般我们总会有写文件无需纳入Git管理，也不希望他们总出现在未跟踪文件列表，再这种情况下，我们可以创建一个名为 .gitignore的配置文件，列出要忽略的文件的匹配模式

•         以 # 开头是注释
•         以 / 结尾的是目录
•         以 / 开头防止递归
•         以 ！开头表示取反
•         可以使用glob模式进行文件和文件夹的匹配（glob指简化了的正则表达式）

 glob模式

• 星号* 匹配零个或等多个任意字符
• [abc] 匹配任何一个列在方括号中的字母（此案例匹配一个a或者匹配一个b或者匹配一个c）
• 问号？只匹配一个任意字符
• 在方括号中使用短划线分隔两个字符，表示所有在两个字符范围内都可以匹配（比如[0-9]表示匹配所有0到9的数字）
• 两个星号** 表示匹配任意中间目录（比如a/**/z可以匹配a/z、a/b/z、a/b/c/z等） 

 👉  查看提交历史

使用git log 命令可以查看提交历史

git log

按时间先后顺序列出所有的提交历史，最近提交排在最上面

git log -2

只展示最新的两条提交历史，数字可以按需进行填写

git log -2 --pretty=oneline

在一行上展示最近两条提交历史的信息，在一行上展示最近两条提交历史的信息，并自定义输出格式

git log -2 --pretty=format:"%h | %an | %ar | %s"

•  %h： 提交的简写哈希值
• %an： 作者名字
• %ar： 作者修订日期,按多久以前的方式显示
• %s：  提交说明 

 👉  回退到指定版本

1. 根据查询提交历史获得版本符号
2. 使用 git reset -- hard命令，根据指定的ID回退到指定版本
3. 在旧版本中使用git reflog --pretty=online命令，查看命令操作的历史
4. 再次根据最新提交ID，跳转到最新版本 

---

---

Git的基础知识总结到此结束了，使用Git并不难，只要记住上述的操作命令，Git的使用就是小菜一碟，下次见~

🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷🌷

💐Per aspera ad astra  循此苦旅，以觅繁星 💐