2019年整理的Git使用技巧有点粗糙，那时候也不懂得找官方文档，其实最好的学习方式，还是直接跟着官方学，这是最好的。

那时候，我自以为我已经把Git玩花了，其实不然，Git使用门槛低，但上限却是出奇的高，由此打算重新整理一份实用的，当然了，也还是偏向基础的。

我这次是有备而来，我准备了官方文档、官方电子版的书、京东购买的书。并且汲取了其中60%对我有用的价值吧。

一、 Git基本使用

1.1 仓库

理解Git三大区域

Git仓库下，分为工作区域（Working Directory）、暂存区域（Staging Area）、存储库（Repository）。

add是由工作区域提交到暂存区域。

commit是由暂存区域提交到存储库。

把文件交给Git管控

初始化仓库

1
2
3

git init
# 查看文件状态
git status

把文件交给Git暂存区

# 添加单个文件
git add test.txt
# 添加多个文件
git add test1.txt test2.txt
# 通过后缀添加
git add *.txt
# 添加所有
git add .
git add --all

--all与.两个参数的区别是，--all表示将git仓库下的所有变动都添加到git，而.只处理当前目录下的变动。

如果我后悔提交到暂存区，可以通过如下命令撤回。
git restore –staged *

将暂存区内容，提交到存储库。

1	git commit -m "提交描述"

如果觉得，先git add –all，再git commit，太麻烦
可以 git commit -a -m “提交描述” 一步到位
但这个-a，只对于修改的文件有效，新增的是无效的。

通过如下命令，可以查看具体的commit

git log
# 将上面的内容简化成一行输出
git log --oneline
# 读取第一条
git log --oneline --max-count=1

远程仓库

以下示例是使用http，ssh个人习惯上感觉过于麻烦。

查看远程仓库连接信息

1	git remote -v

与远程仓库建立远程连接

1	git remote add origin http://git.meethigher.top/wanxiang/test.git

git remote 主要进行与远端Git有关的操作
origin 指的是远端Git的一个别名，而且默认就是origin
add、remove 可以删除本地连接的远端Git

从远程分支拉取

1
2
3

git pull origin <远程分支>:<本地分支>
# 如果分支名称相同，可以直接
git pull origin <分支>

将本地分支推送到远程分支

1
2
3

git push origin <本地分支>:<远程分支>
# 如果分支名称相同，可以直接
git push origin <分支>

像使用Github时，会推荐git push -u origin master
-u就是upstream，此处可以理解成自动跟踪master分支。
也就是说，如果下次，我还是想推送到master分支，只需要执行git push即可。
不过个人不太喜欢这种方式。

删除远程分支

1	git push origin --delete <分支名称>

修补最新commit

如果commit之后，发现漏掉了某个文件，或者需要重新修改提交。

可以将修改暂存，然后执行如下命令，更新最新提交

1
2
3

git commit --amend
# 添加注释
git commit --amend -m "描述"

当你在修补最后的提交时，与其说是修复旧提交，倒不如说是完全用一个新的提交替换旧的提交，理解这一点非常重要。从效果上来说，就像是旧有的提交从未存在过一样，它并不会出现在仓库的历史中。
修补提交最明显的价值是可以稍微改进你最后的提交，而不会让“啊，忘了添加一个文件”或者 “小修补，修正笔误”这种提交信息弄乱你的仓库历史。
如果是远程仓库，本地amend之后，强制推送更新即可。
eg：
git push --force origin dev

1.2 分支

分支只是指向某个commit的地址，就跟Java对象引用地址一样，我把对象清空，只是清空了指向，并没有将开辟的空间回收（回收那就是GC的事了）。

所以，分支（包括后面的标签），都是随意删除的，我甚至删一个aaa分支，再建一个aaa分支，都互不影响。

演示一下删除分支，我从master检出一个分支，并commit后，如图。

此时如果我把分支cat干掉，就变成了如下图。

由此也可知，分支是可以恢复的，只要你记住了commit地址即可，因为commit存在啊。

新增/重命名/删除/切换分支

查看分支列表

1	git branch

在当前分支内容上，新开辟一个分支

1	git branch <分支名称>

切换分支

1	git checkout <分支名>

git checkout -b dev 在当前分支内容上，新开辟一个分支，并切换到dev分支
git checkout --orphan dev 创建一个从0开始的分支，适用于拉取远程分支时使用
git checkout -b test --track origin/dev从远程分支dev拉取最新内容到本地test分支

重命名分支

1	git branch -m <现分支名> <新分支名>

删除分支

git branch --delete <分支名>
git branch -D <分支名>
# 删除远程分支
git push origin --delete <分支名称>
# 删除远程分支简化版，可以理解成，推送空内容区更新分支，也就是将分支删除
git push origin :<分支名称>

切换commit

因为对于Git来说，分支本身也是指向的commit，所以checkout也可以直接指向commit

标签同理，标签也是指向commit，实际切换的还是commit

1	git checkout <commitId>

切换/回滚文件

将修改后的某个文件，回滚到指定的分支或者commitId

1	git checkout [分支\|commitId] -- 文件绝对或者相对路径，相对路径可以使用git status查看

