GIT总结文档（入职文档）、Git的四个工作区域和工作流程、HEAD、master 与 branch（Git分支管理相关概念及操作流程）、对比之前版本文档修改内容、git的终端基本操作命令

提示：本文章通过简单介绍GIT的特点、GIT的安装，执行基本操作、备注、总结的形式介绍与学习GIT

一.GIT总结文档（入职文档）（通过一些简单的基本操作，学会GIT操作）

注：要推送到远端一定要连接VPN，提交到本地不需要连接VPN；

（一）.GIT介绍

  GIT作为分布式版本控制系统，对我们的工作有着很重要的帮助，使用GIT能够使我们的工作更为安全高效。

1.GIT的特点

  首先我们要了解什么是GIT,GIT作为分布式版本控制系统，其“分布式”是相当于“中心式”而言的（典型的中心式版本控制系统如SVN,"中心“是一个特殊的服务器，也是一个中心仓库，工作过程中每个开发者从中央仓库下载最新版的项目到本地、随后开发、最后再上传给中央仓库。由此可见”中心式“系统特别依赖中心仓库，当中心出了问题或者本地与中心断开了连接， 都可能影响到项目开发。）

  Git 理论上是没有中心的，每一个设备都有本地仓库，任何一个设备的在这里插入代码片本地仓库出问题对其他设备都没有影响。且每一个设备都可以创建分支，Git 强大的分支管理也是它的价值所在。

2.GIT的工作过程

  如上图，Git 在电脑上为每个项目建了个本地仓库（项目就是一个电脑端的文件目录，里面的文件都可以交给 Git 管理），每当你的项目完成一小段任务后就可以提交给本地仓库。之后在服务器上建一个远程仓库（这里的服务器只是为了多台设备交流方便而设立的，本质上 Git 系统不依赖它，与中心式系统不是一回事），你将本地仓库的文件推送给远程仓库，其他人（设备）从这个远程仓库获取文件到他们的本地仓库，这样就实现了多个设备的文件同步。

（二）.GIT的安装

1.GIT服务端下载:​

链接：https://www.git-scm.com/download/win

2.GIT客户端及中文包下载

链接：https://tortoisegit.org/download/

3.设置

  安装完成之后，在桌面空白的地方右键鼠标，弹出菜单应该有下图这些选项了：

  选择 TortoiseGit->设置，窗口左侧选择“Git”，在右边填写用户名称和邮箱（若弹出提示窗口，关闭即可）。这个用户信息就是将来使用 Git 时显示各种操作是谁作的。

4.注册Git服务器账号

