Git版本控制工具详解（二）

Git版本控制工具详解（一）https://developer.aliyun.com/article/1470455

(理解)Git远程仓库-常见的Git服务器和远程仓库

什么是远程仓库？

• 什么是远程仓库（Remote Repository）呢？

• 目前我们的代码是保存在一个本地仓库中，也就意味着我们只是在进行本地操作
• 在真实开发中，我们通常是多人开发的，所以我们会将管理的代码共享到远程仓库中

• 那么如何创建一个远程仓库呢？

• 远程仓库通常是搭建在某一个服务器上的（当然本地也可以，但是本地很难共享）
• 所以我们需要在Git服务器上搭建一个远程仓库

• 目前我们有如下方式可以使用Git服务器：

• 使用第三方的Git服务器：比如GitHub、Gitee、Gitlab等等
• 在自己服务器搭建一个Git服务(使用Gitlab软件，跟上面的Gitlab是不一样的)

远程仓库的验证

• 常见的远程仓库有哪些呢？目前比较流行使用的是三种：

• GitHub：https://github.com/
• Gitee(国内用的较多，现在这个创建开源项目很麻烦)：https://gitee.com/
• 自己搭建Gitlab：http://152.136.185.210:7888/

• 对于私有的仓库我们想要进行操作，远程仓库会对我们的身份进行验证：

• 如果没有验证，任何人都可以随意操作仓库是一件非常危险的事情

• 目前Git服务器验证手段主要有两种：

• 方式一：基于HTTP的凭证存储（Credential Storage）
• 方式二：基于SSH的密钥

• 具体讨论一下这两种方式的验证规则和过程

(掌握)Git远程仓库-远程仓库的创建和验证方式

设置模板里面我们通常会选择Readme.md(自述文件)，其他两种通常是开源会选的

git clone "https://gitee.com/XiaoYu-2002/Latest-front-end-Notes.git"//HTTP地址私人仓库需要验证
git clone "git@gitee.com:XiaoYu-2002/Latest-front-end-Notes.git"//SSH
//通常进公司第一件事情就是克隆下来代码

(掌握)Git远程仓库-验证方式-凭证

远程仓库的验证 – 凭证

• 因为本身HTTP协议是无状态的连接，所以每一个连接都需要用户名和密码：

• 如果每次都这样操作，那么会非常麻烦
• 幸运的是，Git 拥有一个凭证系统(账号密码其实也算一种凭证)来处理这个事情

• 下面有一些 Git Crediential 的选项：

• 选项一：默认所有都不缓存。 每一次连接都会询问你的用户名和密码
• 选项二：“cache” 模式会将凭证存放在内存中一段时间。 密码永远不会被存储在磁盘中，并且在15分钟后从内存中清除
• 选项三：“store” 模式会将凭证用明文的形式存放在磁盘中，并且永不过期(不安全)
• 选项四：如果你使用的是 Mac，Git 还有一种 “osxkeychain” 模式，它会将凭证缓存到你系统用户的钥匙串中（加密的）
• 选项五：如果你使用的是 Windows，你可以安装一个叫做 “Git Credential Manager for Windows” 的辅助工具
  可以在 https://github.com/Microsoft/Git-Credential-Manager-for-Windows 下载

git config credential.helper//检查我们电脑是否有Git Credential Manager for Windows这个工具
//如果 git config credential.helper 命令返回的结果是 "manager"，这可能意味着你之前设置了 Git 凭据管理器作为凭据帮助程序。"manager" 实际上是 wincred 凭据帮助程序的别名，它会将 Git 凭据存储在 Windows 凭据管理器中

git config credential.helper 是 Git 的一个配置命令，它的作用是配置 Git 的认证帮助程序（credential helper），用于处理 Git 账户的凭据管理和认证。

Git 用于和远程 Git 仓库交互的协议通常需要进行身份认证，比如使用 HTTPS 或 SSH 连接到 Git 服务器。在使用 Git 进行 push、pull 等操作时，用户需要提供用户名和密码等凭据来进行身份验证，而 credential.helper 可以帮助我们管理这些凭据。

通过设置 credential.helper，Git 将会调用一个外部的认证帮助程序来管理凭据，从而实现自动化身份认证。常见的凭据帮助程序有：

