git 总结 (study)

命令概览

• git stash
• git clone
• git init
• git remote
• git branch
• git checkout
• git add
• git commit
• git rm
• git push
• git pull
• git fetch
• git merge
• git log
• git reset
• git reflog
• git revert
• git cherry-pick
• git tag
• git rebase

命令解析

stash

• git stash save 'xxx':储存变更
• git stash list：查看储存区所以提交列表
• git stash pop：弹出并应用最近一次存储记录
• git stash drop stash@{n}：删除某次存储记录
• git stash clear：清除所有stash信息

git clone

• git cline xxx.git 远程仓库拉到本地
• git clone xxx.git -b dev1远程仓库拉到本地并切换到指定分支

git init
除了我们从远端建仓库，有的时候我们自己本地也是可以自己初始化一个 Git 仓库来操作的，这个时候我们就直接使用 git init 就能轻松为当前目录创建一个 git 仓库，也就能开始对当前目录的改动纳入版本管理库了。
不过本地 init 的仓库没法和远端进行交互，所以我们还是需要去 github/gitlab 创建一个远端仓库，然后关联一下，也就是 git remote命令了

• git init 本地创建初始化仓库
• git remote本地仓库和线上仓库关联

git remote
用于和远程仓库进行关系绑定处理等等操作。

• git remote add: 添加一个远程版本库关联
• git remote rm: 删除某个远程版本库关联

比如我们本地有个初始化好的仓库，同时还有一个创建好的远程空仓库，那么我们就可以执行一下操作让他们关联起来：

• git remote add origin xxx.git先添加到本地仓库
• git push -u origin master：表示把当前仓库的 master 分支和远端仓库的 master 分支关联起来，后面我们执行 push 或者 pull 都可以非常方便的进行操作了。

git branch

拿到一个项目之后，你首先还是应该看一下当前仓库现在有哪些分支，不要待会创建新分支发现名字重复之类的问题，那这个时候我们就可以使用 git branch 来查看一下相关的分支了。

-git branch：查看本地所有分支信息
-git branch -r：查看远程仓库所有分支
-git branch -a：查看本地和远程仓库所有分支

一般来说如果分支太多的话，还是建议使用可视化工具来查看分支信息，比如 vscode 或者 source tree 等软件等等。

当然 IDEA 也是可以的。

git checkout

如果我们想以当前分支为基准，创建一个新的分支并切换过去，可以使用如下命令。

• git checkout -b dev2 创建并切换到指定新分支

git add

我们在某个分支更改了代码之后，想要把它提交一下，那么你第一步要做的就是，执行git add

git add [file1] [file2]: 添加一个或多个文件到暂存区

一般我们平时在使用的时候，用的比较多的应该还是：

git add .：把当前目录下得所有文件改动都添加到暂存区
git add -A：把当前仓库内所有文件改动都添加到暂存区

用的最多的还是这个 git add -A 命令，因为大多数情况，我们都应该把所有变更都加到暂存区里，如果没有，那大概率是忘了。

git commit

文件添加到暂存区之后，我们就可以执行下一步操作了。

git commit [file1] ... -m [message]：将暂存区的内容提交到本地 git 版本仓库中

-m 表示的是当前提交的信息
-a 对于已经被纳入 git 管理的文件（该文件你之前提交过 commit），那么这个命令就相当于帮你执行了上述 git add -A，你就不用再 add 一下了；对于未被 git 管理过的（也就是新增的文件），那么还是需要你先执行一下 git add -A，才能正确被 commit 到本地 git 库。

通常情况下，我们用的比较多得应该是 git commit -m 'feat: do something'，设置当前提交的信息。当然，如果你没有强诉求需要 git add 和 git commit一定要分开，那你大可选择 git commit -am，方便又快捷。

git rm

• git rm a.html 删除git仓库中某个文件
• .gitignore 项目中此文件表示需要被 git 忽略提交

