基础篇
git commit 提交
git branch xx 创建分支
git checkout xx 切换分支
git checkout -b xx 创建并切换到分支xx
git merge 合并分支 每个分支上各有一个独有的提交
git rebase 取出提交记录并复制 将当前记录取出并复制到main分支之后
高级篇
HEAD是对当前分支的符号引用 指向正在工作的提交记录
相对引用
- 使用
^向上移动 1 个提交记录 - 使用
~<num>向上移动多个提交记录，如~3
所以 main^ 相当于"main 的 parent 节点"。
main^^ 是 main 的第二个 parent 节点
git checkout HEAD^
git checkout ~
强制修改分支位置
git branch -f main HEAD~3
上面的命令会将 main 分支强制指向 HEAD 的第 3 级 parent 提交。
撤销修改
git reset 回退提交记录
git reset HEAD~1
git revert HEAD 撤销修改并分享给别人
这是因为新提交记录 C2' 引入了更改 ------ 这些更改刚好是用来撤销 C2 这个提交的。也就是说 C2' 的状态与 C1 是相同的。
revert 之后就可以把你的更改推送到远程仓库与别人分享啦。
!\[Pasted image 20250612105839.png]
移动提交记录
Git Cherry-pick 将其他分支的提交记录复制到当前指针开始的分支上
git rebase -i
杂项
tag
它们可以（在某种程度上 ------ 因为标签可以被删除后重新在另外一个位置创建同名的标签）永久地将某个特定的提交命名为里程碑，然后就可以像分支一样引用了。
更难得的是，它们并不会随着新的提交而移动。你也不能切换到某个标签上面进行修改提交，它就像是提交树上的一个锚点，标识了某个特定的位置。
describe
由于标签在代码库中起着"锚点"的作用，Git 还为此专门设计了一个命令用来描述 离你最近的锚点（也就是标签），它就是 git describe！
高级话题
选择 parent 提交记录
操作符 ^ 与 ~ 符一样，后面也可以跟一个数字。
但是该操作符后面的数字与 ~ 后面的不同，并不是用来指定向上返回几代，而是指定合并提交记录的某个 parent 提交。还记得前面提到过的一个合并提交有两个 parent 提交吧，所以遇到这样的节点时该选择哪条路径就不是很清晰了。
Git 默认选择合并提交的"第一个" parent 提交，在操作符 ^ 后跟一个数字可以改变这一默认行为。
远程篇
git clone
远程分支命名规范：
/
远程仓库名origin 分支名 master
远程分支有一个特别的属性，在你切换到远程分支时，自动进入分离 HEAD 状态。Git 这么做是出于不能直接在这些分支上进行操作的原因, 你必须在别的地方完成你的工作, （更新了远程分支之后）再用远程分享你的工作成果。
fetch
从远端数据库获取数据
git fetch 完成了仅有的但是很重要的两步:
- 从远程仓库下载本地仓库中缺失的提交记录
- 更新远程分支指针(如
o/main)
git fetch只是下载，不会修改本地文件
当远程分支中有新的提交时，你可以像合并本地分支那样来合并远程分支。也就是说就是你可以执行以下命令:
git cherry-pick o/maingit rebase o/maingit merge o/main- 等等
实际上，由于先抓取更新再合并到本地分支这个流程很常用，因此 Git 提供了一个专门的命令来完成这两个操作。它就是我们要讲的git pull。
git pull就是git fetch +git merge
git push 上传代码
git pull --rebase就是fetch 和rebase的简写
pull操作，提交记录会被先下载到o/main上，在合并到本地的Main分支
push操作吧工作从main推送到远程仓库Main(同时更新远程分支o/main)
当你克隆时, Git 会为远程仓库中的每个分支在本地仓库中创建一个远程分支（比如 o/main）。然后再创建一个跟踪远程仓库中活动分支的本地分支，默认情况下这个本地分支会被命名为 main。
克隆完成后，你会得到一个本地分支（如果没有这个本地分支的话，你的目录就是"空白"的），但是可以查看远程仓库中所有的分支（如果你好奇心很强的话）。这样做对于本地仓库和远程仓库来说，都是最佳选择。
这也解释了为什么会在克隆的时候会看到下面的输出：
local branch "main" set to track remote branch "o/main"Git 是通过当前所在分支的属性来确定远程仓库以及要 push 的目的地的。这是未指定参数时的行为，我们可以为 push 指定参数，语法是：
git push <remote> <place>
<place> 参数是什么意思呢？我们稍后会深入其中的细节, 先看看例子, 这个命令是:
git push origin main
把这个命令翻译过来就是：
切到本地仓库中的"main"分支，获取所有的提交，再到远程仓库"origin"中找到"main"分支，将远程仓库中没有的提交记录都添加上去，搞定之后告诉我。
我们通过"place"参数来告诉 Git 提交记录来自于 main, 要推送到远程仓库中的 main。它实际就是要同步的两个仓库的位置。
需要注意的是，因为我们通过指定参数告诉了 Git 所有它需要的信息, 所以它就忽略了我们所切换分支的属性！
要同时为源和目的地制定的话，只需要用冒号：将二者连起来
git push origin :
git fetch
如下命令这样为 git fetch 设置 的话：
git fetch origin foo
Git 会到远程仓库的 foo 分支上，然后获取所有本地不存在的提交，放到本地的 o/foo 上。
"如果我们指定 <source>:<destination> 会发生什么呢？"
如果你觉得直接更新本地分支很爽，那你就用冒号分隔的 refspec 吧。不过，你不能在当前切换的分支上干这个事，但是其它分支是可以的。
这里有一点是需要注意的 ------ source 现在指的是远程仓库中的位置，而 <destination> 才是要放置提交的本地仓库的位置。它与 git push 刚好相反，这是可以讲的通的，因为我们在往相反的方向传送数据。
理论上虽然行的通，但开发人员很少这么做。我在这里介绍它主要是为了从概念上说明 fetch 和 push 的相似性，只是方向相反罢了。