深入解析：【Git学习】入门与基础

Git的安装

Git 配置用户信息

Git 初始化本地仓库

Git 工作区、暂存区和版本库

Git 注册github账号、操作远程仓库

Git 是一个开源的分布式版本控制系统，可以有效、高速地处理项目版本管理。
版本控制：一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。
分布式：每个人的开发机上都有独立的版本库，开发者可以在自己的开发机管理代码版本。

Git的安装

Git官网：https://git-scm.com/
1.在Win上安装：下载二进制安装包，然后直接安装，一直下一步直到安装完成。

2.在Mac上安装：下载二进制安装包，然后直接安装，一直下一步直到安装完成。

查看是否安装成功：

Git 配置用户信息

配置用户信息：

$ git config --global user.name xxx
$ git config --global user.email xxxx.com
传递--global 选项则 Git 读写~/.gitconfig文件。

检查配置的用户信息：

$ git config --list

Git 初始化本地仓库

在工作区目录输入以下命令：

git init

Git 工作区、暂存区和版本库

工作区（Workspace）：放项目代码的地方，项目代码对应的文件。
暂存区（Index/Stage）：也叫索引，是一个文件，保存了下次将提交的文件列表信息。
本地仓库（Repository）：就是安全存放数据的位置，这里边有你提交的所有版本的数据。

Git的工作流程：
在工作区中添加、修改文件；
添加工作区的更改到暂存区；
将暂存区域的文件列表信息提交到本地仓库。

Git 跟踪文件

我们首先要确认本地工作区中有项目文件

使用 git status 命令查看文件当前状态

可以看到此时没有东西需要提交，工作tree是干净的
现在新建一个txt文件

echo hello,world > newfile.txt

现在可以观察到，该txt文件成功创建，现在我们在使用上述命令，查看状态：

现在我们看到有一个”未跟踪的“文件，我们要将该”未跟踪”状态修改为“跟踪”状态（就是将其放入缓存区，从而git就可以跟工作区、本地仓库做比对。）

那我们如何实现对文件的跟踪呢？
使用 git add 要跟踪的文件 这个命令就可以啦！

现在我们再打开git bash，使用上述命令：

我们可以看到，有to be committed 的标记，表示以放置缓存区，待提交状态
现在我们再来提交这个文件，使用 git commit -m '提交信息' 这个命令
其中，-m 表示对这个提交文件的作的注释后面单引号中的内容就是注释内容

使用命令后可以看到，当再次观察状态时，又恢复了初始的样子，clean表示已提交状态

Git 修改文件

现在我们需要实现修改工作区中的文件，可以有多种方法，我们可以在bash外直接打开文件修改内容，或者在bash中使用 vim命令对文件进行修改，我这里使用vim对文件进行修改，依旧是前文中新建的文件作为例子：

可以看到我在文件中添加了“hello,git！”的内容，现在我们再使用 git status查看文件状态：
出现了上述内容，一个待提交的，有修改动作的的未缓存文件（not staged：本地修改未添加至缓存区），好的，现在用我们之前学的内容，提交该文件至缓存区

然后再提交到本地仓库：

注意：git commit --amend
增补提交，会使用与当前提交节点相同的父节点进行一次新的提交，旧的提交将会被取消。

接着我们来查看提交记录，使用 git log命令来实现

提示：使用git log --oneline可以让每次的提交信息显示在一行

Git 删除文件

对于删除文件，可以直接在外部对文件右键删除，或者在bash中，使用 rm 要删除的文件 该命令

我们可以观察到，当删除文件后再查看状态，此时会有delete信息的提示，接着将其添加至缓存区并且提交。

我们还有一个命令，就是 git rm 文件，该命令不仅从工作区删除文件并且缓存区的也被删除。

Git 撤销本地文件的修改

如果我们对文件进行了修改操作，但是发现，还是原版的好，想要找回之间的内容，这时，我们可以使用git中的撤销操作，
git restore file 把文件从暂存区域复制到工作目录，用来丢弃本地修改
这里我们先新建了a.txt文件，接下来使用vim在文件中进行一些修改接下来我们使用撤销命令，