这个其实也挺有用的，比如我们项目中有个文件叫 .env，这个文件是一个私有的，不能被提交到远程的，但是我们不小心提交到了本地仓库中，这个时候我们把这个文件添加到 .gitignore 文件中，表示需要被 git 忽略提交，但是由于我们已经提交到本地仓库了，所以如果不先从git仓库删除是没用的。
如果直接右键删除，那么这个文件的记录还是会被保存到远端仓库，别人还是能看得到你这个信息，所以我们需要先从 git仓库中删掉这个文件才行。

git rm .env：执行完这个命令就表示 .env 文件从git仓库中删除了，配合 `.gitignore 就能保证以后所有的 .env 文件变更都不用担心被提交到远程仓库。

git rm -r dist：如果我们要删除的是一个目录，那么加上-r参数就好了。

git push

• git push --set-upstream origin branch1 推送分支并建立关联关系

接下来我们想要把刚创建好得分支推送到远端，一般来说我们可能会需要用到 git push，但我们这是个新分支，根本没和远端仓库建立任何联系，那么我们就需要加点参数，让他们关联上：

• git push --set-upstream origin branch1 推送分支并建立关联关系

完事之后我们可以再去远程仓库看一眼就会发现我们创建的新分支已经推上去了。接下来可能会有小伙伴要问了，那如果远端仓库已经有了这个分支名咋整？

这里就分两种：

1.一种就是你本地的代码和远端代码没有冲突的情况下，并且你本地有新增提交，那么你可以仍然执行上述命令，这样就会直接将当前本地分支合远程分支关联上，同时把你的改动提交上去。

2.另一种就是本地分支和远端分支存在冲突，这个时候你执行上述命令就会出现提示冲突，那么接下来就需要你先把远端当前分支的代码拉下来，解决一下冲突了，就需要用到 git pull 命令了。

git pull

通常情况下，如果当前分支已经和远端分支建立了联系，那么我们想要合并一下远端分支，只需要执行 git pull就好了，不用带其他参数，但如果和上面提到的 git push 时产生了冲突，还没有建立联系的时候，我们就需要指定需要拉取哪个分支的代码下来进行合并了。

• git pull origin branch1：拉取指定远端分支合并到本地当前分支

这里的 origin 是我们对远端仓库的命名，想改也是可以的，不过一般都是用的 origin。
回到上面提到的冲突问题，我们可以直接使用 git pull然后指定合并当前本地分支想要建立联系的远程分支，然后本地解决一下冲突，然后提交一下改动，再执行 git push --set-upstream origin branch1命令就大功告成了。

git fetch

了解完上面描述的 git pull，命令之后，其实这个命令也很好理解了，特定时候，可能我们只是想把远端仓库对应分支的变更拉到本地而已，并不想自动合并到我的工作区（你当前正在进行代码变更的工作区），等晚些时候我写完了某部分的代码之后再考虑合并，那么你就可以先使用git fetch。
fetch 完毕之后，我提交了自己当前工作去的变更到本地仓库，然后想合并一下远端分支的更改，这个时候执行一下git merge origin/[当前分支名]（默认一般是用 origin 表示远端的分支前缀）即可。

git merge

合并指定分支代码到当前分支。一般来说，我们用的比较多的场景可能是，远端仓库 master 分支有变更了，同时这个时候我们准备提 MR 了，那么就需要先合一下 master 的代码，有冲突就解决下冲突，那这个时候我们可以做以下操作：

切到 master 分支，git pull拉一下最新代码
切回开发分支，执行 git merge master合并一下 master 代码

同理，上面介绍的 git merge origin/xxx 也是一样的用法。

git log
顾名思义，就是日志的意思，执行这个命令之后，我们能看到当前分支的提交记录信息，比如 commitId 和提交的时间描述等等，大概长下面这样：

commit e55c4d273141edff401cbc6642fe21e14681c258 (HEAD -> branch1, origin/branch1)
Author: name <44311619+STDSuperman@xxx.xxx.github.com>
Date:   Mon Aug 1 23:16:11 2022 +0800

    Initial commit

这个时候可能有读者会问了，这个都用来干啥的，简单的用法呢就是看看有谁提交了啥，还有更重要的用法呢就是进行代码版本的回滚，或者其他有意思的操作，且听笔者为你微微道来。

git reset

• git reset [--soft | --mixed | --hard] [HEAD]

关于 HEAD：

HEAD 表示当前版本
HEAD^ 上一个版本
HEAD^^ 上上一个版本
HEAD^^^ 上上上一个版本
HEAD~n 回撤 n 个版本，这种也是更加方便的

参数解析
以下解析均基于后接参数为 HEAD^，也就是git reset HEAD^。

--soft: 重置你最新一次提交版本，不会修改你的暂存区和工作区。
--mixed: 默认参数，用于重置暂存区的文件与上一次的提交(commit)保持一致，工作区文件内容保持不变。
--hard: 重置所有提交到上一个版本，并且修改你的工作区，会彻底回到上一个提交版本，在代码中看不到当前提交的代码，也就是你的工作区改动也被干掉了。

说了半天似乎不是很好理解，我们举个栗子理解下：
比如：

我改动了我的README 文件，在我们的工作区就产生了一次改动，但是这个时候还没有提交到暂存区，在vscode里会显示为工作区修改的标记
接着我们执行git add，这个时候你查看暂存区，会发现这次改动被提交进去了，同时被 vscode标记为已被提交至暂存区
然后再执行 git commit，这个时候就完成了一次提交

接下来我们想撤回这次提交，以上三种参数所体现的表现会是这样的：

--soft：我们对 README 的更改状态现在变成已被提交至暂存区，也就是上面 2 的步骤。
--mixed： 我们对 README 的更改变成还未被提交至暂存区，也就是上面 1 的步骤。
--hard：我们对 README 的所有更改全没了，git log 中也找不到我们对 README 刚刚那次修改的痕迹。

默认情况下我们不加参数，就是 --mixed，也就是重置暂存区的文件到上一次提交的版本，文件内容不动。一般会在什么时候用到呢？

场景一（撤销 git add）

可能大部分情况下，比如 vscode 其实大家更习惯于使用可视化的撤销能力，但是呢，这里我们其实也可以稍微了解下这其中的奥秘，其实也很简单：

方式一：git reset
方式二：git reset HEAD

其实一二都是一样，如果 reset 后面不跟东西就是默认 HEAD。

场景二 (撤销 git commit)
当你某个改动提交到本地仓库之后，也就是commit之后，这个时候你想撤回来，再改点其他的，那么就可以直接使用git reset HEAD^。这个时候你会惊奇的发现，你上一版的代码改动，全部变成了未被提交到暂存区的状态，这个时候你再改改代码，然后再提交到暂存区，然后一起再commit 就可满足你的需求了。
除了这种基础用法，我们还可以配合其他命令操作一下。

场景三
某一天你老板跟你说，昨天新加的功能不要了，给我切回之前的版本看看效果，那么这个时候，你可能就需要将工作区的代码回滚到上一个commit版本了，操作也十分简单：

git log查看上一个commit 记录，并复制commitIdgit reset --hard commitId`直接回滚。

