Git 提高 (2)

提交原则

Do one thing and do it well

Git的每一个commit最好是解决一个问题或者是一个小的改动, 如果一个提交包含过多的改动, 会造成以下问题:

增加了代码评审的难度
缺乏原子化: 如果提交中仅有少部分有问题, 需要撤回整个提交
过多的提交导致提交说明难以描述清楚

提交描述规范

Git提交描述由三部分构成

1	<type>(<scope>): <subject>

type(必须)

用于说明git commit的类别，只允许使用下面的标识。

feat：新功能（feature）

fix/to：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG

fix：产生diff并自动修复此问题。适合于一次提交直接修复问题
to：只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fix

docs：文档（documentation）

style：格式（不影响代码运行的变动）

refactor：重构（即不是新增功能，也不是修改bug的代码变动）

perf：优化相关，比如提升性能、体验

test：增加测试

chore：构建过程或辅助工具的变动

revert：回滚到上一个版本

merge：代码合并

sync：同步主线或分支的Bug

scope(可选)

scope用于说明 commit 影响的范围

subject(必须)

subject是commit目的的简短描述，不超过50个字符。

拆分当前提交

当一个提交包含多个提交的时候, 我们需要进行提交拆分, 可以使用如下操作

git reset HEAD~1: 回退到上一个提交, 此时暂存区任然保留着我们的修改

git add -p: 进入 patch mode , 此时 git 会自动将改动切分成多个片段，并展示第一个片段，提示你进行选择。

Stage this hunk [y,n,q,a,d,/,s,e,?]?

y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file // 
g - select a hunk to go to
/ - search for a hunk matching the given regex
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
e - manually edit the current hunk
? - print help

输入y, 然后输入q: 暂存第一个片段, 后面片段不暂存
git commit -m "your msg": 提交你的第一个改动
循环执行上述命令

演示

git log
# 发现一个提交包含了三个改动
3e6ebdf HEAD@{9}: commit: refactor: add log.c, delete bug.c, doc: update READEME

# 回退到该提交的上一个提交, 工作区的内容仍然保存
git reset HEAD~1

# 进入patch模式
# git add -p

# 第一个改动片段, 输入y暂存, 然后输入q退出
root@MagicBookPro:~/git-learn#git add -p
diff --git a/README.txt b/README.txt
index 9f99148..8c299ef 100644
--- a/README.txt
+++ b/README.txt
@@ -1 +1 @@
\ No newline at end of file
+update READEM
(1/1) Stage this hunk [y,n,q,a,d,e,?]? y

// 提交第一个改动(update README)
root@MagicBookPro:~/git-learn#git commit -m "update READEME"

# 循环执行上面 git add -p直到分区完成

# 查看 git log, 发现已经将提交拆分
root@MagicBookPro:~/git-learn# git log
commit aadca02bdc1d3414889da34a19e210da67366cee (HEAD -> master, dev)
Author: CLOUDERHEM <xx@qq.com>
Date:   Sat Jul 30 08:08:19 2022 +0800

    add log.c

commit 8a391c349031cb0b6f3741d3526cff5a0aa14da9
Author: CLOUDERHEM <xx@qq.com>
Date:   Sat Jul 30 08:07:55 2022 +0800

    delete bug.c

commit 56d010ca2ef3b039b49e92742085e547c030abc2
Author: CLOUDERHEM <xx@qq.com>
Date:   Sat Jul 30 08:07:20 2022 +0800

    update READEME

拆分历史提交

git rebase -i [历史提交]^
进入editor模式, 将需要修改的历史提交前面的pick改为edit
此时master分支指向了需要修改的提交, 使用上面提到的方法拆分当前提交
使用git rebase --continue, 会将历史后面的提交自动添加到最后一个拆分的提交

演示

root@MagicBookPro:~/git-learn#git rebase -i 3e6ebdf~1

# 进入editor模式
------------------
# 将pick该为edit, 保存退出
edit 3e6ebdf refactor: add log.c, delete bug.c, doc: update READEME
pick b86f3c4 new commit

# Rebase 74a756f..b86f3c4 onto 74a756f (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# 后面省略

# 此时master执行了当前提交, 使用上述方法拆分提交

# 执行rebase命名
root@MagicBookPro:~/git-learn#git rebase --continue

修改历史提交

当历史提交中可能出现让应用崩溃的代码是, 我们需要修正历史提交, 可以使用如下方法

在工作区中进行修改
git add: 添加修改到暂存区
git commit --fixup [有缺陷的提交], git会自动生成一个提交, 提交信息为fixup! + 有缺陷的提交信息
git rebase -i 有缺陷的提交^:

在git rebase中加入参数--autosquash自动执行下面的命令
- fixup提交行的前面改成squash, 将该行移动到有缺陷的提交的下方
- 进入edit模式, 编辑合并的提交说明后, git就会将fixup和有缺陷的提交自动合并为一个提交
git rebase --continue 完成此次修改(如果与历史提交修改有冲突, 需要解决冲突之后再执行该命令)

演示

无

git rebase -i 详解

变基时有六个命令可用：

pick

pick一个提交
reword

该reword命令与相似pick，但是使用后，重新设置过程将暂停并为您提供更改提交消息的机会。提交所做的任何更改均不受影响
edit

如果您选择edit提交，则将有机会修改提交，这意味着您可以完全添加或更改提交。您还可以进行更多提交，然后再继续进行变基。这使您可以将大型提交拆分为较小的提交，或者删除在提交中所做的错误更改
squash

该命令使您可以将两个或多个提交合并为一个提交。提交被压缩到其上方的提交中, 并且可以重新写明提交信息
fixup

这类似于squash，但是要合并的提交已丢弃其消息。提交仅合并到其上方的提交中，并且较早提交的消息用于描述这两个更改
exec

这使您可以对提交运行Shell命令

声明

如有错误请联系作者更正