git学习

@git学习目录

git学习的网站项目

课程大纲

第一章基础篇

git commit

基本定义

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

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

Git 还保存了提交的历史记录。这也是为什么大多数提交记录的上面都有父节点的原因 —— 我们会在图示中用箭头来表示这种关系。对于项目组的成员来说，维护提交历史对大家都有好处。

关于提交记录太深入的东西咱们就不再继续探讨了，现在你可以把提交记录看作是项目的快照。提交记录非常轻量，可以快速地在这些提交记录之间切换！

初始状态

目标状态

流程

git commit
git commit

git branch

解释

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

早建分支！多用分支！

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

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

目标

初始状态

目标

操作

git branch bugFix
git checkout bugFix

流程

有个更简洁的方式：如果你想创建一个新的分支同时切换到新创建的分支的话，可以通过

git checkout -b <your-branch-name>

来实现。

git merge

分支与合并

好了! 我们已经知道如何提交以及如何使用分支了。接下来咱们看看如何将两个分支合并到一起。就是说我们新建一个分支，在其上开发某个新功能，开发完成后再合并回主线。

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

通过图示更容易理解一些，咱们到下一页看一下。

初始态

目标态

#六条指令方法git branch bugFix
git checkout bugFix
git commit 
git checkout main
git commit
git merge bugFix

流程

# 五条指令方法git checkout -b bugFix
git commit 
git checkout main
git commit
git merge bugFix 

git rebase

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

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

git rebase 和 git merge的联系

git rebase

和

git merge

都是用于将一个分支的更改合并到另一个分支的 Git 命令，但它们的工作原理和效果略有不同。

1. **git merge**：- git merge 会创建一个新的合并提交，将两个分支的更改合并起来。这个合并提交将有两个父提交，分别是要合并的两个分支的最新提交。- 合并后的历史将会有一个新的合并提交，显示了哪些更改来自于哪个分支。- 合并后的分支历史会保留每个分支的完整历史记录。使用方法：git checkout <目标分支>git merge <要合并的分支>
2. **git rebase**：- git rebase 会将当前分支的提交“重新播放”在目标分支的顶部。它会将当前分支的提交逐个应用到目标分支上，就好像这些提交是在目标分支上进行的一样。- 在 rebase 过程中，会产生一系列的临时提交，这些提交将被应用到目标分支上，最终形成一个线性的提交历史。- 相比于 merge，rebase 可以产生更加清晰的提交历史，但也可能会造成一些问题，特别是当 rebase 操作应用到已经推送到远程的提交时。使用方法：git checkout <要移动的分支>git rebase <目标分支>

因此，

git merge

会创建一个新的合并提交，而

git rebase

会将当前分支的提交应用到目标分支上，形成一个线性历史。选择使用哪个命令取决于你希望达到的合并结果和对提交历史的偏好。
初始

目标

流程

第二章

分离head

初始状态

目标

我们首先看一下 “HEAD”。 HEAD 是一个对当前检出记录的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。

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

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

解决流程

单步或者双步移动 git checkout head^ git checkout head^^

相对引用

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

git log

来查查看提交记录的哈希值。

并且哈希值在真实的 Git 世界中也会更长。例如前一关的介绍中的提交记录的哈希值可能是

fed2da64c0efc5293610bdd892f82a58e8cbc5d8

。

比较令人欣慰的是，Git 对哈希的处理很智能。你只需要提供能够唯一标识提交记录的前几个字符即可。因此我可以仅输入fed2 而不是上面的一长串字符。

通过哈希值指定提交记录很不方便，所以 Git 引入了相对引用。这个就很厉害了!

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

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

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

首先看看操作符 (^)。把这个符号加在引用名称的后面，表示让 Git 寻找指定提交记录的父提交。

所以

main^

相当于“main 的父节点”。

main^^

是 main 的第二个父节点

现在咱们切换到 main 的父节点

初始状态

目标态

流程

当你在 Git 中使用

^

符号时，它通常用于引用一个提交的父提交。以下是一些具体示例：

1. 引用当前提交的父提交：git show HEAD^
2. 引用当前提交的第二个父提交（通常用于合并提交）：git show HEAD^2
3. 引用当前提交的父提交的父提交（即父提交的父提交）：git show HEAD^^
4. 引用当前提交的祖父提交（即父提交的父提交的父提交）：git show HEAD~3

你也可以将

^

符号与提交的哈希值或者分支名、标签名一起使用。例如，假设你有一个名为

feature

的分支，你可以使用以下命令来引用

feature

分支上最新提交的父提交：

git show feature^

这些命令将显示相应提交的详细信息，包括提交哈希值、作者、提交消息等。

多步移动

上一节已经说过了~的相关知识

初始状态
目标态

git branch -f main c6
git checkout HEAD^
git branch -f bugFix bugFix~3

# 这里的git branch -f   操作点   目的点

原网站给的答案
git branch -f main C6

$ git checkout HEAD~1

$ git branch -f bugFix HEAD~1

#我不太喜欢这个答案，相对位置操作这个案例并不好

这个命令的含义是将

main

分支强制指向提交

c6

。具体来说，

git branch -f main c6

将会：

• 将 main 分支设置为指向提交 c6。
• 如果 main 分支已经存在，则它的指针将被移动到提交 c6，如果不存在则会创建一个新的 main 分支指向提交 c6。

需要注意的是，这是一个强制操作，会直接改变分支的指向，慎用此命令，特别是在公共仓库中。

撤销变更

在 Git 里撤销变更的方法很多。和提交一样，撤销变更由底层部分（暂存区的独立文件或者片段）和上层部分（变更到底是通过哪种方式被撤销的）组成。我们这个应用主要关注的是后者。

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

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

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

在我们要撤销的提交记录后面居然多了一个新提交！这是因为新提交记录 C2’ 引入了更改 —— 这些更改刚好是用来撤销 C2 这个提交的。也就是说 C2’ 的状态与 C1 是相同的。

c2’和c1的状态使一样的，会产生新的记录。

初始状态

目标态

$ git reset local^

$ git checkout pushed

$ git revert pushed

这是网站给的解决方式
$ git reset HEAD~1

$ git checkout pushed

$ git revert HEAD

第三章

整理提交记录

到现在我们已经学习了 Git 的基础知识 —— 提交、分支以及在提交树上移动。 这些概念涵盖了 Git 90% 的功能，同样也足够满足开发者的日常需求

然而, 剩余的 10% 在处理复杂的工作流时(或者当你陷入困惑时）可能就显得尤为重要了。接下来要讨论的这个话题是“整理提交记录” —— 开发人员有时会说“我想要把这个提交放到这里, 那个提交放到刚才那个提交的后面”, 而接下来就讲的就是它的实现方式，非常清晰、灵活，还很生动。

Git Cherry-pick

原状态
目标状态

操作流程

#上图操作步骤git cherry-pick c3 c4 c7

交互式的rebase

当你知道你所需要的提交记录（并且还知道这些提交记录的哈希值）时, 用 cherry-pick 再好不过了 —— 没有比这更简单的方式了。

但是如果你不清楚你想要的提交记录的哈希值呢? 幸好 Git 帮你想到了这一点, 我们可以利用交互式的 rebase —— 如果你想从一系列的提交记录中找到想要的记录, 这就是最好的方法了

初始态

目标态

界面交互式的确实比较好看一些
但用的少

操作

get rebase -i 一个祖先节点

本地栈式提交

++++++++++待续++++++++++++++++++++++++