场景四
果某一个你开发需求正开心呢，突然发现，自己以前改的某个东西怎么不见了，你想起来好像是某次合并，没注意被其他提交冲掉了，你心一想，完了，写了那么多，怎么办？很简单，回到有这份代码的那个版本就好了（前提你提交过到本地仓库）。
假设我们有这么两个提交记录，我们需要下面那个 365 开头 commitId 的代码：

commit e62b559633387ab3a5324ead416f09bf347d8e4a (HEAD -> master)
Author: xiaohang.lin <xiaohang.lin@alibaba-inc.com>
Date:   Sun Aug 14 18:08:56 2022 +0800

    merge

commit 36577ea21d79350845f104eee8ae3e740f19e038 (origin/master, origin/HEAD)
Author: 陌小路 <44311619+STDSuperman@users.noreply.github.com>
Date:   Sun Aug 14 15:57:34 2022 +0800

    Update README.md

抢救第一步 git log找到有你这个代码的那个 commitId（也就是 36577ea21d79350845f104eee8ae3e740f19e038）
抢救第二步 git reset --hard commitId
第三步：Ctrl + c 你的目标代码

这个时候你想把复制好的代码写回去，该怎么办呢，你可能会再 git log看一下我们 reset 之前的 commitId，你会发现，完了，之前的 commitId 都没了，只有这个 365 了。