• cache：将凭据缓存到内存中一段时间，减少重复输入密码的次数。
• store：将凭据保存在明文文件中，不建议在安全性较高的环境中使用。
• wincred：将凭据保存在 Windows 凭据管理器中，可以避免密码泄露。

例如，通过执行以下命令可以将 credential.helper 设置为使用 Windows 凭据管理器：

这样，Git 就会将凭据存储在 Windows 凭据管理器中，避免了密码泄露的风险，并且可以避免频繁地输入密码。

git config --global credential.helper wincred

(掌握)Git远程仓库-验证方式-SSH密钥

远程仓库的验证 – SSH密钥

• Secure Shell（安全外壳协议，简称SSH）是一种加密的网络传输协议，可在不安全的网络中为网络服务提供安全的传输环境
• SSH以非对称加密实现身份验证

• 例如其中一种方法是使用自动生成的公钥-私钥对来简单地加密网络连接，随后使用密码认证进行登录
• 另一种方法是人工生成一对公钥和私钥，通过生成的密钥进行认证，这样就可以在不输入密码的情况下登录
• 公钥需要放在待访问的电脑之中，而对应的私钥需要由用户自行保管

意思就是电脑生成一对公私钥，私钥自己保存，公钥交出去给服务器。然后等要访问服务器的时候，会将电脑上的私钥自动去匹配服务器上的公钥。这串公私钥是非对称加密的

• 如果我们以SSH的方式访问Git仓库，那么就需要生产对应的公钥和私钥：

ssh-keygen -t ed25519 -C "XiaoYu20020805@gmail.com"//现在更多使用这种方式
//ssh-keygen -t ed25519 -C "your email" 是用于生成 ed25519 算法的 SSH 密钥。ed25519 是一种非对称加密算法，可以用于在计算机之间建立安全连接。该命令将生成一个 ed25519 密钥对，其中包括一个私钥和一个公钥。私钥将保存在你的本地计算机上，而公钥可以在需要访问的服务器上安装，方便你可以通过 SSH 连接到该服务器
ssh-keygen -t rsa -b 2048 -C "XiaoYu20020805@gmail.com"
//sh-keygen -t rsa -b 2048 -C "your email" 是用于生成 RSA 算法的 SSH 密钥。RSA 是一种非对称加密算法，也可用于在计算机之间建立安全连接。该命令将生成一个 RSA 密钥对，其中包括一个私钥和一个公钥。私钥将保存在你的本地计算机上，而公钥可以在需要访问的服务器上安装，以便你可以通过 SSH 连接到该服务器
//这两个命令中的 -C 参数是用于添加注释，以标识密钥的拥有者。"XiaoYu20020805@gmail.com" 应替换为你的电子邮件地址(一般也填这个)

有上面框框里面的那些就是我们的公私钥已经生成好了，在资源管理器的如下地址中可以找到我们的公私钥

打开PUB这个文件，拿到里面的公钥内容。然后去我们的平台设置公钥

输入密码即可验证成功

• 这样我们就能够直接使用SSH的方式进行克隆私有仓库的代码git clone "SSH地址"
• 写完内容，直接git push就能更新服务器中的内容了

(掌握)Git远程仓库-远程仓库的添加和同步

管理远程服务器

• 查看远程地址：比如我们之前从GitHub上clone下来的代码，它就是有自己的远程仓库的：

git remote
git remote –v
-v是—verbose的缩写(冗长的)

• 添加远程地址：我们也可以继续添加远程服务器（让本地的仓库和远程服务器仓库建立连接）：

这个 Git 命令用于将一个远程 Git 仓库与本地 Git 仓库建立连接，让你可以从本地 Git 仓库向远程 Git 仓库推送代码或者从远程 Git 仓库拉取代码到本地 Git 仓库

git remote add <shortname> <url>
//<shortname> 是给远程 Git 仓库指定的一个简短的别名，方便在以后的 Git 命令中使用，比如通常用 "origin" 来作为默认的远程仓库的别名。
//<url> 是远程 Git 仓库的 URL 地址，可以是 HTTPS 或 SSH 协议的地址。
  