链接: (http://192.168.50.129:3000/lixiao/IOT.git).

（三）.体验Git和Github（基本操作）

1.在 GitLab 上创建项目

  点击网址，在 GitLab 页面顶栏点击“+”符号创建一个 Group（所有项目都是隶属于 Group 的），
​​​​​​
  之后在 Group 里创建第一个项目，记得勾选“Initialize repository with a README”。


  接下来用这个该项目来练习基本 Git 操作。
  创建项目之后复制项目的 URL，点击下图中的按钮即可：克隆项目到本地

   在你的硬盘上找一块空地右键鼠标，选择 “Git 克隆（clone）”

  然后你就看到之前在 GitLab 上创建的项目被复制下来了！打开目录可以看到自动创建的 README.md 文件。

2.创建新文件

  在 README.md 旁边创建一个文本文档，文档输入“Hello Git!”保存并关闭。

  在目录下空白区域右键鼠标，选择“Git 提交（commit） -> master”。含义是：将本地的修改内容提交到本地仓库主分支。

  Git 不会自动将所有处于项目目录下的文件纳入管理，哪些文件需要被 Git 管理需要用户指定。在这里，我们勾选窗口下方“显示未受版本控制的文件”，然后勾选需要添加的文件。最后添加本次提交的日志信息，就可以提交了。

看到这个蓝色的“成功”就代表操作正确了。

3.还原文件

  打开刚才添加的文本文档，删除所有内容保存并关闭文档。鼠标右键空白处，选择“TortoiseGit ->还原（revert）”，在弹出的窗口中勾选文本文档，然后点“确定”。再次打开文档，发现被删除的文本被还原了！

4.推送到远程仓库

刷新 GitLab 页面，刚才添加的文本文档不在列表里；

  因为 Git 提交只是提交到本地仓库，如果要同步给远程仓库然后再同步给其他设备，就需要执行推送命令。右键 “TortoiseGit->推送（push）”。

  所有都是默认选项，直接点击“确定”即可推送。等操作成功后刷新 GitLab 页面，会看到添加的文本文档。

5.更改GitLab 页面的一些文档（使本地磁盘文档同步）（获取与合并操作）

  在GitLab 页面将新建文本文档.txt的内容更改一下，现在我们在当前使用的设备上将这个更改的行为同步下来。右键“TortoiseGit->获取(fetch)”（注意不是拉取）；

然后你会发发现，本地的磁盘文档并没有更改，别急，右键“TortoiseGit->版本分支图”：

  浅黄的origin 代表远程仓库，红色的master代表本地仓库，本地主分支落后于远程主分支了。刚才获取操作只是修改了远程分支，没有修改本地分支。现在需要执行一次“合并”将远程分支与本地分支合并。右键“TortoiseGit->合并(merge)”：

默认选项即可，点击确定。执行后可以看到本地磁盘文本文件更改了。

再打开版本分支图，可以看到本地分支和远程分支合并了。

6.解决冲突（有冲突时）

  直接通过 GitLab 页面编辑器修改 新建文本文档.txt的内容，输入“remote”；在本地通过记事本修改新建文本文档.txt的 内容输入“local”。现在再执行 “获取”；然后再执行“提交”；现在打开版本分支图.

远程分支和本地分支分道扬镳了！

现在我们再执行“合并”，会看到合并失败

失败的原因是，两个分支上 新建文本文档.txt 的修改内容冲突并且无法自动合并。同时看到一个提示窗口：

提示我们解决冲突后再提交。关闭这些窗口，然后右键 “TortoiseGit->解决冲突（resolved）”：

选中冲突文件，右键选择“编辑冲突”：

  在编辑冲突的窗口中，左上角是远程分支的文件内容，右上角是本地分支的文件内容，下方是合并后的内容。在每一块内容中，红色部分是冲突内容。右键合并后的内容，选择优先左侧文本块（这样选择相当于远程和本地的内容合并了，只是合并后的内容远程的在上面，本地的在下面），标记已解决冲突、退出。
  现在还需要执行一次提交。提交完成后执行推送，将修改推送到远程仓库。

现在再查看版本分支图，可以看到本地分支和远程分支合并了。

7.log日志功能

  在空白处右键tortoiseGit->显示日志，即可打开日志页面，日志可以显示远程库中所有被更改的具体内容，以及更改的人的ID，根据这些信息可以对各个版本所更改的内容进行对比，并可以选择还原到任何一个版本。非常滴银杏~

我们要回到9:10:43是的那个状态，右键重置“master”到此版本

之后选择硬重置，点击确定即可

（四）.备注

1.右键菜单里“TortoiseGit->拉取”

  “拉取”相当于先“获取”然后强制“合并”，也就是说如果存在冲突文件也会合并冲突文件。所以“拉取”不安全，应该尽量使用“获取”然后手动“合并”，手动解决可能发生的冲突。

2.Git 本地仓库在哪？

  设置你的资源管理器以显示隐藏文件，打开你的项目目录，可以看到一个名为 .git 的隐藏文件夹，这就是当前项目的本地仓库了。因此，移动项目的位置不会影响到 Git 的管理，本地仓库就在项目目录里面。

3.怎么把项目同步到另一台电脑上

  打开另一台电脑，根据之前讲到的“准备工作”部分安装程序、创建 SSH 密钥并将公钥添加到你的 GitLab 账号下，复制 GitLab 项目 URL 然后执行“Git 克隆”就可以了。

  将来如果设备丢失、或者团队成员离职，为了保证安全，你可以在 GitLab 上删除对应设备或员工的 SSH 公钥即可。

（五）.总结

1.还原到此版本时（还原时重置，硬重置）

2.一样的状态时单纯改变本地文档，然后提交，这是本地库高于远程库。只是更改了GITLab远程端的内容，此时远程高于本地；

3.本地低想推送，先通过获取，合并使优先级一样（此时工作区的内容也与远程一样了，工作区被改变了），再更改内容（更改之后优先级就高了）再提交、推送，远程就改变了

4.本地仓库和远程仓库一样的情况下，单纯改变本地文档，然后提交，不会造成分道扬镳，只是本地仓库优先级提前了；

5.只改变远程，本地文档获取后，只是远程仓库优先级变高了，没有分道扬镳，此时本地文档执行合并，这时本地文档与远程同步，本地仓库与远程仓库合并；（工作区被动与远程仓库保持同步；

6.本地仓库低，拉取、合并之后优先级一样；

7.（本地高时可推送，本地低时不可推送？？？）不一定，当本地仓库优先级高时，（可以推送但推送不成功），拉取也不能使优先级一样，这时的操作是获取、合并。合并出错，解决错误即可，之后再对本地文档执行提交、推送。
8.推送时勾选force,强制推送（应用于本地落后于远程或本地与远程分道扬镳；且想要远程变成本地的版本）

二.Git的四个工作区域和工作流程（workspace index repository remote）

（一）.GIT是分布式版本控制系统

  Git是一种分布式版本控制系统，理论上是没有中心的，每一个设备都有本地仓库，任何一个设备的本地仓库出问题对其他设备都没有影响。而且，每一个设备都可以创建分支，Git 强大的分支管理也是它的价值所在。
  由此可以高效地处理项目的版本管理，包括跨区域的多人协同开发，追踪和记录文件的历史记录，组织和保护源代码和文档，统计工作量，跟踪记录整个软件的开发过程。
  Git 在你的电脑上为每个项目建了个本地仓库（项目就是一个文件目录，里面的文件都可以交给 Git 管理），每当你的项目完成一小段任务当后就可以提交给本地仓库。然后你在服务器上建一个远程仓库（这里的服务器只是为了多台设备交流方便而设立的，本质上 Git 系统不依赖它，与中心式系统不是一回事），你将本地仓库的文件推送给远程仓库，其他人（设备）从这个远程仓库获取文件到他们的本地仓库，这样就实现了多个设备的文件同步。

（二）.GIT的工区域组织架构

  GIT有四个工作区域，每个工作区域实现不同的功能，帮助我们完成不同的工作，如下表所示:

1	Workspace	工作区
2	Index	暂存区
3	Repository	本地仓库
4	Remote	远程仓库

1.Workspace：工作区

  工作区即进行开发改动的地方，是当前看到的，内容也是最新的，平常开发就是拷贝远程仓库中的分支，基于该分支进行开发，在开发的过程就是在工作区的操作。

2.Index：暂存区

（一定程度上相当于是一个指针，但又有一些区别）
  暂存区位于.git目录下的index文件，暂存区会记录 git add 添加文件的相关信息（文件名、大小），不保存文件实体，通过 id 指向每个文件的实体。使用 git status 可以查看暂存区的状态，暂存区标记了当前工作区中那些内容是被 git 管理的，当完成某个需求或者功能后需要提交代码，第一步就是通过 git add 先提交到暂存区。

3.Repository：本地仓库

  位于自己的本地计算机，本地仓库保存了被提交过的各个版本，比起工作区和暂存区的内容，它更旧一些。首先是 git commit（提交） 同步 index 的目录树到本地仓库，然后通过 git push（推送） 同步本地仓库到远程仓库。

4.Remote：远程仓库

  位于托管代码的服务器，远程仓库的内容能够被分布在多个地点的处于协作关系的本地仓库修改(能被本地修改）。比起本地仓库，远程仓库通常旧一些，因此本地仓库修改完之后需要同步到远程仓库。

（三）.Git 的工作流程

• 在工作区(Workspace)添加、修改文件；
• 将修改后的文件放入(add)暂存区域 index；
• 将暂存区域的文件提交(commit)到本地仓Repository；
• 将本地仓库的修改推送(push)到远程仓库Remote。
  

（四）.我的理解

1. 远程仓库 是一个虚拟的但又真实存在的地方（类似,不恰当地说的说是GIT网页）；

我们从远程仓库克隆到桌面上的某个文件夹下，该文件夹下就有了，如图

在这里有一个隐含文件，点击查看-隐含项目，发现多了一个.git文件,如下图所示；
在隐藏文件.git文件下有index文件，这个文件就是某种程度上所说的 暂存区 了；而整个.git文件就是一定程度上的 本地仓库 ；而 工作区 如下图所示：

2.当我们更改工作区上的某个文档，或添加了一个新文档时，把这些更改同步下来的过程所执行的流程其实是有差别的：

  （1）对于在工作区添加一个新文档或者在工作区中改动某个原有文档的内容（添加/删除一句新代码），把这个改动同步到远程仓库（执行提交，推送命令）
  ①提交的结果是把工作区的内容弄到本地仓库，是本地仓库与工作区保持一致，这其中又包括两部分（内容由工作区放到到暂存区index的过程；以及由 暂存区index到本地仓库 的过程）------（这样本地仓库就与工作区中所做的最新更改一致了）；
  虽然好像在电脑上用小乌龟提交好像一部到位了，但是实际也是执行了两步,只不过程序把这两步整合到了一起来执行了；
  如果是在命令行终端进行操作若选择在终端操作如果新增了一个文件，那么必须要用 git add 命令跟踪新文件，再用 git commit -m 命令提交暂存区的文件； 如果只是修改了已跟踪的文件，那么可以用 git commit --am 命令一起完成“提交文件到暂存区、提交暂存区的文件”（省略了 git add 命令）
  ②推送 命令的执行过程，执行结果是更改远程仓库的就内容，使其与本地仓库的新内容保持一致；

3.还原文件的操作“TortoiseGit ->还原（revert）”或者“TortoiseGit->获取(fetch)”、“TortoiseGit->合并(merge)”操作

  如果工作区中的重要文档由于手欠删除了，该怎么办；别急我们可以通过操作还原，虽然我们工作区中的内容删除了（之后没有提交），但是由于我们曾经将内容提交到了本地仓库（也曾经推送到了远程仓库），我们可以使用“TortoiseGit ->还原（revert）”功能，使本地仓库的内容重新回到工作区；

  如果工作区中的重要文档由于手欠删除了，删除之后执行了提交操作此时本地仓库的内容也被修改成了最新的样子；想要恢复只能通过远程仓库来恢复如初；①执行获取；②在执行合并，合并时会出现冲突（因为此时如果打开版本分支图的话发现远程落后于本地，只有本地落后于远程才可以执行合并操作），解决冲突后，执行合并，此时本地设备的工作区又恢复了；
注： 获取操作：使本地仓库与远程仓库做一个对比（因为有所修改）；合并操作：使本地仓库同步到远程仓库，如果使用乌龟来执行合并的话，还会默认悄悄执行了checkout操作；

4.在远程仓库直接修改，本地的设备想要实现同步可以执行获取与合并操作（“TortoiseGit->获取(fetch)”、“TortoiseGit->合并(merge)”）

  通过获取操作，发现设备上的工作区的内容并没有改变什么，再次执行合并操作，发现设备工作区的内容改变了。（获取操作：使本地仓库与远程仓库做一个对比（因为有所修改）；合并操作：使本地仓库同步到远程仓库，如果使用乌龟来执行合并的话，还会默认悄悄执行了checkout操作，使设备的工作区也得到了更新；如果在命令行终端操作，还是要认真执行每一步，每个操作）

（五）.如何将公共仓库中自己的分支克隆到本地，并往自己的分支上提交推送信息；（两种方式）

先新建自己的分支


点击克隆/下载按钮，复制；之后可以采用两种方式

（1）方式一

在桌面的一个指定文件夹下，右键->Git克隆，选中“分支”，在后面输入自己新建的的分支名称，最后点击“确定”即可；

（2）方式二

1.在桌面的一个指定文件夹下，右键->Git克隆，点击“确定”
2.打开设备指定文件夹下的工作区；右键->TortouseGit(T)->创建分支(B)
如下图，选择已创建的自己的工作区即可；

三.(GIT) HEAD、master 与 branch（Git分支管理相关概念及操作流程）

  这一节主要是几个概念的解释：HEAD、master 以及 Git 中非常重要的一个概念： branch。

（一）.引用：commit 的快捷方式

首先（我们克隆的是master分支），再看一次日志；执行命令：

git log

  第一行的 commit 后面括号里的 HEAD -> master, origin/master, origin/HEAD ，是几个指向这个 commit 的引用。
  在 Git 的使用中，经常会需要对指定的 commit 进行操作。每一个 commit 都有一个它唯一的指定方式(版本号（它的 SHA-1 校验和)，也就是上图中每个黄色的 commit 右边的那一长串字符)。两个 SHA-1 值的重复概率极低，所以你可以使用这个 SHA-1 值来指代 commit，也可以只使用它的前几位来指代它（例如第一个 78bb0ab7d541…16b77，你使用 78bb0ab 甚至 78bb 来指代它通常也可以），但毕竟这种没有任何含义的字符串是很难记忆的，所以 Git 提供了「引用」的机制：使用固定的字符串作为引用，指向某个 commit，作为操作 commit 时的快捷方式。

（二）.HEAD：当前 commit 的引用

  上一段里说到，图中括号里是指向这个 commit 的引用。其中这个括号里的 HEAD 是引用中最特殊的一个：它是指向当前 commit 的引用。所谓当前 commit这个概念很简单，它指的就是当前工作目录所对应的 commit（当前版本）。
  例如上图中的当前 commit 就是第一行中的那个最新的 commit。每次当有新的 commit 的时候，工作目录自动与最新的 commit 对应；而与此同时，HEAD 也会转而指向最新的 commit。事实上，当使用 checkout、reset 等指令手动指定 改变当前 commit 的时候，HEAD 也会一起跟过去 。
  总之，当前 commit 在哪里，HEAD 就在哪里，这是一个 永远自动指向当前 commit 的引用，所以你永远可以用 HEAD 来操作当前 commit。（ HEAD永远指向当前提交的版本，或者说指向本地仓库的当前版本）
  比如看下面：

  上面的(HEAD -> 分支4, origin/分支4）显示本地的分支4与远程的分支4是同一个级别；没有谁领先，谁落后；
  在git log 命令显示的日志里，(HEAD -> 分支4, origin/分支4）往下数几行还有(origin/分支3, 分支3)这说明分支4的版本领先于分支3；在版本分支图中是这样的：

（三）.branch（分支）

  HEAD 是 Git 中一个独特的引用，它是唯一的。而除了 HEAD 之外，Git 还有一种引用，叫做 branch（分支）。HEAD 除了可以指向 commit，还可以指向一个 branch（当从远程仓库的非主干分支克隆时HEAD会指向对应的分支），当它指向某个 branch的时候，会通过这个 branch 来间接地指向某个 commit；另外，当 HEAD 在提交时自动向前移动的时候，它会像一个拖钩一样带着它所指向的 branch 一起移动。如图


或者

  HEAD -> master 中的 master 就是一个 branch（分支） 的名字，而它左边的箭头 -> 表示 HEAD 正指向它（当然，也会间接地指向它所指向的 commit）。
  如果我在这时创建一个 commit，那么 HEAD 会带着 master 一起移动到最新的 commit：如上两图所示：

git commit

通过查看 git log，可以对这个逻辑进行验证：（红色的代表远程：远程origin指向master主分支；远程origin指向HEAD)

  从图中可以看出，最新的 commit 被创建后，HEAD 和 master 这两个引用都指向了它，而在上面第一张图中的后两个引用 origin/master 和 origin/HEAD 则依然停留在原先的位置（远程的版本没有变化，还是老版本）。

（四）.master: 默认 branch

  上面的这个 master ，其实是一个特殊的 branch：它是 Git 的默认 branch（俗称 主 branch / 主分支）。

所谓的「默认 branch」，主要有两个特点：
  1.新创建的 repository（仓库）是没有任何 commit 的。但在它创建第一个 commit 时，会把 master 指向它，并把 HEAD 指向 master。


  2.当有人使用 git clone 时，除了从远程仓库把 .git 这个仓库目录下载到工作目录中，还会 checkout （签出） master（把HEAD指向克隆下来的某个分支）
  （checkout 的意思就是把上一个 commit 作为当前 commit，把 HEAD 移动过去，并把工作目录的文件内容替换成这个 commit 所对应的内容）。

  另外，需要说一下的是，大多数的开发团队会规定开发以 master 为核心，所有的分支都在一定程度上围绕着 master 来开发。这个在事实上构成了 master 和其它分支在地位上的一个额外的区别。

（五）.branch 的通俗化理解

  尽管在 Git 中，branch 只是一个指向 commit 的引用，但它有一个更通俗的理解：你还可以把一个 branch 理解为从初始 commit 到 branch 所指向的 commit 之间的所有 commits 的一个「串」(branch翻译是一个分支，把它比喻成含有每次提交的版本的，由这些版本所穿起来的枝条或糖葫芦，每次只对一个版本（一个枝点）起作用）。例如下面这张图：

  master 的本质是一个指向 3 的引用，但你也可以把 master 理解为是 1 2 3 三个 commit 的「串」，它的起点是 1，终点是 3(master每次只能代表其中的一个具体版本）。
  这种理解方式比较符合 branch 这个名字的本意（branch 的本意是树枝，可以延伸为事物的分支），也是大多数人对 branch 的理解。不过如果你选择这样理解 branch，需要注意下面两点：
1.所有的 branch 之间都是平等的。

  例如上面这张图，branch1 是 1 2 5 6 的串，而不要理解为 2 5 6 或者 5 6 。其实，起点在哪里并不是最重要的，重要的是你要知道，所有 branch 之间是平等的，master 除了上面我说的那几点之外，并不比其他 branch 高级。这个认知的理解对于 branch 的正确使用非常重要。
2.branch 包含了从初始 commit 到它的所有路径，而不是一条路径。并且，这些路径之间也是彼此平等的。

  像上图这样，master 在合并了 branch1 之后，从初始 commit 到 master 有了两条路径。这时，master 的串就包含了 1 2 3 4 7 和 1 2 5 6 7 这两条路径。而且，这两条路径是平等的，1 2 3 4 7 这条路径并不会因为它是「原生路径」而拥有任何的特别之处。
  如果你喜欢用「树枝」的概念来理解 Git 的 branch，一定要注意上面说的这两点，否则在今后使用 branch 的时候就可能与出现理解偏差或者使用方式不当的问题。事实上我本人并不喜欢用这种方式来理解 branch，因为觉得它有点舍近求远的味道：我为了「直观」地思考，给它了一个形象的比喻，但由于它的本质含义其实更加简单，导致我的这种比喻反而增加了思考它时的复杂度，未免有点画蛇添足。不过这是我自己的感受，怎么理解 branch 是个个人偏好的问题，这两种理解方式你选一个喜欢的就好。

（六）.branch 的创建、切换和删除

创建 branch

  如果你想在某处创建 branch ，只需要输入一行 git branch 名称。例如你现在在 master 上：

  你想在这个 commit 处创建一个叫做 “feature1” 的 branch，只要输入：

git branch feature1

切换 branch

  不过新建的 branch 并不会自动切换，你的 HEAD 在这时依然是指向 master 的。你需要用 checkout来主动切换到你的新 branch 去：

git checkout feature1

然后 HEAD 就会指向新建的 branch 了：

  除此之外，你还可以用 git checkout -b 名称 来**把上面两步操作合并执行**。这行代码可以帮你用指定的名称创建 branch 后，再直接切换过去。还以 feature1 为例的话，就是：

git checkout -b feature1

在切换到新的 branch 后，再次 commit 时 HEAD 就会带着新的 branch 移动了：

而这个时候，如果你再切换到 master 去 commit，就会真正地出现分叉了：

git checkout master
...
git commit

删除 branch

  删除 branch 的方法非常简单：git branch -d 名称。例如要删除 feature1 这个 branch：

git branch -d feature1

需要说明的有两点：

1.HEAD 指向的 branch 不能删除。 如果要删除 HEAD 指向的 branch，需要先用 checkout 把 HEAD 指向其他地方。
2.由于 Git 中的 branch 只是一个引用，所以删除 branch 的操作也只会删掉这个引用，并不会删除任何的 commit。（不过如果一个 commit 不在任何一个 branch 的「路径」上，或者换句话说，如果没有任何一个 branch 可以回溯到这条 commit（也许可以称为野生 commit？），那么在一定时间后，它会被 Git 的回收机制删除掉。）
3.出于安全考虑，没有被合并到 master 的 branch 在删除时会失败（因为怕你误删掉「未完成」的 branch ）：

（七）.「引用」的本质

  所谓 「引用」（reference），其实就是一个个的字符串。这个字符串可以是一个 commit 的 SHA-1 码（例：c08de9a4d8771144cd23986f9f76c4ed729e69b0），也可以是一个 branch（例：ref: refs/heads/feature3）。
  Git 中的 HEAD 和每一个 branch 以及其他的引用，都是以文本文件的形式 存储在本地仓库 .git 目录中，而 Git 在工作的时候，就是通过这些文本文件的内容来判断这些所谓的「引用」是指向谁的。

（八）.小结

这一节介绍了 Git 中的一些「引用」：HEAD、master、branch。这里总结一下：
1.HEAD 是指向当前 commit 的引用，它具有唯一性，每个仓库中只有一个 HEAD。在每次提交时它都会自动向前移动到最新的 commit 。

2.branch 是一类引用。HEAD 除了直接指向 commit，也可以通过指向某个 branch 来间接指向 commit。当 HEAD 指向一个 branch 时，有commit 发生时，HEAD 会带着它所指向的 branch 一起移动。

3.master 是 Git 中的默认 branch，它和其它 branch 的区别在于：
①新建的仓库中的第一个 commit 会被 master 自动指向；
②在 git clone 时，会自动 checkout 出 master。

4.branch 的创建、切换和删除：
①创建 branch 的方式是 git branch 名称 或 git checkout -b 名称（创建后自动切换）；
②切换的方式是 git checkout 名称；
③删除的方式是 git branch -d 名称。

四.通过Git对比之前版本文档修改内容

（一）.比较修改文件的前后状态和内容

  （一）我们在本地设备的工作区中的一篇readme.txt文档修改后，不执行提交的步骤；打开命令行终端，定位到该工作区文件夹；(或者不用打开终端cmd，直接在对应的设备工作区文件夹中右键->Git Bush Here即可打开命令输入框）执行 git status 命令，查看结果：

F:\桌面\新建的第一个仓库\xinjiandediyigecangku>git status
On branch ruteng
Your branch is up to date with 'origin/ruteng'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

   git status 命令可以让我们时刻掌握仓库当前的状态，上面的命令告诉我们，readme.txt被修改过了，但还没有准备提交的修改。
  （二.1）然而虽然告诉我们readme.txt已经被修改了，但从上面并不能知道具体修改信息。所以这里我们需要一个命令:

git diff //查看difference

通过 git diff 帮助我们查看修改信息（我们把文档的结尾的1改成了2）
在git add和git commit -m""之前显示不同；

F:\桌面\新建的第一个仓库\xinjiandediyigecangku>git diff
diff --git a/readme.txt b/readme.txt
index af479ae..6178c1a 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1 +1 @@
-1111111111111111111111
\ No newline at end of file
+11111111111111111222222
\ No newline at end of file

  此时可以看到前面的加号或者减号，加号代表添加，减少代表删除这样就可以很清楚的了解都干了些什么，哪里更改了，哪里添加了什么内容。
（二.2）导出本地修改的 diff(本地修改了文件，还没有 git add ，可以这样导出到工作区的某个文档。先提前新建一个文档 diferent.pacth或者diferent.diff

git diff 【修改的文件或文件夹】>>【差异文件名称】

比如：

git diff readme.txt >> diferent.diff

或

git diff readme.txt >> diferent.pacth

实例：

Administrator@PC-20211208FFRJ MINGW64 /f/桌面/新建的第一个仓库/xinjiandediyigecangku (ruteng)
$ git diff readme.txt >> diferent.diff

Administrator@PC-20211208FFRJ MINGW64 /f/桌面/新建的第一个仓库/xinjiandediyigecangku (ruteng)
$ git diff readme.txt >> diferent.pacth

Administrator@PC-20211208FFRJ MINGW64 /f/桌面/新建的第一个仓库/xinjiandediyigecangku (ruteng)
$

就将更改的不同之处打印到了其他文档中了；
  （三）如果说对刚才的修改不满意，或者 想要撤销，也是可以的。可以直接执行以下命令即可：

git checkout --  .     //全部撤销；

git checkout <文件名称>    //有选择的撤销；

执行完后如果执行"git status"和"git diff"命令，提示没有任何修改；
如果再打开工作区文件发现没有修改，修改不存在；

  （四）知道了对readme.txt作了什么修改后，再把它提交到仓库就放心多了，提交修改和提交新文件是一样的两步（由工作区到暂存区、由暂存区到本地仓库）
①第一步是 git add

F:\桌面\新建的第一个仓库\xinjiandediyigecangku>git add readme.txt

再运行 git status 看看当前仓库的状态：

F:\桌面\新建的第一个仓库\xinjiandediyigecangku>git status
On branch ruteng
Your branch is up to date with 'origin/ruteng'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   readme.txt

这告诉我们将要被提交的修改包括readme.txt
②下一步，就可以放心地提交了：git commit -m" "

F:\桌面\新建的第一个仓库\xinjiandediyigecangku>git commit -m "add distributed"
[ruteng c75cf72] add distributed
 1 file changed, 1 insertion(+), 1 deletion(-)

提交后，可以用 git status 命令看看仓库的当前状态

F:\桌面\新建的第一个仓库\xinjiandediyigecangku>git status
On branch ruteng
Your branch is ahead of 'origin/ruteng' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

（五）提交成功后，可以使用 git log 来查看提交的日志。

$ git log
commit e50014b16fd482a5001f4327f9bbe26efbac1edd (HEAD -> ruteng)
Author: ZRT960730 <2453809943@qq.com>
Date:   Mon Mar 28 09:32:01 2022 +0800

    提交2-8

commit c30b8cb13dd209b919c26ef57b59721ae80b6deb (origin/ruteng)
Author: ZRT960730 <2453809943@qq.com>
Date:   Mon Mar 28 09:23:59 2022 +0800

    提交信息

  可以看到，每次提交的记录版本，这样就完成提交了。
  我们可以从上面的信息看到，有两行commit开头的，后面跟了很长的数，这就版本号，并且是唯一的，没有两个相同的版本。下面还有作者和日期的信息。
git log状态下退出方法：
①英文状态：q/Q 即可
②中文状态：q+回车
（六）再然后就可以推送到远程仓库了： “git push”

F:\桌面\新建的第一个仓库\xinjiandediyigecangku>git push
fatal: Custom certificate bundle not found at path: E:/TortoiseGit/Git閺堝秴濮熼崳銊ь伂/Git/mingw64/ssl/certs/ca-bundle.crt
fatal: Custom certificate bundle not found at path: E:/TortoiseGit/Git閺堝秴濮熼崳銊ь伂/Git/mingw64/ssl/certs/ca-bundle.crt
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 262 bytes | 262.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [GNK-6.3]
To https://gitee.com/zhang-ruteng/xinjiandediyigecangku.git
   f2fa106..c75cf72  ruteng -> ruteng

  再次用 git status 命令看看仓库的当前状态：

F:\桌面\新建的第一个仓库\xinjiandediyigecangku>git status
On branch ruteng
Your branch is up to date with 'origin/ruteng'.

nothing to commit, working tree clean

（七）版本退回（回到之前旧的版本）
  在平常的工作中，如果在之前的版本上进行了一次修改，后来在使用时出现了问题，那么此时就想要回到最初的那个版本，这时应该怎么办呢？版本回退可以解决这个尴尬的问题。
  查看版本日志，“git log”,从上面的信息看到，有两行commit开头的，后面跟了很长的数，这就是版本号，并且是唯一的，没有两个相同的版本。下面还有作者和日期的信息。
  版本回退就是根据版本号来实现的，需要执行命令"git reset --hard 版本号"(这里只需要版本号的前7位就可以啦)；如下所示：

Administrator@PC-20211208FFRJ MINGW64 /f/桌面/新建的第一个仓库/xinjiandediyigecangku (ruteng)
$ git reset --hard  e50014b16fd482a5001f4327f9bbe26efbac1edd
HEAD is now at e50014b 提交2-8

Administrator@PC-20211208FFRJ MINGW64 /f/桌面/新建的第一个仓库/xinjiandediyigecangku (ruteng)
$

  这时就已经回到指定的版本了，现在再来看下git log

  发现我们回到了该版本，打开日志，日志中该版本之后的几个版本都没有了，但是更早的版本还在；
  那么如何回到最新版呢？先来执行 git reflog ;

  执行之后，可以看到head的变化情况，第一行是表示当前的版本号。这时我们再用一次reset，将head指向第一次的版本，同时查看log，这时就回到第一次reset的状态了
（八）清除未追踪的文件
  通常在reset或者pull之后要做两件事情
a：将新添加且未追踪的文件删除（比如我在工作区新建一个xxx.txt文件,但是没有交到暂存库index中，此时该文件图标底部不带任何符号，称之为 未追踪文件；）
b：已追踪的文件有修改，但又不需要这些修改，将它们还原。
  这时用checkout是没办法删除掉的，需要使用 git clean -xf ;
1.例如：在工作区新建一个文本文件，没有提交到暂存区；那么这是一个未追踪文件，要将之删除" git checkout - - .“命令不可以，只能用” git clean -xf "命令，没有被追踪的文件，就被清理了；
2.在一个已追踪的文档里修改内容；想要还原，可以使用"git checkout – .“命令可以；使用” git clean -xf "命令不能完成；

小结：

1.要随时掌握工作区的状态，使用 git status 命令;
2.如果 git status 告诉你有文件被修改过，用 git diff 可以查看修改内容.
3.git add
  用来跟踪新文件并提交到暂存区或者将已跟踪的文件提交到暂存区
4.git commit -m" "
  提交暂存区到仓库区（本地仓库），引号内容为提交注释（必填），便于项目成员查看，将索引的当前内容与描述更改的用户和日志消息一起存储在新的提交中
5.git commit -am
  如果新增了一个文件，那么必须要用 git add 命令跟踪新文件，再用 git commit -m 命令提交暂存区的文件；
  如果只是修改了已跟踪的文件，那么可以用 git commit -am 命令一起完成“提交文件到暂存区、提交暂存区的文件”（省略了 git add 命令）。
6.如果我们在工作区新建了一个名字包含中文的文件，在查看状态"git status"时可以看到文件夹里有显示文件了，但是不支持中文,如下图：

$ git status
On branch ruteng
Your branch is up to date with 'origin/ruteng'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   "\347\273\203\344\271\240.txt"

no changes added to commit (use "git add" and/or "git commit -a")

没关系，这都不是问题，可以使用下面的命令：

git config --global core.quotepath false

随后再"git status"就OK了：

7.以上"git add"做法的上传只能上传一个文件,后面要加上要操作的具体文件名称，如"git add readme.txt"，如果在文件夹中有多个文件的话，要是一个一个上传的话，就有点不科学了。这里有一个命令可以将文件全部上传：git add -A；
8.用git命令，想看到自己的操作记录，则可以使用log与reflog，它两个的区别如下：
① git log 命令可以显示所有提交过的版本信息（不包括已经被删除的 commit 记录和 reset 的操作）；（如果感觉太繁琐，可以加上参数 --pretty=oneline，只会显示版本号和提交时的备注信息）
② git reflog 可以查看所有分支的所有操作记录（更加详细，数量也更加多，（包括已经被删除的 commit 记录和 reset 的操作）包括提交，回退的操作。一般用来找出操作记录中的版本号，进行回退，常用于恢复本地的错误操作；执行命令后从文件clone开始，所有的操作记录日志都有了。
③无论是log还是relog,最底下的是越老的版本信息；
9.推送时勾选force,强制推送（应用于本地落后于远程或本地与远程分道扬镳；且想要远程变成本地的版本）

五.git的终端基本操作命令

1. ls
   显示当前本地 工作区 有哪些文件
2. touch file.txt
   在工作区创建新文件file.txt；
3. git add file.txt
   将创建的新文件file.txt添加到暂存区；
   git add -A
   将所有的文件添加到暂存区；
   git add -u （用的少）
   他仅监控已经被add的文件（即tracked file），他会将被修改的文件提交到暂存区。add -u 不会提交新文件
4. git status
   查看状态；
5. git commit -m “备注内容”
   将暂存区的文件提交到本地仓库；
   git commit -am “内容备注”
   将已追踪的文件提交到本地仓库；
   在本地对分支4做出更改，一定要在定位到分支4的状态下执行提交，否则是无法定位到其他分支上；
6. git diff
   对工作区文档做出了修改，提交之前想看看修改了那些不同，将不同打印到终端；
   git diff readme.txt >> diferent.diff
   将我们在工作区对readme.txt更改的不同打印到diferent.txt中；
7. (1)必须是已追踪的文件
   git checkout – .
   全部撤销；
   git checkout readme.txt
   有选择的撤销，撤销对readme.txt文件做出的更改；（删除了也能通过此方法恢复）
   (2)必须是未追踪的文件（比如新建了一个文档，还没有追踪呢，误删，可以通过此方法来恢复）
   git clean -xf
8. git show
   列出最近一次的提交
9. （1）git log
   查看日志，不太详细；英文状态下q键退出日志状态；
   （2）git reflog
   查看日志，非常详细；
10. ① git push
       推送到远程仓库；（小乌龟时勾选force，则是强制推送）
       当远程领先于本地但是想要远程变成本地的版本，可以执行强制推送；
    ② git push origin 分支3
       把本地分支3的内容推送远程仓库；其他分支对应的远程仓库不会发生变化，远程只有分支3变了；
    ③ 当我 对分支4做出了更改，想把它推送上去：
       如果我此时定位到了分支3；则执行git push不成功（相当于还是推送分支3的内容）；要执行git push origin 分支4才能成功；
       如果定位到了分支4上，则无论哪种推送方式都可以推送成功；
11. git reset --hard 版本号
    退回到其他版本；
12. （小乌龟）推送时勾选force，强制推送（本地低于远程/本地与远程分道扬镳）
    （命令行终端） git push -f origin master （ git push -f 即可）
    注释： origin远程仓库名，master分支名，-f为force，意为：强行、强制。
13. git rm 666.txt
    删除工作区中已追踪的666.txt文件；
14. git merge 分支1
    两条本地分支的合并；
    此时定位到分支2上，执行以上命令，则把分支1合并到了分支2上；分支2变了，分支1还是原来的分支1，没有删除一直存在；
15. git branch 分支1
    创建分支1；
    git checkout 分支1
    切换到分支1；
    git checkout -b 分支2
    创建并且切换到分支2；
    git checkout -b A origin/A
    切下远端库A分支到本地库A分支（若本地A分支不存在，则自动新建）？
    git branch -d 分支1
    删除分支1
    git branch
    查看本地分支
    git branch -a
    查看远程分支；
16. git push --set-upstream origin 分支1
    将在本地创建的分支1推送到远端（在提交到本地之后再执行），这时远程就多出了一个分支：分支1；且分支1的内容与其他分支的内容相互独立，没有相互影响；
17. git pull 和git pull origin <某分支>
    在push 推送之前先pull一下（本地与远程的获取合并）：（将服务器项目与本地项目 拉取=获取+合并）了解远端的情况；（在多人维护时很有必要）主要是让本地的对远端的了解与远端的实际情况保持一致（因为git branch -a的结果并不一定是最新的）
      当远端比本地领先时，本地执行pull命令可以使本地与远端保持一样；
      当远端落后于本地时，在本地执行pull命令，是不能使本地变成与远端一致的；
      当在远端分支1修改了文件文档，想要把修改对应（映射）到本地和工作区（本地和工作区也更改的和远端一样了)使用 git pull 命令或者 git pull origin 分支1 命令时 都要在终端上定位到这个分支1上，否则不成功；
18. 删除远端分支2的操作：
    ①（删除本地分支）git branch -d 分支2
    ②（删除远端分支，并把结果推送到远端） git push origin --delete 分支2
19. vim 111.txt
    在终端打开文件；
    cat 111.txt
    把111.txt的内容打印到终端上；
20. git fetch
    获取 操作，在远端更改了分支1上的一个文件，这时回到本地，查看版本分支图，发现远程和本地还是同步的（远程应该领先于本地，但是没有），这是因为本地没有监视到远程的操作，需要git fetch （获取）一下远程的信息；
    git merge
    合并操作
    当要push推送本地到远程时，执行一次git pull可以，分别执行一次git fetch和git merge也可以；反正效果是一样的；
21. 冲突的产生及解决冲突
    情景一：多个分支代码合并到一个分支时；
    情景二：多个分支向同一个远端分支推送代码时；
      实际上，push操作即是将本地代码merge到远端库分支上。
      关于push和pull其实就分别是用本地分支合并到远程分支 和 将远程分支合并到本地分支
      所以这两个过程中也可能存在冲突。
    git的合并中产生冲突的具体情况：
    　　<1>两个分支中修改了同一个文件（不管什么地方）
    　　<2>两个分支中修改了同一个文件的名称
    两个分支中分别修改了不同文件中的部分，不会产生冲突，可以直接将两部分合并。
    解决冲突的方法
    情景一：在当前分支上，直接修改冲突代码 —> add —> commit。
    情景二：在本地当前分支上，修改冲突代码 —> add —> commit —> push
    注：借用vim或者IDE或者直接找到冲突文件，修改。
    情境1：
      在本地master分支上创建两个分支（分支1，分支2）我们改变分支1，分支2上的相同文件的相同部分的代码；然后让分支1，分支2分别于master分支合并；合并分支1（正常进行,没问题）；再合并分支2到master分支，这时就有冲突了；
      解决冲突：vim编辑器打开冲突的文件，更改里面的冲突（可以随意更改），更改完之后提交（add,commit），此时显示冲突已解决；然后就可以推送（push）到远程仓库了；
    情景2：
      我在远端仓库，更改分支1上的一个111.txt文件，再回到本地的工作区，更改分支1上的111.txt文件（更改的是相同的文件文档），提交（add，commit）；执行命令：拉取（pull），这时本地和远程在版本分支图中会分道扬镳，无法拉取了；这时远程和本地产生了冲突；
      要解决冲突，vim编辑器打开冲突文件，更改解决冲突（随意改），改完之后显示冲突解决了，再执行提交（add，commit）即可，再pull，推送（push），这时冲出解决了，远端也和本地保持一致了，完成了对文件的操作；
22. 倘若两个分支都提交了，且内容不一样，定位到那个分支上，桌面上的工作区的内容就是呢个节点的对应内容
23. 如何通过命令合并远程的两个分支（将测试1分支合并到master分支上）
    ①克隆master分支到本地；
    ②在本地新建一个与远程的测试1版本相同(被合并的版本)的测试1分支；
    git checkout -b 分支1 origin/分支1
    ③返回到master版本
    git checkout master
    ④把本地的测试1分支合并到master
    git merge 测试1
    然后解决冲突（同名文档要打开手动解决冲突，异名文件不用，最后直接提交即可解决冲突）
    ⑤把本地的master同步到远程（先git pull一下或者git fetch+git merge一下）
    git push origin master
    17.解决git每次提交、推送仓库都要输入用户名密码的解决方案
      每次推送gitl仓库的时候都会提示输入用户名密码，太烦人了，输个一两次的还好，但每次都输密码，确实有点浪费时间，所以在网上爬文也爬到了，就一行命令的事,记录一下吧!
      git可以支持在硬盘上以文件的形式存储明文密码;
    解决方案
    打开命令行，输入以下命令：

git config --global credential.helper store

  执行完毕会在在当前系统用户文件夹下生成一个名为 .git-credentials 的文件，如：C:\Users\Administrator.git-credentials，再次提交代码时，输入密码后会将用户名密码以明文的方式保存在其中。


  (不重要，重装系统之后终端再次执行代码即可)为了保证重装系统后也不必再次输入用户名密码，将这个文件移动到某个不被影响的路径下，如D盘之类的，通过建立硬链接的方式链接到用户文件夹下的.git-credentials文件，重装系统后再次执行以下上面的命令即可。