commit 36577ea21d79350845f104eee8ae3e740f19e038 (origin/master, origin/HEAD)
Author: 陌小路 <44311619+STDSuperman@users.noreply.github.com>
Date:   Sun Aug 14 15:57:34 2022 +0800

    Update README.md

不要慌，请记住一句话，只要你不删你本地的 .git 仓库，你都能找回以前所有的提交。
git log看不到的话，我们就可以祭出我们的绝招了：git reflog

36577ea (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: reset: moving to 36577ea21d79350845f104eee8ae3e740f19e038
e62b559 HEAD@{1}: reset: moving to e62b559633387ab3a5324ead416f09bf347d8e4a

这里我们可以看到两行记录，一个是我们执行 reset 到 365 的记录，另一条不知道是啥，不重要，我们想回到我们刚刚 reset 之前的状态也很简单，直接复制它上一次的变动也就是这个 e62b559，然后执行 git reset --hard e62b559，然后你会惊奇的发现，你之前的代码又回来了。
接下来把你以前版本的代码，再 Ctrl + v 放进来就完成了。

git reflog
介绍：用来查看你的所有操作记录。

既然git log看不到我之前 commitId 了，那么就回到 reset 之前的状态吧！

git revert

当然了，如果是针对master的操作，为了安全起见，一般还是建议使用revert命令，他也能实现和reset 一样的效果，只不过区别来说，reset是向后的，而 revert是向前的，怎么理解呢？简单来说，把这个过程当做一次时光穿梭，reset表示你犯了一个错，他会带你回到没有犯错之前，而revert 会给你一个弥补方案，采用这个方案之后让你得到的结果和没犯错之前一样。
举个栗子：
假设你改了README的描述，新增了一行文字，提交上去了，过一会你觉得这个写了有问题，想要撤销一下，但是又不想之前那个提交消失在当前历史当中，那么你就可以选择使用 git revert [commitId]，那么它就会产生一次新的提交，提交的内容就是帮你删掉你上面新增的内容，相当于是一个互补的操作。

PS D:\Code\other\git-practice> git revert 3b18a20ad39eea5264b52f0878efcb4f836931ce
On branch branch2
Your branch is ahead of 'origin/branch2' by 1 commit.
  (use "git push" to publish your local commits)

这个时候，它会提示你可以把新的改动 push 上去了。
其实你如果在 gitlab 进行 mr 之后，想要回滚这个 mr，一般它会给你一个revert 的按钮选项，让你进行更安全的回滚操作。

git cherry-pick

其实对于我们工作中大部分场景下应该用不到这个功能，但是呢有的时候这个命令又能挽救你于水火之间，那就是当某个倒霉蛋忘记切分支，然后在master分支上改了代码，并且提交到了本地仓库中，这个时候使用git cherry-pick简直就是神器了。

git cherry-pick：将执行分支的指定提交合并到当前分支。

一听介绍就来精神了，雀氏有点东西，比如我在master 分支提交了某个需求的代码，同时还没提交到远程分支，那么你就可以先git log 查看一下当前的提交，找到 master 分支正常提交之后的所有commitId，然后复制出来，然后再切到你建好的开发分支，接着执行
git cherry-pick master commitId1 commitId2 commitId4。
完事之后记得清理一下作案现场，把你的 master 分支代码恢复到正常的提交上去。

git tag

顾名思义，也就是打标签的意思。一般可能会在你发布了某个版本，需要给当前版本打个标签，你可以翻阅 vite 的官方 git 仓库，查看它的 tag 信息，它这里就标注了各个版本发布时候的 tag 标签。

它有两种标签形式，一种是轻量标签，另一种是附注标签。

轻量标签

• 创建方式：git tag v1.0.0

它有点像是对某个提交的引用，从表现上来看，它又有点像基于当前分支提交给你创建了一个不可变的分支，它是支持你直接 checkout到这个分支上去，但是它和普通分支还是有着本质的区别的，如果你切换到了这个tag "分支"，你去修改代码同时产生了一次提交，亦或者是reset版本，这对于该tag本身不会有任何影响，而是为你生成了一个独立的提交，但是却在你的分支历史中是找不到的，你只能通过commitId 来切换到本次提交，看图：

image.png

那如果你从其他分支通过 commitId 切换到这个改动上，它会提示你以下内容：

Note: switching to 'be276009'.

changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

大致意思就是你可以选择丢弃或者保留当前更改，如果需要保留的话直接使用下面的 git switch 命令创建一个新分支即可。

附注标签

创建方式：git tag -a v1.0.1 -m "发布正式版 1.0.1"

引用官方文档的描述：

而附注标签是存储在 Git 数据库中的一个完整对象， 它们是可以被校验的，其中包含打标签者的名字、电子邮件地址、日期时间， 此外还有一个标签信息，并且可以使用 GNU Privacy Guard （GPG）签名并验证。

从概念上看，轻量标签更像是一个临时的标签，而附注标签更加正式一点，能够保留更多的信息。它创建的方式和轻量标签区别主要是-a 和-m 参数，如果你的-m参数不传，那么编辑器会让你手动填写。

对比标签信息
打完标签之后，我们可以使用 git show命令来看看这两种标签最终体现的信息有哪些。

轻量标签

commit dcbd335be87f51eaa0cc1852400e64e9f46e84d8 (HEAD -> test-branch1, tag: v1.0.2, tag: v1.0.1)
Author: STDSuperman <2750556766@qq.com>
Date:   Tue Aug 16 22:54:36 2022 +0800

    xx

diff --git a/README.md b/README.md
index 715766a..b4cdea6 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,3 @@
-# git-practice
\ No newline at end of file
+# git-practice
+
+test tag

附注标签

tag v1.0.1
Tagger: STDSuperman <2750556766@qq.com>
Date:   Tue Aug 16 22:58:27 2022 +0800

发布正式版 1.0.0

commit dcbd335be87f51eaa0cc1852400e64e9f46e84d8 (HEAD -> test-branch1, tag: v1.0.1)
Author: STDSuperman <2750556766@qq.com>
Date:   Tue Aug 16 22:54:36 2022 +0800

    xx

diff --git a/README.md b/README.md
index 715766a..b4cdea6 100644
--- a/README.md
+++ b/README.md

推送标签

git push origin tagName

$> git push origin v1.0.1
Enumerating objects: 6, done.
Counting objects: 100% (6/6), done.
Delta compression using up to 12 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 448 bytes | 448.00 KiB/s, done.
Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:STDSuperman/git-practice.git
 * [new tag]         v1.0.1 -> v1.0.1

当然，附注标签和轻量标签都是可以被推送到远端的。

其他命令

查看标签：git tag
筛选标签：git tag -l v1.0.1
删除标签：git tag -d v1.0.1
删除远程标签：git push origin --delete v1.0.2

另一种删除远程方式（表示将“:”前面空值替换到远程，也不失为一种方式）：git push origin :refs/tags/v1.0.1

git rebase

这块其实涉及的玩法会相对来说复杂一点，可能还是需要拿来和 merge 做一下对比才更加有意义，东西有点多，先搁置一下。

WIP...

参考来源链接：https://juejin.cn/post/7131713973572861966