首先，比较一下SVN与Git的根本区别

SVN：集中式版本控制系统，所有历史记录都存储在中央服务器，提交和更新都依赖服中央服务器
Git：分布式版本控制系统，每个开发者的工作目录都可以是一个完整本地仓库，可以独立离线工作。支持同步到远程仓库。

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

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

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

一、 Git基本使用

1.1 仓库

1.1.1 理解Git三大区域

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

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

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

1.1.2 把文件交给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 分支名称
# 将上面的内容简化成一行输出
git log --oneline
# 读取第一条
git log --oneline --max-count=1

1.1.3 远程仓库

以下示例是使用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 <分支名称>

1.1.4 修补最新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.2.1 新增/重命名/删除/切换分支

查看分支列表

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 :<分支名称>

1.2.2 切换commit

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

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

1	git checkout <commitId>

1.2.3 切换/回滚文件

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

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

1.2.4 合并分支并提交

比如我在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。

1.2.6 合并分支到暂存区

比如我在master分支，此时我要将dev的分支合并到当前暂存区

1	git merge dev --no-ff --no-commit

[Git - git-merge Documentation](https://git-scm.com/docs/git-merge#:~:text=With –no-commit perform,merges with –no-commit)

1.2.7 复制commit修改

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

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

# 表示将commit为111和222的合并到当前分支
git cherry-pick 111 222
# 表示将commit为111到222的所有提交合并到当前分支
git cherry-pick 111...222
# 表示将commit为111和222的修改，放到当前暂存区
git cherry-pick 111 222 --no-commit
# 表示将commit为111到222的修改，放到当前暂存区
git cherry-pick 111...222 --no-commit

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

1.2.8 回退commit

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

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

1.2.9 跟踪分支

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

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

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

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

1.2.10 变基

我的Git提交记录是A->B->C->D，我现在想要在A里面添加一个文件，并且不影响git记录。如下操作。

# 1. 开启交互式变基
git rebase -i --root

# 2. 在编辑器中将要修改的commit，由pick改为edit

# 3. 添加文件，进行修补提交
git commit --amend -m "feat: test"

# 4. 提交变基
git rebase --continue

# 5. 让所有变基后的提交的commitTime=authTime
git filter-branch -f --env-filter 'export GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"'

1.3 标签

1.3.1 新增/删除/切换标签

为commit为51d54ff的创建标签ava

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

切换标签

1	git checkout ava

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

创建了标签推送到远程分支

1	git push origin --tags

删除本地标签ava

1	git tag -d ava

删除远程标签

1	git push origin tag -d ava

1.3.2 标签与分支区别

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

两者的作用是，分支会随着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 提交规范

参考约定式提交

类型	说明	示例场景
feat	新增功能	feat: 添加用户注册模块
fix	修复缺陷	fix: 解决登录页面崩溃问题
docs	文档变更	docs: 更新 API 使用说明
style	代码样式调整（不改变逻辑）	style: 修正缩进、删除多余空行
refactor	代码重构（既非修复也非新增功能）	refactor: 优化数据验证逻辑结构
perf	性能优化	perf: 减少数据库查询次数
test	测试相关变更	test: 添加用户登录单元测试
chore	构建/依赖维护	chore: 更新 webpack 配置、升级 npm 包
ci	持续集成配置变更	ci: 调整 GitHub Actions 流程
build	影响构建系统的变更	build: 修改 Dockerfile 配置
revert	回滚之前的提交	revert: 撤销某次错误合并

二、参考致谢

Git - Book

Git使用技巧-规范总结版