可以看到成功实现了撤销操作。与此命令类似，还有一种命令：
git checkout -- file 把文件从暂存区域复制到工作目录，用来丢弃本地修改，这里不再演示。

提示：checkout的功能很多，从 Git 2.23 版本开始引入了两个新的命令： git switch 用来切换分支，git restore用来还原工作区的文件。
提示：从暂存区恢复工作区数据的前提是，暂存区有对应数据。

Git 取消暂存

git restore --staged file 恢复暂存区，也就是丢弃add到暂存区的状态，是将内容从本地仓库恢复到暂存区。

git reset -- file 恢复暂存区，也就是丢弃add到暂存区的状态，是将内容从本地仓库恢复到暂存区。

注意：以上恢复暂存区的操作不影响工作区。

Git 跳过暂存区

这里的跳过暂存区不是不使用暂存区的意思，而是将暂存和提交两个动作合在一体实现，从而跳过git add步骤

git commit aa.txt -m '提交信息' //提交aa.txt
git commit -a -m '提交信息'  //提交当前目录下所有跟踪的文件

注意：使用-a跳过git add步骤的前提是这些待提交的数据，是已跟踪过的。-a不会自动将未跟踪文件变为已跟踪。

Git 版本回退

版本回退就是将暂存区回退到指定版本，并且删除之前的所有提交信息，我们可以通过
git reset [回退版本] 该命令实现

这里的[回退版本]我们有两种对象使用，一种是commit标识串，还有一种就是HEAD
如果使用commit

回退版本可以用commit标识中的前几位符号表示，如回退到图中时间更早的版本，就可以这么来写，git reset 9541

如果使用HEAD，HEAD表示指向当前分支(后面会讲),当前分支指向最新的提交

git reset HEAD
git reset HEAD^ 回退到上一个版本
git reset HEAD1 回退到上一个版本

HEAD 说明：
HEAD 表示当前版本
HEAD^ 上一个版本
HEAD^^ 上上一个版本
HEAD^^^ 上上上一个版本
以此类推...
可以使用～数字表示
HEAD~0 表示当前版本
HEAD~1 上一个版本
HEAD~2 上上一个版本
以此类推...

还有一种功能，就是数撤销工作区中所有未提交的修改内容，将暂存区与工作区都回到上一次版本，并删除之前的所有信息提交。对于这种，我们可以通过：
git reset --hard HEAD 来实现

Git 撤销提交

有时候我们提交了文件，但是后来发现，这个最新提交有些问题，需要撤回并且重新提交，对于这种问题，我们可以使用：
git revert HEAD 来实现撤销提交，HEAD表示撤销最新的提交，HEAD^或者HEAD1表示撤回前一次提交。

对于这个命令，还可以添加参数-n，表示撤销最新提交，但执行命令后不进入编辑界面，也就是不会自动帮你提交文件，需要手动提交。
git revert -n HEAD

Git 设置忽略文件

一般我们总会有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。在这种情况下，我们可以创建一个名为.gitignore的文件，列出要忽略的文件模式。

格式规范
所有空行或者以注释符号＃开头的行都会被 Git 忽略
可以使用标准的 glob 模式匹配
匹配模式最后跟斜杠(/)说明要忽略的是目录
要忽略指定模式以外的文件或目录，可以在模式前加上感叹号(!)进行取反
glob模式：所谓的 glob 模式是指 shell 所使用的简化了的正则表达式，匹配规则如下：
"*"：星号匹配零个或多个任意字符。
[]：匹配任何一个列在方括号中的字符，如[ab]匹配a或者匹配b。
"?"：问号匹配一个任意字符。
[n-m]：匹配所有在这两个字符范围内的字符，如[0-9]表示匹配所有0到9的数字。
匹配示例：
logs/：忽略当前路径下的logs目录或多级路径下的logs目录，包含logs下的所有子目录和文件。
/logs.txt：忽略根目录下的logs.txt文件。
*.class：忽略所有后缀为.class的文件。
!/classes/a.class：不忽略classes目录下的a.class文件。
tmp/*.txt：只忽略tmp目录下的.txt文件。
**/foo：可以忽略/foo, a/foo, a/b/foo等。

下面做个实操测试一下忽略文件，先随便创建一个空文件夹，打开bash，init初始化git仓库

