git 在线练习

git 常见命令

git 配置信息

root@GoLang:~/proj/proj1/GoDistributeCache# git config --global --list
user.email=atticussiegfried@outlook.com
user.name=Simon

git commit

Git 仓库中的提交记录保存的是你的目录下所有（已跟踪）文件的快照，就像是把整个目录复制，然后再粘贴一样，但比复制粘贴优雅许多！

Git 希望提交记录尽可能地轻量，因此在你每次进行提交时，它并不会盲目地复制整个目录。条件允许的情况下，它会将当前版本与仓库中的上一个版本进行对比，并把所有的差异打包到一起作为一个提交记录。

Git 还维护了提交的历史记录。这也是为什么大多数提交记录上方都有 parent 节点 —— 我们会在图示中用箭头来表示这种关系。维护历史记录对项目中的每个参与者都有好处。

要理解的东西很多，但现在你可以把提交看作是项目的快照。提交非常轻量，而且在它们之间切换的速度快的惊人！

git branch

Git 的分支也非常轻量。它们只是简单地指向某个提交记录 —— 仅此而已。所以许多 Git 爱好者传颂：

早建分支！多用分支！

这是因为即使创建再多的分支也不会造成储存或内存上的开销，并且按逻辑分解工作到不同的分支要比维护那些特别臃肿的分支简单多了。

在将分支和提交记录结合起来后，我们会看到两者如何协作。现在只要记住使用分支其实就相当于在说：“我想基于这个提交以及它所有的 parent 提交进行新的工作。”

git checkout

注意：在 Git 2.23 版本中，引入了一个名为 git switch 的新命令，最终会取代 git checkout，因为 checkout 作为单个命令有点超载（它承载了很多独立的功能）

git switch 只负责“切换分支”，而 git checkout 是老的多功能命令，既能切分支，也能检出某个提交，还能把某些文件恢复成某个版本。官方文档也明确说，checkout 会根据你给的参数去“猜”你是想切分支、切到某个提交，还是恢复文件；而 switch 的职责更单一，就是切换分支或进入分离 HEAD 状态。

对了，有个更简洁的方式：如果你想创建一个新的分支同时切换到新创建的分支的话，可以通过 git checkout -b <your-branch-name> 来实现。

接下来咱们看看如何将两个分支合并到一起。就是说我们新建一个分支，在其上开发某个新功能，开发完成后再合并回主线。

git merge

咱们先来看一下第一种方法 —— git merge。在 Git 中合并两个分支时会产生一个特殊的提交记录，它有两个 parent 节点。翻译成自然语言相当于：“我要把这两个 parent 节点本身及它们所有的祖先都包含进来。”

git rebase

第二种合并分支的方法是 git rebase。Rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。

Rebase 的优势就是可以创造更线性的提交历史，这听上去有些难以理解。如果只允许使用 Rebase 的话，代码库的提交历史将会变得异常清晰。

咱们还是实际操作一下吧……

在提交树上移动

在接触 Git 更高级的一些功能之前，我们有必要先学习在你项目的提交树上前后移动的几种方法。

一旦熟悉了如何在 Git 提交树上移动，你驾驭其它命令的能力也将水涨船高！

HEAD

我们首先看一下 “HEAD”。 HEAD 是当前所在提交记录的符号名称 —— 它本质上标识着你正在其上工作的那个提交。

HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。

HEAD 通常情况下是指向分支名的（如 bugFix）。在你提交时，bugFix 的状态会被改变，且这一变化通过 HEAD 可见。

相对引用

通过指定提交记录哈希值的方式在 Git 中移动不太方便。在实际应用时，并没有像本程序中这么漂亮的可视化提交树供你参考，所以你得用 git log 来查看提交记录的哈希值。

并且哈希值在真实的 Git 世界中也会长得多（译者注：基于 SHA-1，共 40 位）。例如，添加上一关的那个提交的哈希值是 fed2da64c0efc5293610bdd892f82a58e8cbc5d8。舌头都快打结了吧…

好在 Git 对哈希值处理得很聪明。你只需要提供能够唯一标识提交记录的前几个字符即可。因此我可以仅输入 fed2，而不是上面的一长串。

正如我前面所说，通过哈希值指定提交记录并不是最方便的方式，所以 Git 提供了相对引用。这个就很厉害了!

使用相对引用的话，你就可以从一个易于记忆的地方（比如 bugFix 分支或 HEAD）开始计算，然后移动。

相对引用非常给力，这里我介绍两个简单的用法：

• 使用 ^ 向上移动 1 个提交记录
• 使用 ~<num> 向上移动多个提交记录，如 ~3

“^”操作符

“~”操作符

如果你想在提交树中向上移动很多步的话，敲那么多 ^ 貌似也挺烦人的，所以 Git 也引入了操作符 ~。

该操作符后面可以跟一个数字（可选），用于指定向上移动的次数。我们来看看它的实际效果。

强制修改分支位置

你现在是相对引用的专家了，现在用它来做点实际的事情。

我使用相对引用最多的方式就是移动分支。可以直接使用 -f 选项让分支指向另一个提交。例如:

git branch -f main HEAD~3

这条命令会将 main 分支强制指向 HEAD 的第 3 级 parent 提交。

注意：在真实的 Git 环境中，你当前所在的分支上不允许执行 git branch -f

测试

法1

法2

$ git branch -f main C6

$ git checkout bugFix~2

git branch -f bufFix HEAD~1

撤销变更

在 Git 里撤销变更的方法很多。和提交一样，撤销变更也由底层部分（暂存单个文件或代码块）和上层部分（变更实际如何被撤销）组成。我们的应用将聚焦于后者。

主要有两种方法用来撤销变更 —— 一是 git reset，还有就是 git revert。接下来咱们逐个进行讲解。

Git Reset

git reset 通过将分支引用向后移动至一个更早的提交来撤销变更。从这个意义上说，你可以把它理解为“改写历史”。git reset 会把分支向上移动，就好像之前指向的提交从未发生过一样。

Git Revert

虽然在你的本地分支中使用 git reset 很方便，但是这种“改写历史”的方法对大家一起使用的远程分支是无效的哦！

为了撤销更改并分享给别人，我们需要使用 git revert。

测试

移动工作

到目前为止，我们已经涵盖了 Git 的基础知识 —— 提交、分支以及在源码树中移动。仅凭这些概念就足以发挥 Git 仓库 90% 的强大功能，并满足开发者的主要需求。

然而, 剩余的 10% 在处理复杂的工作流时(或者当你陷入困惑时）可能就显得尤为重要了。接下来要讨论的这个话题是“移动工作” —— 换句话说，它能让开发者以一种精确、简洁且灵活的方式表达“我想要这个工作到这里，那个工作到那里”。

看起来挺复杂, 其实是个很简单的概念。

Git Cherry-pick

本系列的第一个命令是 git cherry-pick, 命令形式为:

• git cherry-pick <提交1> <提交2> <…>

这是一种非常直接的方式，用来表达你想将一些提交复制到当前所在的位置（HEAD）下面。我个人非常喜欢 cherry-pick，因为它几乎没什么魔法成分，而且很容易理解。

之后我会持续更新，如果喜欢我的文章，请记得一键三连哦，点赞关注收藏，你的每一个赞每一份关注每一次收藏都将是我前进路上的无限动力 ！！！↖(▔▽▔)↗感谢支持！