git remote add gitlab http://152.136.185.210:7888/coderwhy/gitremotedemo.git
//这样就可以在以后的 Git 命令中使用 "gitlab" 这个别名来代替远程 Git 仓库的 URL 地址了

• 重命名远程地址：

git remote rename gitlab glab

• 移除远程地址：

git remote remove gitlab

远程仓库的交互

• 从远程仓库clone代码：将存储库克隆到新创建的目录中；

git clone "地址"

• 将代码push到远程仓库：将本地仓库的代码推送到远程仓库中；

• 默认情况下是将当前分支（比如master）push到origin远程仓库的

git push
//这个命令将本地代码库中的修改上传到远程代码库。如果你之前使用过 git clone 或者 git remote add 命令，那么在执行 git push 时就会将本地代码库中的内容推送到默认的远程代码库中
git push origin master
//这个命令将本地代码库中的修改上传到名为 origin 的远程代码库中的 master 分支。如果你有多个远程代码库，那么可以使用 git remote 命令来查看它们的名称，并将 origin 替换为你想要推送到的远程代码库的名称
//在执行这些命令之前，你需要先使用 git add 和 git commit 命令将本地的修改保存到本地代码库中。这样才能通过 git push 命令将这些修改推送到远程代码库中

• 从远程仓库fetch代码：从远程仓库获取最新的代码

• 默认情况下是从origin中获取代码

git fetch
git fetch origin

• 获取到代码后默认并没有合并到本地仓库，我们需要通过merge来合并

git merge//merge中文意思：合并

• 从远程仓库pull代码：上面的两次操作有点繁琐，我们可以通过一个命令来操作(代码合并)

git fetch//将代码从服务器拿下来(放在仓库里，而不是我们编写的代码里)
git merge//跟我们当前编写的代码做出合并
git pull = git fetch + git merge//合二为一(拉下来合并)
git push//提交代码(将代码推到仓库)
//以上4个就是平时最常用的命令

(理解)Git远程仓库-fetch和merge遇到的问题处理

我们git init初始化一个本地仓库，这个时候我们的本地文件内容还没有放进去本地仓库里面(就是没有进行跟踪)，文件的右边有个U意思是untracked(未跟踪)

第一步：git add.将其进行添加进去本地仓库(跟踪)，这个时候状态变成了A

第二步：第一次提交git commit -m "初始化项目"

这个时候，我们当前的本地仓库还没有跟远程仓库建成连接

第三步：使用命令git remote add "给本地仓库起名，通常origin" "远程仓库连接"建立起本地仓库和远程仓库的连接

使用git remote -v就可以看到我们所连接的远程仓库都有哪些了

第四步：这里如果使用git pull就会报错，目前知道我们的分支是master(GitHub默认分支是main)，但是真正开发的时候还会有其他的分支(本地仓库有多个分支，远程仓库也可以多个分支)

那我们就可以开始解决报错问题了：已知我们本地的分支是master，注意第三步中我们只是建立起本地仓库跟远程仓库的连接，但是没有说跟远程仓库的哪个分支进行连接

//指定拉取(pull)远程仓库某个分支的内容
git push origin master
//这个命令将本地代码库中的修改上传到名为 origin 的远程代码库中的 master 分支。如果你有多个远程代码库，那么可以使用 git remote 命令来查看它们的名称，并将 origin 替换为你想要推送到的远程代码库的名称

注意：

在 Git 2.28 及之前的版本中，新创建的本地仓库默认分支名为 master。但是自 Git 2.28 版本开始，Git 的默认分支名已经被更改为 main，这是为了避免与潜在的不包容性语言相关的术语有关(master有主人的意思，为了避免种族歧视，所以后续就修改掉了)。

因此，如果你的 Git 版本在 2.28 及之前的版本，那么在初始化新的本地仓库时，默认分支名将是 master。如果你使用的是 Git 2.28 或更新版本，则默认分支名将是 main。不过，在初始化仓库时，你可以指定任何分支名作为默认分支。例如，使用以下命令可以在初始化时指定分支名为 XiaoYu：

git init --initial-branch=XiaoYu//branch的中文意思：分支

指定上游分支(什么是上游分支，我们在接下来会进行讲解)

