携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第1天，点击查看活动详情
Git概述
所谓Git就是分布式版本控制工具，版本就是我们所提交的每一个日志节点就是所谓的代码版本，分布式的概念体现在每一个客户端提取的不是最新版本的快照，而是直接把代码仓库直接Clone到本地库，这样任意一处文件发生故障，都可以用其他客户端的本地仓库进行恢复，并且在远端仓库进行断网的情况下也可以进行开发工作
工作区：我们平时新增文件就会处于工作区，在工作区中的文件无法被Git 追踪 所以我们需要 git add 命令将我们的文件添加进暂存区
暂存区：保存了下次将提交的文件列表信息
本地库：存放我们从暂存区提交的信息，我们Push的时候就是将本地仓库的版本推送到远程仓库，在这儿之前的操作都是不用依靠网络来完成，这就是所谓分布式的一大特点。
远程仓库：我们通过Push命令会将我们本地仓库的版本代码推送到远程仓库，远程仓库会替我们管理代码，并且我们在任意客户端上可以将代码Clone下来进行开发
Git常用命令详解
一、关于分支的操作命令
| 命令名称 | 作用 |
|---|---|
| git branch [分支名称] | 新建分支 |
| git branch [分支名称] [记录节点引用] | 从某个版本节点应用上新建分支 |
| git branch [-r/-d] | 查看本地分支列表 -r 查看远端分支列表 -d <分支名称> 删除本地分支 |
| git checkout [分支名称] | 切换到某个分支 此时的HEAD指针也指向我们切换的分支 |
| git merge [分支名称] | 将指定分支合并到当前分支，这种合并分支的方式会产生一种合并分支的记录 (可以看出下图1就是通过merge命令合并分支) |
| git rebase [分支名称] | Rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去，rebase可以创造更线性的提交历史记录 |
在高版本的git中切换分支的命令会替换成git switch [分支名称]
master：待变基分支 当前HEAD指针指向的分支
bugFix：变基分支 目标分支
当执行rebase操作时，git会从两个分支的共同祖先开始提取待变基分支上的修改，然后将待变基分支指向基分支的最新提交，最后将刚才提取的修改应用 到基分支的最新提交的后面。
二、版本节点引用的Git操作命令
HEAD 引用表示当前操作的节点引用，Git 切换版本，底层其实是移动的 HEAD 指针，分支底层其实也是指针的引用
通过HEAD我们可以选中我们想要移动的提交记录节点 ，其实可以通过checkout 节点记录的hash值进行节点记录的选中，但是由于hash值过长操作不便 所以会出现^的相对引用
| 命令名称 | 作用 |
|---|---|
| git checkout HEAD^ | 在当前HEAD引用记录节点上，移动到上一个父节点 |
| git checkout HEAD~[移动节点数] | 在当前HEAD引用记录节点上，移动指定数目的父节点 |
| git branch -f main HEAD~[移动节点数] | 这个命令会让某个分支强制回到指定数目的父提交上 |
| git branch -f main [节点引用] | 让分支指向另一个提交记录点 |
| git reset HEAD~1 | 该命令主要是将记录向上移动【撤销提交】(git reset 无法撤销远端分支的提交记录) |
| reset命令的附加参数： | |
| git reset -soft HEAD~1 | 撤销的文件会自动处于暂存区状态 |
| git reset -mixed HEAD~1 | 撤销的文件状态是未加入暂存区 ，需要git add 指令加入暂存区 (默认就是该参数) |
| git reset -hard HEAD~1 | 撤销的文件和commit记录都会被删除 ，慎用 |
| git revert HEAD | reset命令是撤销本地提交 ，如果需要撤销远程仓库提交记录就需要用到该记录 |
:warning: revert 撤销远端分支之后会生成 一条新的记录 该记录主要是撤销记录节点的父节点相同，然后push到远端就能共享此次撤销了
git branch -f main HEAD~3 这个命令会让某个分支强制回到第3级的父提交上
-f 选项让分支指向另一个提交记录
撤销操作
git reset HEAD~1 该命令主要是将记录向上移动并且reset之后撤销节点分支的变更记录还存在只是处于未加入暂存区状态(git reset 无法撤销远端分支的提交记录)
三、整理提交记录
1、git cherry-pick <提交记录号> 将一些提交复制到当前所在的位置（HEAD）下面
应用场景： 我们需要在本地合入其他分支的提交时，如果我们不想对整个分支进行合并，而是只想将某一次提交合入到本地当前分支上，那么就要使用 `git cherry-pick` 了。
2、cherry-pick 需要提供hash日志记录值 如果不想使用这种可以使用 交互式的rebase来进行记录的整理
git cherry-pick c3 c2 c1 //将日志记录顺序重排成 c3 c2 c1
git rebase -i HEAD ~[向上调整的记录条数]
四、暂存文件
有这么一个场景，现在你正在用你的 feature 分支上开发新功能。这时，生产环境上出现了一个 bug 需要紧急修复，但是你这部分代码还没开发完，不想提交，怎么办？这个时候可以用 git stash 命令先把工作区已经修改的文件暂存起来，然后切换到 hotfix 分支上进行 bug 的修复，修复完成后，切换回 feature 分支，从堆栈中恢复刚刚保存的内容。
| 命令名称 | 作用 |
|---|---|
| git stash | 把本地的改动暂存起来 |
| git stash save “暂存信息” | 执行存储时，添加备注，方便查找。 |
| git stash apply [stash@{0}] | 应用某个存储,但不会把存储从存储列表中删除，默认使用第一个存储,即 stash@{0}， |
| git stash list | 查看stash的存储列表 |
| git stash clear | 删除所有stash 缓存内容 |
五、远端仓库相关操作
| 命令名称 | 作用 |
|---|---|
| git fetch [-all] | 从远程获取最新版本到本地，不会自动合并分支 |
| 合并远端分支到本地仓库： | |
| git cherry-pick origin/master | |
| git rebase origin/master | |
| git merge origin/master | //通过这个命令区合并远端分支节点会产生许多的合并记录 |
| git pull | pull 默认的行为是 fetch+merge |
| git pull --rebase | 行为就是 fetch+rebase |
git fetch
1、下载远程仓库下载本地仓库中缺失的提交记录
2、更新远程分支节点指针
这个操作并不会修改本地记录 只是更新分支记录以及节点指针
假设你周一克隆了一个仓库，然后开始研发某个新功能。到周五时，你新功能开发测试完毕，可以发布了。但是5天啊！你的同事这周写了一堆代码，还改了许多你的功能中使用的 API，这些变动会导致你新开发的功能变得不可用。但是他们已经将那些提交推送到远程仓库了，因此你的工作就变成了基于项目旧版的代码，与远程仓库最新的代码不匹配了。
//我们通常的操作是啥 fetch->pull 有冲突解决冲突，合并然后产生一大堆mergeinto 的信息导致分支提交记录不干净？
此时我们就可以使用git pull --rebase 操作会保证分支提交记录的干净整洁
