参考文件

refer to : https://blog.csdn.net/zhaoyanjun6/article/details/125135486

https://juejin.cn/post/6933552407242604551

简易模型

重难点

本地已经改动的文件

• Unstaged : 未固定的，未支持的。在 git 里还没 add 就是 Unstaged , 也就是 modified状态
• Staged : 暂存的、阶段的、上演、层次。在 git 里，被 add 过，还没 commit 就是 Staged

rebase 参数

• Pick 保留该 commit
• Squash 将该 commit 和 前面一个 commit 合并
• Reword 保留该 commit，可以修改 commit 的注释

修改 commit 信息

• Interactive：交互
• Reword：改写

Stash 藏、存、隐匿

Init new Repository

File---->Init new Repository，选择一个新文件夹D:\WorkSpace\WpTest，然后，在这个文件夹下，创建一个Maven项目haha，最后增加一个.gitignore文件

在Gitlab的web页面上，创建一个仓库，然后，在fork的remotes上，将新的仓库，添加到这里，远程仓库的名字，叫做origin

最后add commit push

Merge

git merge 命令默认是从 当前分支 和 对方分支 的最近共同祖先节点之后的对方分支节点合并到当前分支。

• 默认缺省情况下，为 --ff ，即不创建合并节点
• --no-ff：合并分支时，会创建新的合并 commit 节点。
• --squash：将对方分支所有节点（最新节点 => 顶部节点）压缩在一起，使用者可以经过审视后进行提交，产生一个新的 commit 节点，合入到当前分支。
• --no-commit：合并后，不自动进行 commit 提交，能够给使用者一个机会在提交前审视和修改合并结果。

Reset

https://blog.csdn.net/weixin_44544859/article/details/122325272

https://blog.csdn.net/sinat_26394043/article/details/132723994

https://www.cnblogs.com/auv2009/p/12794178.html

基础理论

先看看工作区、暂存区和本地版本库的关系
你的项目就在工作区，对于项目新建的文件你必须先add保存到暂存区，再commit提交到本地库；
对于修改的文件可以先add再commit，或者直接commit。

回退和前进commit版本，只是移动HEAD指针的位置，

可以通过git log，查看commit的历史记录，通过git reset前进或者后退。

soft （软），仅仅移动版本库HEAD指针，其他什么事都不做，即索引文件（暂存区）、工作区不会重置

也即，--soft: 只移动HEAD指针，暂存区和工作目录中的更改都会保留在工作目录中，以便再次提交。 原来的文件相当于已经add过了，只需要重新 commit即可

mixed（混合）reset默认的，不指定reset类型就是它，移动版本库HEAD指针，重置暂存区，但不重置工作区。就比如说你从当前版本回退到历史版本，你工作区更改的文件和代码都是不会变成历史版本的。

也即，--mixed 或不带选项（默认）：移动 HEAD 指针并重置索引，不会修改工作区，撤销了提交和暂存的更改，但保留了工作区的修改。 原来的文件相当于，是新修改的，需要重新走add commit流程

hard（硬），移动版本库HEAD指针，重置暂存区和工作区。彻底回退到某个版本，本地的代码也会变为某个版本的内容，此命令慎用！

也即，--hard: 移动 HEAD 指针并重置索引和工作区，彻底删除了提交以及暂存区和工作区的修改，慎用，因为会导致工作区的内容丢失。

git reset --soft [commit]
git reset [commit]
git reset --hard [commit]

使用场景

git reset --mixed的使用场景：

本地开发环境，已提交N个commit、但尚未push，希望：①保留本地所有的更改，撤销最近的若干次提交历史（目的是想让git log干净一些）。

解决办法：git reset --mixed HEAD~回退到前N个版本，N=0，1，2....

git reset --mixed HEAD1，HEAD指向前1次commit，丢弃最近1次提交历史。比如：C2<--C1<--C0，C0是最近1次提交（前0次），C1是最近2次提交（前1次），C2是最近3次提交（前2次）.HEAD1 指向C1

注意，如果想让git log干净一些，这里的commit，是都还没有提交到远程仓库的，只提交到了本地仓库，否则没办法通过reset --mixed，实现让git log干净

git reset --hard的使用场景：

Fetch 和 Pull的区别

fetch：仅仅是将远程仓库的代码，拉取到本地，接下来，需要手动再次执行rebase命令，实现将本地commit和远程commit进行合并

而pull = fetch + merge

merge的前提是，本地的dev，是从origin/dev分支，checkout出来的，2者存在track关系。

这样，pull命令，就会将远程仓库的dev分支的代码，拉取到本地，并且自动执行merge命令，将远程commit和本地commit，进行合并

rebase

多个分支之间的rebase

上面，是rebase master on origin/dev，也即，是将origin/dev分支的commit，copy到master上

上面的命令，执行完成后，需要在master分支上，执行pull，然后才能执行push。

因为，如果不执行pull的话，那么本地的master分支，可能和远程的origin/master分支，代码不一致，无法执行push命令。所以，必须先执行pull，然后才能执行push命令

将多个 commit 合并为一个 commit的rebase

当我们在本地仓库中提交了多次，在我们把本地提交 push 到公共仓库中之前，为了让提交记录更简洁明了，我们希望把如下分支B、C、D三个连续的提交记录合并为一个完整的提交，然后再 push 到公共仓库。（❗️ps：同一分支操作，分支无关）

❗️注意！！！此操作会重写 commit 历史且不可撤回。

在 fork 中选中连续的提交节点，右键 Squash into Parent...

在 交互处理(interactively) 这些节点时，可进行审视和修改。

最终，可以看到选中的多个节点，合并成一个节点 （选中节点之前的节点 feat(资金流水): 开发完成）