git branch --set-upstream-to=origin/master
//返回branch 'master' set up to track 'origin/master'，也就是'master'分支已经去跟踪'origin'的master分支了
git pull//此时直接执行pull命令就不会报错了

本地分支的上游分支（跟踪分支）

• 问题一：当前分支没有track的分支

• 原因：当前分支没有和远程的origin/master分支进行跟踪

• 在没有跟踪的情况下，我们直接执行pull操作的时候必须指定从哪一个远程仓库中的哪一个分支中获取内容

• 如果我们想要直接执行git fetch是有一个前提的：必须给当前分支设置一个跟踪分支：

在 Git 中，"upstream branch" 指的是与当前本地分支所跟踪的远程分支相关联的远程分支。换句话说，它是一个与当前本地分支相关联的远程分支，它被用来同步远程分支和本地分支之间的代码更改。

当你克隆一个 Git 仓库时，通常会自动创建一个默认的本地分支，它会跟踪克隆时指定的远程分支，这个远程分支就是这个本地分支的上游分支。

如果你的本地分支没有跟踪任何远程分支，那么它就没有上游分支。在这种情况下，你需要手动设置远程分支作为本地分支的上游分支。可以使用以下命令来设置本地分支的上游分支：

这个命令会将当前所在分支的上游分支设置为指定的远程分支。

有了上游分支，你可以使用 Git 命令比如 git fetch 和 git pull 来从远程仓库获取最新的代码，并将其合并到本地分支。同时，你也可以使用 git push 将本地分支的更改推送到上游分支。

上游分支是 Git 中一个非常重要的概念，它帮助我们更好地管理本地分支和远程分支之间的同步

git branch --set-upstream-to=<remote-branch>

拒绝合并不相干的历史

• 问题二：合并远程分支时，拒绝合并不相干的历史

• 原因：我们将两个不相干的分支进行了合并：

• https://stackoverflow.com/questions/37937984/git-refusing-to-merge-unrelated-histories-on-rebase

• 简单来说就是：过去git merge允许将两个没有共同基础的分支进行合并，这导致了一个后果：新创建的项目可能被一个毫不怀疑的维护者合并了很多没有必要的历史到一个已经存在的项目中，目前这个命令已经被纠正，但是我们依然可以通过--allow-unrelated-histories选项来逃逸这个限制，来合并两个独立的项目

(理解)Git远程仓库-远程仓库总结和公司开发流程

• 情况1：你到公司之后公司有项目了，并且有远程仓库了

1. git clone "xxx"，先把公司的代码拉下来
2. 进行开发：

• git add(跟踪本地仓库)
• git commit "提交"
• git push(提交代码，在这之前最好先git pull一下，将最新代码拉去下来合并，不然同事可能已经传递一些东西上去了)

• 情况2：开发一个全新的项目(由你来搭建)

• 方案1：创建远程仓库

• 首先需要有个远程仓库 => 创建一个远程仓库
• git clone克隆下来，在克隆下来的文件夹中搭建整个项目
• git add .对项目进行跟踪。git commit -m，将项目提交到暂存区
• git push将代码提交到远程仓库

• 方案2：创建一个本地仓库和搭建本地项目

• git remote add origin "项目地址"将本地仓库跟远程仓库建立连接
• git branch --set-upstream-to=origin/master将本地仓库跟远程仓库的某个分支建立连接
• git fetch拉下全新的代码，然后git merge --allow-unrelated-histories合并代码
• git push提交代码

(掌握)GitHub-GitHub的作用和查找开源项目

GitHub：全球最优秀也是最强大的程序员交流平台，开源平台

需要一点点手段才能够正常使用这个网站(手段教不了)，要么就换个时间段登录(打不开的情况)。注册账号的话自己CSDN看看怎么注册的

搜索对应的源码通过git clone克隆下来学习

git服务器

(理解)GitHub-创建开源项目和开源协议

开源协议的不同选择，决定了别人使用我们这个仓库的程度最多能到达什么程度

常见的开源协议

(掌握)GitHub-Gitlab的常见操作演练

Gitlab的创建仓库界面

GitHub的SSH公钥上传跟gitee差不多

大量实际操作需要自己看一下

Git标签（tag） - 删除和检出tag

• 删除本地tag：

