GIT技巧

目录

基础命令

commit 、branch

merge

rebase

高级特性

自由修改提交树

cherry-pick

rebase

远程仓库命令

---

基础命令

commit 、branch

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

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

merge

分支与合并
我们新建一个分支，在其上开发某个新功能，开发完成后再合并回主线。在 Git 中合并两个分支时会产生一个特殊的提交记录，它有两个父节点。翻译成自然语言相当于：“我要把这两个父节点本身及它们所有的祖先都包含进来。”

rebase

git rebase
Rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个放下去，
Rebase的优势就是可以创造更线性的提交历史。如果只允许使用 Rebase的话，代码库的提交历
史将会变得异常清晰。

 在开发社区里，有许多关于merge 与rebase 的讨论。以下是关于rebase的优缺点：
优点：Rebase 使你的提交树变得很干净，所有的提交都在一条线上
缺点：Rebase 修改了提交树的历史
比如，提交C3 可以被 rebase 到C1之后。这看起来C3中的工作是在C1之后进行的，但实际上是在 C1之前。
一些开发人员喜欢保留提交历史，因此更偏爱menge。而其他人（比如我自己）可能更喜欢干净的提交树。于是偏爱rebase。仁者见仁，智者见智。

高级特性

HEAD是一个对当前检出记录的符号引用，也就是指向你正在其基础上进行工作的提交记录。
HEAD总是指向当前分支上最近一次提交记录。大多数修改提交树的Git命令都是从改变HEAD的指向开始的。
HEAD通常情况下是指向分支名的(如bugFix)。在你提交时，改变了 bugFix的状态，这一变化通过 HEAD变得可见。
分离的 HEAD就是让其指向了某个具体的提交记录而不是分支名。
HEAD -> main-> C1  HEAD指向 main, main 指向 C1
checkout C1后变成了HEAD -> C1

通过哈希值指定提交记录很不方便，所以Git引入了相对引用。使用相对引用的话，你就可以从一个易于记忆的地方（比如bugFix分支或HEAD）开始计算。相对引用非常给力，这里我介绍两个简单的用法:
·使用^向上移动 1 个提交记录,如git checkout main^
·使用~向上移动多个提交记录，如~3

强制修改分支位置
可以直接使用选项让分支指向另一个提交。例如：
git branch -f main head~3
上面的命令会将 main 分支强制指向 HEAD的第3级父提交。

撒销变更
在Git 里撤销变更的方法很多。和提交一样，撤销变更由底层部分（暂存区的独立文件或者片段）和上层部分（变更到底是通过哪种方式被撤销的）组成。主要有两种方法用来撤销变更:
git reset 通过把分支记录回退几个提交记录来实现撤销改动。你可以将这想象成“改写历史”。git reset 向上移动分支，原来指向的提交记录就跟从来没有提交过一样。(在reset后，所做的变更还在，但是处于未加入暂存区状态。)

git  reset   head~1

 虽然本地分支使用reset很方便，但对远程分支是无效的；为了撤销更改并分享给别人，需要用revert

奇怪！在我们要撤销的提交记录后面居然多了一个新提交！
这是因为新提交记录c2'引入了更改,这些更改刚好是用来撤销c2这个提交的。也就是说c2'的状态与c1是相同的，revert 之后就可以把你的更改推送到远程仓库与别人分享啦。

git revert head

自由修改提交树

上面的这些概念涵盖了 Git 98% 的功能，同样也足够满足开发者的日常需求，然而，剩余的 10% 在处理复杂的工作流时(或者当你陷入困惑时）可能就显得尤为重要了。接下来要讨论的这个话题是“整理提交记录”— 开发人员有时会说“我想要把这个提交放到这里，那个提交放到刚才那个提交的后面”，而接下来就讲的就是它的实现方式，

cherry-pick

本系列的第一个命令形式为：git cherry-pick <提交号>
如果你想将一些提交复制到当前所在的位置（head）下面的话，Cherry-pick 是最直接的方式了。

如下将side分支上的C2,C4提交记录复制到main分支

git  cherry-pick  C2  C4

rebase

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

交互式rebase 指的是使用带参数-interactive的rebase 命令，简写为-i，如果你在命令后增加了这个选项，Git 会打开一个 UI 界面并列出将要被复制到目标分支的备选提交记录，它还会显示每个
提交记录的哈希值和提交说明，提交说明有助于你理解这个提交进行了哪些更改。在实际使用时，所谓的UI 窗口一般会在文本编辑器 — 如Vim- 中打开一个文件。 

git rebase -i head~4

tags

分支很容易被人为移动，有新提交时也很容易改变，有没有可以永远指向某个提交记录的标识呢，比如软件发布新的大版本，或修正一些重要的bug，或增加了某些新特性。tag可以永久的将某个特定的提交命名为里程碑，他不会随着新提交移动，也不能切换到某个标签上进行修改提交，他就像是提交树上的一个锚点，标识了某个特定的位置

git  tag  v1  c1

远程仓库命令

远程仓库是一个强大的备份，也能让代码社交化

远程分支命名规范 / 比如origin/main

git pull=git fetch;git merge

git pull --rebase=git fetch;git rebase

git clone #在本地创建一个远程仓库的拷贝

git fetch #从远程仓库下载本地仓库缺失的提交记录并更新远程分支指针origin/main,但并不会改变本地仓库的状态，不会更新本地main分支，也不会修改磁盘上的文件

git pull #抓取更新并合并到本地分支

git push #将变更上传到远程并在远程仓库上合并你的新提交记录

git branch -u origin/main foo #设置foo跟踪远程分支

git push origin 源:目的地

git fetch origin 源:目的地

git push origin :foo #删除远程foo分支

git fetch origin :bar #在本地创建一个新分支

git pull origin main:foo #本地创建foo，拉取远程main合并到本地foo，然后再merge到当前检出的分支，参考下图