然后，再新建一个空文件夹，命名为test，在这个空文件夹中，新建一个.txt文件，我们通过新建设置.gitignore文件来忽略此.txt文件。

现在设置gitignore文件：

打开文件并编辑，按照规范设置忽略哪些文件：

这里表示忽略test文件内所有.txt文件，现在我们在bash中查看git状态，理论上，应该检查不到.txt文件了。

可以看到，成功的忽略了目标文件。

Git 比较文件差异

有时候我们会把我们的代码修改后，与最新提交的代码相比较，对于这种问题，我们可以使用：
git diff 这条命令来实现：对比工作区跟暂存区的变化，显示未暂存的的改动
git diff --cached|--staged对比本地仓库最新版本跟暂存区的变化，显示未提交的改动。
git diff commit1 commit2对比本地仓库中俩个提交版本之间的差异,显示commit2在commit1基础上的改动。

Git 代码托管平台

目前我们使用到的git命令是都是在本地执行，如果你想通过 Git 分享你的代码或者与其他开发人员合作，你就需要将数据放到一台其他开发人员能够连接的服务器上，托管在这台服务器上的数据的就是我们的远程仓库。

在使用远程仓库之前，我们首先要创建仓库，创建仓库有很多种，这里常见的有：自己搭建的Git服务器，安装如GitLab的Git版本管理系统，或者使用第三方托管平台(国内的/国外的)。

常用的托管服务平台（这些代码托管平台，都是基于git技术来实现的）

