Git|Git Playground

HEAD

分离HEAD

一些基础的Git操作直接跳过，下面讲述更常见但是稍微复杂的 HEAD 相关的知识

Git 中 HEAD 指向的是当前本地版本的代码提交记录，通过 git checkout 来进行变更

一旦输入后本地的代码版本就会切换到对应提交记录的版本

对于提交记录的哈希值，我们可以用 git log 来进行查看

如果出现了当前 HEAD 指向的提交和 master 指向的提交不一致的情况，就是分离 HEAD 的状态

相对移动

Git 中指定提交记录的哈希值有点麻烦，我们可以用 ^ 或者是 ~num 的方式来进行相对移动，例如

git checkout main^
git checkout main~2
git checkout HEAD^^ #除了用分支的哈希，分支名称外，也可以以 HEAD 作为相对移动的参照物，这句话的意思是将 HEAD 移动到上上个提交记录

强制移动分支

git branch -f main HEAD^

意思是将 main 分支强制移动到当前 checkout 指向的前一个提交记录

撤销变更

git reset

回滚提交版本到指定提交记录位置

git reset HEAD^

这种就是回退到前一次提交记录，保留本地工作区的代码

git revert

回滚提交版本，针对远程分支有用

并不会直接删除提交记录，而是新增一个新的 commit 其中内容包含了旧版本的所有信息

git revert HEAD

IDEA pull 两种方式

昨天准备提交代码，看到有更新就拉了一下，结果由于之前的提交修改了大部分包的结构位置，导致我拉完 IDEA 直接把我之前的工作历史记录给删除了XD

后面了解发现其实 IDEA 有两种更新代码的方式，分别对应 merge 和 rebase

假设我们现在基于之前的最新提交记录上开发，然后主线 master 还是有其他人在同时进行开发新的功能，来看下两种不同的情况

merge

merge会创建一个新的提交记录，包含了其他人开发新功能的所有记录（如图上最后一个）

git checkout feature
#当前在 feature 分支线，我们想要把 main 的工作记录同步到当前工作分支上
git merge main 

那么Feature所指向的提交记录就同时具备了其他人在同一时间开发的记录、以及自己本地进行的修改

我们可以发现 Merge 本身是一种非破坏性的操作，无论是自己工作的提交线还是别人的提交线都没有收到破坏

但是缺点就是会产生很多没有意义的 Merge Commit 记录，如果分支数量一多或者是分支的更新非常频繁，就会导致 commit 信息难以维护

rebase

最早使用rebase主要是当初在开源社区提交代码的时候为了合并多个 commit 记录为一个 commit

实际上 rebase 也可以实现代码的合并

git checkout feature
git rebase main

使用 rebase 相当于重新设置了当前分支包含的所有新提交的基准点

例如上图就是把我们之前的开发线上修改的内容重新设置基准设置为了 main 后面

这样的操作会导致公共分支上的其他人受到影响，因为你这样的操作会导致原先没同步的人，基于最后一个蓝色提交的提交基准发生变化

rebase的黄金法则

The golden rule of git rebase is to never use it on public branches.

上面是在 feature 分支上，把 feature 的 base 设置为了 main 后

加入反过来是在 main 分支上，设置 main 的 base 为 feature，那影响就大了

git checkout main
git rebase feature

这一个操作直接导致其他人基于 main 的操作直接毁了，因此在公共开发的分支（例如 main 分支等）千万不能用 rebase master 这样的指令