合并分支

比如我在master分支，此时我要将dev的分支合并过来

1	git merge dev

合并常见三种情况

Fast-forward
recursive strategy
CONFLICT (content)

像Fast-forward，如下图，此时master分支要合并hotfix，是没有任何冲突的，master只需要指向前方的地址值C4即可。这种合并叫做Fast-forward。

像recursive strategy，如下图，一般是因为两个分支有共同的祖先，但是各自分支上进行了更改，并没有发生冲突。

像CONFLICT (content)，如下图，一般是由于多人同时改了同一个文件，甚至同一行。git并不会提交commit，而是将冲突的内容保存在暂存区，等人工去纠正后再commit。

合并commit

cherry-pick，顾名思义，精心挑选。

与merge不同，它只合并指定的commit。

# 表示将commit为111和222的合并到当前分支
git cherry-pick 111 222
# 表示将commit为111到222的所有提交合并到当前分支
git cherry-pick 111...222

git cherry-pick命令用法详解-CSDN博客

回退commit

将当前分支的内容回退到指定的分支，指定分支之后的都被删除。

# 硬删除，真实删除
git reset --hard commitid
# 软删除，虚假删除
git reset --soft commitid

跟踪分支

一开始我跟踪的是origin/h2-diy-api分支，所以会提示比远程分支多修改了内容，尽快提交。

我重新跟踪正确分支，问题解决。

在 Git 中，跟踪（track）是指建立一个分支与另一个分支之间的关联关系，使得它们可以相互追踪对方的提交记录。跟踪的作用是方便在推送和拉取代码时进行操作，并提供了一种简洁和直观的方式来管理分支之间的关系。

# git branch -u 远程新分支
git branch -u origin/camunda
# 查看当前分支与远程分支的跟踪关系
git branch -vv

1.3 标签

新增/删除/切换标签

为commit为51d54ff的创建标签ava

# 简洁版标签
git tag ava 51d54ff
# 描述版标签
git tag ava 51d54ff -a -m "描述"

切换标签

1	git checkout ava

如果我想再切换到最新的commit，只需要切换分支即可。
因为分支就是标识了最新的commit

删除标签ava

1	git tag -d ava

推送标签到远程分支

1	git push origin --tags

标签与分支区别

标签与分支作用一样，只是起到指向的作用。标签与分支被删除都不会影响到实际的数据。

两者的作用是，分支会随着commit移动，但标签不会。

分支=会移动的标签，留下来的是标签，跟着走的是分支。

1.4 暂存区贮藏

如果我已经修改了代码，但是此时又未完成，不能提交，而此时比如我要切换分支。

可以使用stash，将修改add到暂存区，然后stash贮藏起来。

一定要存储到暂存区，否则stash也不会存储

# 超简洁版
git stash
# 简洁版
git stash push [暂存的某个文件]
# 描述版
git stash push -m "描述" [暂存的某个文件]

查看贮藏列表

1	git stash list

查看修改内容

1	git stash show

恢复并删除贮藏

# 取出最新贮藏的到工作区域，理解成栈的后入先出
git stash pop
# 取出指定stashId标识内容到工作区域
git stash pop <stashId>

恢复并保留贮藏

# 取出最新贮藏的到工作区域，理解成栈的后入先出
git stash apply
# 取出指定stashId标识内容到工作区域
git stash apply <stashId>

删除贮藏

1 2	git stash drop git stash drop <stashId>

清空贮藏

1	git stash clear

1.5 提交规范

在Git中，通常使用规范化的提交消息格式，其中包含一个关键字作为提交消息的前缀，用于表示提交的类型或目的。以下是常见的关键字及其含义：

feat: 表示引入新功能（feature）。当你添加新的功能、模块或功能性改进时使用此关键字。
fix: 表示修复Bug。当你修复代码中的错误、修复功能缺陷或解决问题时使用此关键字。
docs: 表示文档更新。当你更新文档、注释或其他相关文档内容时使用此关键字。
style: 表示代码风格调整。当你对代码进行格式化、空格调整、命名调整或样式调整等不涉及功能修改的操作时使用此关键字。
refactor: 表示代码重构。当你对现有代码进行重构、优化或重组，而不是修复错误或添加新功能时使用此关键字。
perf: 表示性能优化。当你对代码进行优化、改进性能或提高效率的操作时使用此关键字。
test: 表示测试相关的修改。当你添加、修改或重构测试代码时使用此关键字。
chore: 表示杂项或琐碎的变更。当你进行一些不涉及源代码、测试或文档的变更时使用此关键字。例如，构建过程的改变、包管理器配置的修改等。
revert: 表示回滚操作。当你需要撤销先前的提交时使用此关键字。
build: 表示构建相关的修改。当你修改构建脚本、配置文件或依赖项时使用此关键字。

请注意，以上关键字只是一种常见的约定，并没有严格的规定，你可以根据团队或项目的具体要求进行调整和定义。重要的是保持提交消息的清晰、有意义，以便更好地理解和跟踪代码的变更历史。

二、参考致谢

Git - Book

Git使用技巧-规范总结版