GitHub (地址: https://github.com/)是一个面向开源及私有软件项目的托管平台，因为只支持Git作为唯的版本库格式进行托管，故名GitHub。
码云（地址: Gitee - 基于 Git 的代码托管和研发协作平台）是国内的一个代码托管平台，由于服务器在国内，所以相比于 GitHub，码云速度会更快。
GitLab (地址: https://about.gitlab.com/) 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。

这里以国内的码云平台为例子，注册并创建远程仓库

第一步：打开码云网址，并注册https://gitee.com/

第二步：填写信息，点击立即注册：
第三步：注册成功，登录后来到主页
第四步：创建远程仓库
第五步：填写仓库信息

第六步：创建远程仓库成功

第七步：设置仓库可见权限

到此为止，在码云平台的git远程仓库就算创建成功了，后面再讲，如何将本地仓库和远程仓库联系起来。

Git 本地添加远程仓库

在本地仓库添加远程仓库之前，要事先创建好远程仓库。对于本地仓库，先使用 git init 初始化本地仓库，初始化完成之后，开始为本地添加远程仓库，。可以使用如下命令来实现：

git remote add
// shortname:远程仓库的简称，自定义；
// url:远程仓库的地址

提示：可以在.git/config文件中查看远程仓库的信息

对于添加的原车仓库，我们可以使用git remote 来查看远程仓库

如果要删除远程仓库时，可以使用git remote rm 远程仓库名 来实现
【注意：该操作是在本地上移除与远程仓库的联系，并不是将远程仓库从平台上移除】

将远程仓库代码拉取到本地仓库：git pull <远程主机名> <远程分支名>

将本地仓库代码推送到远程仓库：git push <远程主机名> <本地分支名>:<远程分支名>
【如果本地分支(branch name 后面会讲)与远程分支名相同，则可以省略冒号】
git push <远程主机名> <本地分支名>

Git 克隆/推送代码

克隆就是

将远程仓库(如GitHub，GitLab上的代码库)完整下载到本地，包括代码，历史记录和分支，打个比方就是，就像下载一个游戏的安装包到你的电脑，之后你可以离线修改游戏内容。

例子：

git clone https://github.com/用户名/仓库名.git

推送就是将你本地的代码修改上传到远程仓库，让其他人能看到你的改动

git push origin 分支名

首先我们需要知道远程仓库地址，然后复制到剪贴板

然后在本地工作目录中打开git bash，输入克隆远程仓库的命令， git clone 远程仓库url

更改本地工作区的文件，并且完成本地的工作流

然后推送本地仓库到远程仓库 git push

Git 拉取：git pull 将远程仓库的数据拉取到本地进行合并
git pull <remote> <branch>
【要直接使用git pull时，要确保设置了跟踪信息】

我们可以通过在输入上述命令之后再输入以下命令，来设置跟踪信息：

git branch --set-upstream-to=origin/master

Git 抓取（git fetch）：将远程仓房的数据拉取本地，但是不会自动合并
【必须注意 git fetch 命令会将数据拉取到本地 - 它并不会自动合并或修改本地的工作。当准备好时可以使用git merge手动合并】

git merge orgin/master

Git 合并冲突

Git 合并冲突（Merge Conflict） 是指当 Git 无法自动合并不同分支（或同一分支的不同提交）的代码修改时，需要手动解决冲突的情况。通常发生在多人协作或同时修改同一文件的同一部分代码时。

为什么会发生冲突？
场景1：你和同事同时修改了同一个文件的同一行代码。
场景2：你删除了某个文件，而同事修改了该文件。
场景3：你从远程拉取代码（git pull）时，远程分支的修改和你的本地修改冲突。
Git 无法自动判断该保留谁的修改，于是标记为冲突，需要你手动处理。

冲突的表现：冲突的文件中会包含类似这样的标记：

>>>>>> branch-name

<<<<<<< HEAD 到 ======= 之间是你的代码。
======= 到 >>>>>>> branch-name 之间是别人的代码。

那我们如何去解决这些冲突？
首先，找到冲突文件，运行git status，Git会提示哪些文件有冲突（Unmerged paths）。
然后，手动编辑文件，打开冲突文件，根据需求选择：

保留你的代码：删除别人的代码和冲突标记（<<<<<<<, =======, >>>>>>>）。
保留别人的代码：删除你的代码和冲突标记。
合并两者：手动调整代码，保留需要的部分。

接着，标记冲突已解决：将修改后的文件添加进暂存区并提交

git add 冲突文件名
git commit -m "解决合并冲突"

最后，将已经修改后的文件推送到远程仓库，git push
【提示：我们要养成推送之前，先拉取代码的习惯，防止覆盖合作者的代码。】

Git 注册github账号、操作远程仓库

之前我们操作的是国内的码云平台，现在我们来操作国外的github平台

先打开github网址https://github.com/ 点击注册【网址由于在国外有可能打不开，需要魔法上网】

填写信息：

填写完信息后,点击验证：

点击create account

然后去你填写的邮箱查看激活码：

填写激活码后，进入github首页：

接着创建远程仓库：

填写仓库信息

创建成功

打开工作目录，克隆远程仓库

在本地添加文件，并且提交到本地仓库

然后推送到远程仓库

可以看到推送成功！

Git 使用SSH协议

之前本地仓库跟远程仓库数据的传递使用的是https协议，需要用户名跟密码进行身份验证。我们还可以使用SSH协议，配置一次，以后每次再传递数据就不需要再使用用户名跟密码进行认证了。

什么是SSH协议？

SSH为Secure Shell(安全外壳协议)的缩写，由IETF的网络小组(Network Working Group)所制定。SSH是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用SSH协议可以有效防止远程管理过程中的信息泄露问题。

先在本地生成一对私钥公钥：

ssh-keygen -t rsa

先以码云平台设置SSH为例子：
先打开码云平台，进入设置：

点击安全设置里的SSH公钥

填写公钥，点击确定

填写当前登录账号的密码进行验证：

打开仓库，复制ssh协议的仓库地址

然后再进行克隆，推送操作。

以上是在国内的代码暂存平台，接下来测试GitHub上如何使用SSH。

不管在什么平台上使用SSH协议都要事先在本地上生成私钥公钥，然后配置在平台上。

首先打开github网址，登录进入设置区域，如下所示：

在右边导航栏中找到有SSH标识的区域：

然后新建SSH公钥：

最后复制SSH协议的地址，进行数据传递，拉取，图送等操作。

Git分支

Git中的分支，起始本质上就是一种指向commit对象的可变指针。Git会默认使用master作为分支

分支在每次提交的时候都会自动向前移动，在进行了若干次提交后，你其实已经有了一个指针指向最后一次提交的对象的分支。

那我们可以在当前分支上再创建一个新的分支吗？当然可以，可以使用如下的命令实现：
git branch 新建分支名称：这会在当前分支指向的commit对象上新建一个新的分支指针

注意： Git 中的分支实际上仅是一个包含所指对象校验和（40 个字符长度 SHA-1 字串）的文件。

我们为什么要使用分支呢？

一般我们的项目会有：

生产分支，专门用来上线，这里的代码必须是经过测试定版的，比较稳定。（一般为master分支）。
开发分支，生产分支的平行分支，专门用于后续的开发，或仅用于稳定性测试，一旦进入某种稳定状态，便可以把它合并到 master 里。（一般为develop分支）
功能分支，从develop分支创建，开发人员在这个分支上完成功能模块代码，提测的时候合并到develop分支。（名称一般由这次的开发功能自定义）

工作场景：开发人员在某个功能分支正在编写代码，突然接到一个电话说线上有个很严重的问题需要紧急修补，这个时候我们面临的问题：当前的功能代码不能提交到线上，所以不能在当前分支进行bug修复。

返回到原先已经发布到生产服务器上的分支
为这次紧急修补建立一个新分支，并在其中修复问题
通过测试后，回到生产服务器所在的分支，将修补分支合并进来，然后再推送到生产服务器上
切换回之前实现新需求的分支，继续工作。

Git HEAD与分支

在git中，有一个指向你正在工作中的本地分支的指针，叫做HEAD。如果我们只有一个默认的master分支，则HEAD就会指向master分支。

如果有多个分支，我们切换工作分支时，HEAD指针也会随之变化，指向我们当前正在工作的分支

那我们如何切换分支呢？
我们可以使用 git checkout 分支名称这条命令来实现HEAD指向目标分支进行工作

在新分支上工作时，比如在testing分支上进行提交，则HEAD也会随着分支一起向前移动，如下图显示，

我们现在再切换到原来的master分支，HEAD指针也会移动到master分支：

注意：切换分支，除了HEAD指针发生移动之外，工作目录中的文件也会换成当前分支所指向的commit版本。

Git 分支的管理

新建本地分支：git branch <分支名>

【注意：新建分支之前至少有一个已存在的分支】

查看本地所有分支：git branch

【注意：master分支前的 * 表示当前所在的分支】

查看各个分支最后一个提交对象的信息：git branch -v

切换分支：git checkout <分支名>

【注意：切换分支后，本地工作区的工作内容也会更换】

新建并且切换分支：git checkout -b feature

删除分支：git branch -d <分支名>

Git 合并分支

我们先创建新的分支，命名为iss53

git checkout -b iss53

然后在新的分支工作区提交内容

git commit -am ''

最后将新分支的提交合并到原来的分支：git merge <被合并的分支>
【注意：要先切换到被合并的分支】

git checkout master

git merge iss53

然后删除没有用的分支：

git branch -d iss53

Git 合并分支冲突

Git 合并分支冲突是指当你在尝试合并两个分支时，Git 无法自动决定如何合并某些文件的修改，需要你手动介入解决的情况。

那为什么会发生分支合并冲突呢？

冲突通常发生在以下情况：

同一文件的同一部分在两个分支中都被修改了
一个分支删除了文件，而另一个分支修改了该文件
两个分支对同一文件的同一行做了不同的修改

冲突的本质：Git 的冲突不是错误，而是 Git 的一种保护机制

当 Git 可以明确知道如何合并时（比如一个分支修改了文件A，另一个分支修改了文件B），它会自动合并
当 Git 不确定应该保留哪个修改时（比如两个分支都修改了文件A的同一行），它会标记为冲突，让你来决定

冲突的直观表现为：在代码文件中，冲突会表现为特殊标记，如下所示：

>>>>>> branch-name

为什么需要解决冲突？

保证代码正确性：自动合并可能会产生不符合预期的结果
保持代码一致性：需要人工确认合并后的代码逻辑是否正确
避免引入错误：防止自动合并导致的语法错误或逻辑错误

现在我制造一个分支合并冲突事件：

先基于master分支，新建开发分支dev，并切换到该分支中

git checkout -b dev

然后使用分支切换代码，更改本地文件
突然接到新的需求,需要更改线上bug，提交dev分支的本地工作，并且切换到master分支

git checkout master

基于master分支，新建bug修复分支hotfix

git checkout -b hotfix

在hotfix分支，修复bug，修复完成，提交，切换回master分支，将hotfix分支的提交合并到master分支

git checkout master
git merge hotfix

切换回dev分支，继续工作，工作完成后提交：

git checkout dev

切换回master分支，合并dev分支到master分支

git checkout master
git merge dev

这时候就会产生分支合并冲突

提示：可以使用git status查阅未合并的冲突

Git 储藏（git stash)

有的时候我们需要从当前正在工作的这个分支，切换到其它分支去解决问题，要切换到其它分支，我们可以先将当前的工作分支的本地修改进行提交，如果说你不想提交，你的代码并没有写完，这个时候我们还可以把当前分支的本地修改暂时储藏起来，让它的工作区保持干净，这样就可以切换到别的分支了。将来我们还可以把储藏起来的更改进行恢复，从而继续之前的工作。

储藏当前的修改git stash

再次切换分支，成功

取出之前储藏的修改，即恢复dev分支的本地工作git stash apply 先切换到dev分支

Git 远程分支_本地分支区别

远程分支（remote branch）是对远程仓库中的分支的索引。它们是一些无法移动的本地分支，远程分支就像是书签，提醒着你上次连接远程仓库时上面各分支的位置。

我们用 (远程仓库名)/(分支名)这样的形式表示远程分支。

在本地我们只能移动本地master分支，不能移动远程分支origin/master。、

例子：先从远程仓库克隆项目到本地
在本地master分支修改内容，提交后，本地master分支移动，origin/master分支保持不变。

只有跟服务器通信，远程分支origin/master分支才会移动，比如其他人往远程仓库推送了代码，则远程仓库中，master分支向前移动，我们可以通过 git fetch 获取远程仓库库的最新数据。

通过git merge orgin/master将远程分支的变更合并到本地master分支。

Git 创建远程仓库的分支

创建远程仓库的分支有两种方法，一种是从本地向远程仓库推送分支，步骤如下：
现在本地新建分支feature_user
推送本地分支到远程仓库 git push 远程仓库名本地分支名：远程分支名

git push origin feature_user
//远程分支名跟本地分支名相同，所以采用简写

其他协作的小伙伴通过git fetch获取远程仓库的分支
通过远程仓库分支创建本地分支 git checkout -b 本地分支远程分支

git checkout -b feature_user origin/feature_user

提示：通过git checkout -b 本地分支名远程分支名创建的本地分支会自动跟踪远程分支。也可以先在本地新建feature_user分支，然后git fetch获取最新数据，再通过git merge origin/feature_user手动合并到本地分支，但需要手动跟踪远程分支。
设置跟踪分支 git branch --set-upstream-to=origin/develop develop

第二种方法是在远程仓库之间新建分支

通过git fetch拉取远程仓库最新数据，并获取远程分支
通过基于远程分支创建本地分支或者新建本地分支再合并的方式开始开发

Git 删除远程分支

当我们的某个分支已经合并到了master分支，并且之后也不会继续在该分支上进行开发使用，则可以从远程仓库把该分支删除掉，避免杂乱的分支管理。

在托管平台直接删除：

在本地通过命令删除git push 远程仓库名 --delete 分支名

【提示：删除远程分支，会将本地远程分支这个指针跟服务器上面的对应分支删除掉，本地分支不会被删除】

Git 标签概念

什么是标签
标签可以是一个对象（带注解标签），也可以是一个简单的指针（不带注解标签），用来标注某次提交对象。
- 如果只是一个简单的指针，则它就相当于一个不会移动的分支。
- 如果是一个对象，则除了保存指向的提交对象的信息之外，还会保存是谁打的标签，什么时间，还可以保存注解信息。（推荐使用）
为什么使用标签
我们可以为重要的版本（某个里程碑）打上标签，相当于为这次提交记录指定一个别名，方便提取文件。比如人们在发布某个软件版本（比如 v1.0 等等）的时候，经常这么做。
标签跟分支的区别
分支会跟着我们的提交移动，指向最新的提交对象，但是标签不会移动，它就是指向某个固定的提交对象。