Git命令大全或者使用Git命令操作也是Git命令总结

╰+哭是因爲堅強的太久メ 2021-09-21 14:54 398阅读 0赞

> **Git的学习总结**
> 
> 学习Git的网站为： [https://learngitbranching.js.org][https_learngitbranching.js.org]  闯关形式的学习方法，试用与电脑操作，手机端体验可能不佳
> 
> 学习过程中会不断的进行提示，演示，然后自己手动实操…很好的学习网站
> 
> 但是缺点也是有的，所有的一切都是闯关模式，对于想快速学习来说还是不太有好的，所以总结出里面的命令以供学习参考

###  网站中Git命令分为 主要 和 远程 两类 ###

**主要包括：基础篇、高级篇、移动提交篇、杂项、高级话题 其中又包含若干命令**

**远程包括： Push & Pull —— Git 远程仓库、 关于 origin 和它的周边 —— Git 远程仓库高级操作**

## 基础篇 ##

> ## Git Commit 提交修改 ##
> 
> Git 仓库中的提交记录保存的是你的目录下所有文件的快照，就像是把整个目录复制，然后再粘贴一样，但比复制粘贴优雅许多！
> 
> Git 希望提交记录尽可能地轻量，因此在你每次进行提交时，它并不会盲目地复制整个目录。条件允许的情况下，它会将当前版本与仓库中的上一个版本进行对比，并把所有的差异打包到一起作为一个提交记录。
> 
> Git 还保存了提交的历史记录。这也是为什么大多数提交记录的上面都有父节点的原因 —— 我们会在图示中用箭头来表示这种关系。对于项目组的成员来说，维护提交历史对大家都有好处。
> 
> 关于提交记录太深入的东西咱们就不再继续探讨了，现在你可以把提交记录看作是项目的快照。提交记录非常轻量，可以快速地在这些提交记录之间切换！

> ## Git Branch 新建分支 ##
> 
> Git 的分支也非常轻量。它们只是简单地指向某个提交纪录 —— 仅此而已。所以许多 Git 爱好者传颂：**早建分支！多用分支！**
> 
> 这是因为即使创建再多的分支也不会造成储存或内存上的开销，并且按逻辑分解工作到不同的分支要比维护那些特别臃肿的分支简单多了。
> 
> 在将分支和提交记录结合起来后，我们会看到两者如何协作。现在只要记住使用分支其实就相当于在说：“我想基于这个提交以及它所有的父提交进行新的工作。”

> ## git checkout 切换分支 ##
> 
> 下面的命令会让我们在提交修改之前先切换到新的分支上
> 
> git checkout newImage;

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

> ## Git Rebase 分支与合并 ##
> 
> 第二种合并分支的方法是 `git rebase`。Rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。
> 
> Rebase 的优势就是可以创造更线性的提交历史，这听上去有些难以理解。如果只允许使用 Rebase 的话，代码库的提交历史将会变得异常清晰。

## 高级篇 ##

> ## HEAD ##
> 
> 示例：
> 
>     #假设c2是一个节点，切换到c2的时候，HEAD指向也会更改为c2
>     git checkout c2
> 
> 我们首先看一下 “HEAD”。 HEAD 是一个对当前检出记录的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。
> 
> HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。
> 
> HEAD 通常情况下是指向分支名的（如 bugFix）。在你提交时，改变了 bugFix 的状态，这一变化通过 HEAD 变得可见。
> 
> 如果想看 HEAD 指向，可以通过 `cat .git/HEAD` 查看， 如果 HEAD 指向的是一个引用，还可以用 `git symbolic-ref HEAD` 查看它的指向。

> ## 相对引用 ##
> 
> 示例：
> 
>     #万能语句了，操作的是HEAD,我们可以一直使用 HEAD^ 向上移动【注意：HEAD一定要大写】
>     git checkout HEAD^
>     git checkout HEAD~3
>     #针对知道名称的
>     git checkout main^
>     git checkout main~3
> 
> 通过指定提交记录哈希值的方式在 Git 中移动不太方便。在实际应用时，并没有漂亮的可视化提交树供你参考，所以你就不得不用 `git log` 来查查看提交记录的哈希值。
> 
> 并且哈希值在真实的 Git 世界中也会更长（译者注：基于 SHA-1，共 40 位）。例如介绍中的提交记录的哈希值可能是 `fed2da64c0efc5293610bdd892f82a58e8cbc5d8`。舌头都快打结了吧...
> 
> 比较令人欣慰的是，Git 对哈希的处理很智能。你只需要提供能够唯一标识提交记录的前几个字符即可。因此我可以仅输入`fed2` 而不是上面的一长串字符。
> 
> 使用相对引用的话，你就可以从一个易于记忆的地方（比如 `bugFix` 分支或 `HEAD`）开始计算。
> 
> 相对引用非常给力，这里我介绍两个简单的用法：
> 
>  *  使用 `^` 向上移动 1 个提交记录
>  *  使用 `~<num>` 向上移动多个提交记录，如 `~3`

> ### 强制修改分支位置 ###
> 
> 你现在是相对引用的专家了，现在用它来做点实际事情。
> 
> 我使用相对引用最多的就是移动分支。可以直接使用 `-f` 选项让分支指向另一个提交。例如:
> 
> `git branch -f main HEAD~3`
> 
> 上面的命令会将 main 分支强制指向 HEAD 的第 3 级父提交。相对引用为我们提供了一种简洁的引用提交记录方式， 而 `-f` 则容许我们将分支强制移动到那个位置。

> ## 撤销变更 ##
> 
> 在 Git 里撤销变更的方法很多。和提交一样，撤销变更由底层部分（暂存区的独立文件或者片段）和上层部分（变更到底是通过哪种方式被撤销的）组成。我们这个应用主要关注的是后者。
> 
> 主要有两种方法用来撤销变更 —— 一是 `git reset`，还有就是 `git revert`。接下来咱们逐个进行讲解。
> 
> ### Git Reset ###
> 
> `git reset` 通过把分支记录回退几个提交记录来实现撤销改动。你可以将这想象成“改写历史”。`git reset` 向上移动分支，原来指向的提交记录就跟从来没有提交过一样。
> 
> ### Git Revert ###
> 
> 虽然在你的本地分支中使用 `git reset` 很方便，但是这种“改写历史”的方法对大家一起使用的远程分支是无效的哦！
> 
> 为了撤销更改并**分享**给别人，我们需要使用 `git revert`。revert 之后就可以把你的更改推送到远程仓库

## 移动提交记录 ##

> ## Git Cherry-pick ##
> 
> 本系列的第一个命令是 `git cherry-pick`, 命令形式为:
> 
>  *  `git cherry-pick <提交号>...`
> 
> 如果你想将一些提交复制到当前所在的位置（`HEAD`）下面的话， Cherry-pick 是最直接的方式了。我个人非常喜欢 `cherry-pick`，因为它特别简单。
> 
>     答案：    git cherry-pick c3 c4 c7

> ## 交互式的 rebase ##
> 
> 当你知道你所需要的提交记录（**并且**还知道这些提交记录的哈希值）时, 用 cherry-pick 再好不过了 —— 没有比这更简单的方式了。
> 
> 但是如果你不清楚你想要的提交记录的哈希值呢? 幸好 Git 帮你想到了这一点, 我们可以利用交互式的 rebase —— 如果你想从一系列的提交记录中找到想要的记录, 这就是最好的方法了
> 
> 交互式 rebase 指的是使用带参数 `--interactive` 的 rebase 命令, 简写为 `-i`
> 
> 如果你在命令后增加了这个选项, Git 会打开一个 UI 界面并列出将要被复制到目标分支的备选提交记录，它还会显示每个提交记录的哈希值和提交说明，提交说明有助于你理解这个提交进行了哪些更改。
> 
> 在实际使用时，所谓的 UI 窗口一般会在文本编辑器 —— 如 Vim —— 中打开一个文件
> 
> 当 rebase UI界面打开时, 你能做3件事:
> 
>  *  调整提交记录的顺序（通过鼠标拖放来完成）
>  *  删除你不想要的提交（通过切换 `pick` 的状态来完成，关闭就意味着你不想要这个提交记录）
>  *  合并提交。简而言之，它允许你把多个提交记录合并成一个。
> 
>     答案：    git rebase -i HEAD~4

## 杂项  ##

> ## 本地栈式提交 ##
> 
> 来看一个在开发中经常会遇到的情况：我正在解决某个特别棘手的 Bug，为了便于调试而在代码中添加了一些调试命令并向控制台打印了一些信息。
> 
> 这些调试和打印语句都在它们各自的提交记录里。最后我终于找到了造成这个 Bug 的根本原因，解决掉以后觉得沾沾自喜！
> 
> 最后就差把 `bugFix` 分支里的工作合并回 `main` 分支了。你可以选择通过 fast-forward 快速合并到 `main` 分支上，但这样的话 `main` 分支就会包含我这些调试语句了。你肯定不想这样，应该还有更好的方式……
> 
> 实际我们只要让 Git 复制解决问题的那一个提交记录就可以了。跟之前我们在“整理提交记录”中学到的一样，我们可以使用
> 
>  *  `git rebase -i`
>  *  `git cherry-pick`
> 
> 来达到目的。
> 
>     答案：    git rebase -i HEAD~3
>              ##删除两次打印日志的提交
>               git branch -f main bugFix

[https_learngitbranching.js.org]: https://learngitbranching.js.org