• 要删除掉你本地仓库上的标签，可以使用命令 git tag -d

• 删除远程tag：

• 要删除远程的tag我们可以通过git push  –delete

• 检出tag：

• 如果你想查看某个标签所指向的文件版本，可以使用 git checkout 命令
• 通常我们在检出tag的时候还会创建一个对应的分支（分支后续了解）

(理解)GitHub-push操作的默认行为

git push origin master//用于将本地代码仓库的 master 分支推送（push）到远程代码仓库的 origin 主机上
//git push 命令用于将本地代码仓库中的代码上传到远程代码仓库，而 origin 表示远程代码仓库的主机名，而 master 表示本地代码仓库中的主分支。因此，git push origin master 的意思是将本地代码仓库中的 master 分支推送到远程代码仓库的 origin 主机上
----------------------------------------
git push origin master:main
//意思是将本地代码仓库中的 master 分支推送到远程代码仓库的 main 分支上。这个命令会将本地的 master 分支的代码推送到远程代码仓库的 main 分支，并覆盖远程分支上的所有内容。通常，这个命令用于在本地的 master 分支上进行开发，然后将更改推送到远程仓库的 main 分支上
git push origin head:main//head默认情况下就是指向master的
//将当前分支的代码推送到远程代码仓库的 main 分支上。这个命令会将本地当前分支的代码推送到远程代码仓库的 main 分支，并覆盖远程分支上的所有内容。与上一个命令不同的是，这个命令可以用于推送任何本地分支的更改，而不仅仅是 master 分支
//在使用这些命令之前，我们需要确保本地代码仓库和远程代码仓库进行了正确的关联，并且有权限将代码推送到远程仓库。另外，如果远程代码仓库中不存在指定的远程分支，则 Git 会自动创建一个新的分支并将代码推送到该分支上

• git push的默认设置行为：

• git config push.default simple，什么都不写的情况下默认是simple
• git config push.default.upstream，修改为upstream
• git config push.default.current，修改为current

• 如果设置为 upstream（或者是其同义词 tracking），则表示 git push 命令将只推送当前分支所跟踪的远程分支（也就是 upstream 分支）。例如，如果当前本地分支是 feature，并且它跟踪的远程分支是 origin/feature，那么运行 git push 命令时，Git 将只会推送本地 feature 分支的更改到 origin/feature 分支上。
• 如果设置为 simple，则表示 git push 命令将只推送当前分支所跟踪的远程分支，但是会限制推送操作的条件，即只有在当前分支的 upstream 分支是远程代码库中存在的分支，并且本地分支与 upstream 分支同名时，才能成功执行推送。这样可以避免误推送到错误的分支。
• 如果设置为 matching，则表示 git push 命令将推送所有与本地分支同名的远程分支。例如，如果当前本地分支是 feature，那么运行 git push 命令时，Git 将会尝试推送所有名为 feature 的远程分支。
• git config push.default.current 是 Git 中的一个配置选项，它指定了在不带任何参数的情况下使用 git push 命令时应该如何处理推送操作。具体来说，这个配置项的含义如下：

• 如果设置为 current，则表示 git push 命令将只推送当前分支到远程仓库中同名的分支。例如，如果当前本地分支是 feature，那么运行 git push 命令时，Git 将只会推送本地 feature 分支的更改到远程仓库的 feature 分支上。

这种配置相对于其他选项来说比较简单明了，但需要注意的是，这种配置有一定的危险性，因为如果你误操作了，可能会不小心把本地分支的修改推送到了错误的分支上。因此，建议在使用 git push

命令时要慎重考虑是否使用该选项，并根据实际情况选择合适的推送策略。

需要注意的是，从 Git 2.0 版本开始，push.default 配置项的默认值被改为 simple。因此，如果没有显式地设置该配置项，那么默认情况下 git push 命令将使用 simple 模式进行推送操作

cat .git/config
//作用：用于查看当前 Git 仓库的配置信息。在 Git 中，每个仓库都有一个 .git 目录，其中包含了该仓库的所有信息，包括对象库、配置文件等
//在 Git 中，配置信息被存储在 .git/config 文件中，这个文件是每个仓库都独立存在的。使用 cat .git/config 命令可以打印出这个文件的内容，从而查看该仓库的配置信息，包括如下内容：
//仓库的名称和描述
//远程仓库的信息，如 URL 和分支映射
//分支的信息，如跟踪的远程分支、合并方式等
//用户的身份信息，如用户名、邮箱等
//Git 的行为配置，如行为、合并策略等
//通过查看 .git/config 文件，你可以了解该仓库的配置信息，包括远程仓库的地址、分支信息、用户名等，以及 Git 的行为配置，这对于理解 Git 的行为和解决一些问题是很有帮助的

(掌握)git-tag-tag的使用过程

Git标签（tag） - 创建tag

• 对于重大的版本我们常常会打上一个标签，以表示它的重要性：

• Git 可以给仓库历史中的某一个提交打上标签
• 比较有代表性的是人们会使用这个功能来标记发布结点（ v1.0 、 v2.0 等等）
• 这样方便进行版本回退

• 创建标签：

• Git 支持两种标签：轻量标签（lightweight）与附注标签（annotated）
• 附注标签：通过-a选项，并且通过-m添加额外信息

• 默认情况下，git push 命令并不会传送标签到远程仓库服务器上

• 在创建完标签后你必须显式地推送标签到共享服务器上，当其他人从仓库中克隆或拉取，他们也能得到你的那些标签

git push 远程仓库别名 推送的版本

Git标签（tag） - 删除和检出tag

• 删除本地tag：

• 要删除掉你本地仓库上的标签，可以使用命令 git tag -d
  

• 删除远程tag：

• 要删除远程的tag我们可以通过git push  –delete
• --delete可以简写为-d

• 检出tag：(查看当前所有的tag)

• 如果你想查看某个标签所指向的文件版本，可以使用 git checkout 命令
• 通常我们在检出tag的时候还会创建一个对应的分支（分支后续了解）

(理解)git的提交对象和底层原理

当你git init初始化一个新的仓库的时候，还没有进行跟踪，只有如下两个文件

当你进行git add.进行全部跟踪之后，多出来的两个文件夹。两个文件夹里面是二进制文件

git cat-file -t 00xx，其中xx是指00文件夹里面的二进制文件名字前面几个字母数字内容，通常就写四五个，达到没有跟当前文件夹其他的二进制文件重复就行。

• git cat-file 命令是一个多功能命令，可以用来查看 Git 对象的内容、类型和大小等信息。其中 -t 选项表示查看对象的类型（type），而 00xx 则是要查看的对象的 SHA-1 值
• 通过查看对象类型，可以帮助我们更好地了解 Git 中的对象模型和数据结构，以及更好地理解 Git 内部是如何存储和管理版本控制数据的

git cat-file -p 00xx，跟上面的区别是一个-p，另一个-t。那他们的区别是什么？

• -p 选项表示打印对象的内容（payload），也就是打印出该对象存储的实际数据。这通常是一段文本，它的格式取决于对象的类型。例如，如果指定的对象是一个提交对象（commit object），那么执行 git cat-file -p 00xx 命令会输出该提交对象的元数据（如作者、提交日期等）以及提交消息。如果指定的对象是一个文件对象（blob object），那么执行相同的命令会输出该文件的内容。
• -t 和 -p 选项在作用上是不同的，前者用于查看对象的类型，而后者用于查看对象的实际内容。两个选项的选择取决于你想要查看的信息类型Git提交对象（Commit Object）
• 当你在跟踪的基础上使用git commit -m "初始化项目"提交一次代码到暂缓区后，又会多出来两个文件，如果我们对这多出来的两个文件用刚刚的git cat-file -p xxxx来查看的话

我们查看到的内容是上一个跟踪的文件索引还有类型以及对应的文件。那多出来的另外一个文件放的是什么？是我们真正的提交文件

让我们进行观察一下就能发现规律

• 几乎所有的版本控制系统都以某种形式支持分支。

• 使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线

• 在进行提交操作时，Git 会保存一个提交对象（commit object）：

• 该提交对象会包含一个指向暂存内容快照的指针；
• 该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针

首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象
而由多个分支合并产生的提交对象有多个父对象

Git版本控制工具详解（三）https://developer.aliyun.com/article/1470457