[前端漫谈]Git 在项目中的完全控制实践在上一篇文章[前端漫谈]一巴掌拍平Git中的各种概念中，描述了 Git 的一些

导读

在上一篇文章[前端漫谈]一巴掌拍平Git中的各种概念中，描述了 Git 的一些概念，但是太过虚化，描述的都是一些概念和命令。这篇文章结合实际场景，主要描述我在项目实践中使用 Git 管理项目、团队协作的一些经验。包括 1）merge 和 rebase 使用的区别和选择；2）多人团队合作开发流程；3）标准化 commit message；4）commit 精细化管理等。这些都是为项目的健壮发展和代码的精细管理所流的泪累积出来的。

0x000 前言

由上一片文章[前端漫谈]一巴掌拍平Git中的各种概念中，可以知道，Git 世界就像一个宇宙，每一个 commit 都是一颗星球，而 commitId 就是星球的坐标，branch 是一条条的航线，穿过无数的星球，tag 是航线上重要的星球，可能是供给站，可能是商业中心，而 HEAD 则是探索号飞船，不断向前探索。中间可能会有岔道，但是永远有一个真正的方向等待勇敢的船长。

0x001 `merge` 还是 `rebase`

merge 还是 rebase，这是经久不衰的讨论点。但是这里我不去争论孰优孰略，我只说我在不同场景的实践。

1. merge

我通常使用 merge 来将多个分支合并到当前分支，比如要发布的时候，将多个功能分支合并到带发布分支：

已知：feat/A、feat/B、feat/C，是从主分支新建的功能分支，feat/B和feat/C都修改了文件1。

新建待发布分支：

# 从主分支新建分支 pub/191205
$ git checkout -b pub/191205
Switched to a new branch 'pub/191205'

合并feat/A到pub/191205：

$ git merge feat/A
Updating 53ab8fd..e443dd4
Fast-forward
 featA | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 featA

pub/191205 和 feat/A 都是从主分支新建，所以 pub/191205 指向的 commit 是 feat/A 的祖先，当把 feat/A 合并到pub/191205的时候，会发生快速合并（Fast-forward）。不会新建一个合并节点（当然也可以通过--no-ff(no-fast-forward)来强制生成一个节点）：

# 查看 log
$ git log --oneline
e443dd4 (HEAD -> pub/191205, feat/A) feat: a
53ab8fd (master) chore: first commit

合并feat/B到pub/191205

$ git merge feat/B
# 进入 vim 填写合并信息
Merge made by the 'recursive' strategy.
 1     | 2 +-
 featB | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 featB

feat/B是从主分支新建的分支，pub/191205原本指向的也是feat/B的祖先，但是因为已经和feat/A合并了，所以pub/191205不再是feat/B的祖先。因此，pub/191205和feat/B的合并不再是快速合并（Fast-forward），而是Merge made by the 'recursive' strategy.。会产生一个新的节点：

$ git log --oneline
5d0ee9b (HEAD -> pub/191205) Merge branch 'feat/B' into pub/191205
d7773d6 (feat/B) feat: b
e443dd4 (feat/A) feat: a
53ab8fd (master) chore: first commit

合并feat/C到pub/191205

$ git merge feat/C
Auto-merging 1
CONFLICT (content): Merge conflict in 1
Automatic merge failed; fix conflicts and then commit the result.

feat/C和fix/B修改了相同文件，所以产生冲突，因此，会提示解决冲突。这时候查看状态，可以发现，处于you have unmerged paths状态： ``` $ git status On branch pub/191205 You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge)

Changes to be committed:
	new file:   featC

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   1
```

这时候可以执行git merge --abort放弃继续合并，恢复合并之前的状态。也可以解决冲突之后，执行git merge。这里选择解决冲突： # 解决冲突 $ git commit # 进入 vim 编写 message [pub/191205 98d63aa] Merge branch 'feat/C' into pub/191205

feat/C是从主分支新建的分支，pub/191205原本指向的也是feat/C的祖先，但是因为已经和feat/A、feat/B合并了，所以pub/191205不再是feat/C的祖先。因此，pub/191205和feat/C的合并不再是快速合并（Fast-forward），会产生一个新的节点： $ git log --oneline 98d63aa (HEAD -> pub/191205) Merge branch 'feat/C' into pub/191205 5d0ee9b Merge branch 'feat/B' into pub/191205 d7773d6 (feat/B) feat: b 52dd922 (feat/C) feat: c e443dd4 (feat/A) feat: a 53ab8fd (master) chore: first commit

历史如下：

2. rebase

注：rebase 的功能很强大，这里先介绍和 merge 相对应的功能。

我通常用它来和主分支同步，比如一个新版本发布，主分支比我当前的功能分支超前，我使用rebase将当前分支和主分支“合并（变基）”。

已知：feat/A、feat/B 是从主分支新建，feat/A开发完成之后合并到主分支。feat/B继续开发，需要将master的功能合并到当前分支上，使用merge可以这么做：

切换到 feat/B

$ git switch feat/B
Switched to branch 'feat/B'

将 master 合并到 feat/B

$ git merge master
# 进入 vim 编写 message
Merge made by the 'recursive' strategy.
 featA | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 featA

查看状态

$ git log
b4f178e (HEAD -> feat/B) Merge branch 'master' into feat/B
d7773d6 feat: b
e443dd4 (pub/191205, master, feat/A) feat: a
53ab8fd chore: first commit

因为master合并了feat/A，因此不再是feat/B的祖先节点，不会进行快速合并（Fast-forward），会产生一个新的节点。历史如下

这么做是可以，但是我不喜欢这个合并产生的节点，所以我选择使用rebase：

恢复到合并feat/B之前

$ git reset e443dd4 --hard
HEAD is now at e443dd4 feat: a

使用rebase“合并（变基）”master

$ git rebase master
git rebase master
First, rewinding head to replay your work on top of it...
Applying: feat: b

查看历史：

$ git log --oneline
ef3450c (HEAD -> feat/B) feat: b
e443dd4 (pub/191205, master, feat/A) feat: a
53ab8fd chore: first commit

可以发现没有新的节点产生，但是rebase的操作过程并不只是不产生一个合并节点而已，它的中文翻译是变基，听起来很 Gay 的样子。但它的意思是“改变基础”。那改变的是什么基础呢？就是这个分支checkout出来的commit，原本feat/B是从master中checkout出来的，但是使用git rebase master之后，就会以master最新的节点作为feat/B分支的基础。就像feat/B上所有的commit都是基于最新的master提交的。

历史如下：

由于rebase之后，master始终是feat/B的祖先节点，因此，之后将feat/B合并到master将执行Fast-Farword，不会产生冲突（如果有冲突，rebase的时候就需要解决了），也不会产生新节点。

3. merge 还是 rebase

merge还是rebase，有人提倡不要使用rebase，应该rebase改变了历史（在上一小节中一直在改变分支的启始节点），有人提倡使用merge，保留完整的历史。

我是这么做的，在私有的分支上，我始终使用rebase将主分支的更新合并到私有的分支上（后面还有很多使用rebase的操作，都是在私有的分支，这里的私有的分支，指的是只有自己使用的分支，一旦分享出去，或者有人基于你的分支开发，那就不再是私有），而在将自己的分支合并到其他分支（主分支或者待发布分支），则使用merge。

切换到主分支：

$ git switch mater
Switched to branch 'master'

将feat/B 合并到主分支

$ git merge feat/B
Updating e443dd4..ef3450c
Fast-forward
 1     | 2 +-
 featB | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 featB

这样在长时间开发(master中间发布过n多版本)的feat/B就不会有无数乱七八糟的分支合并。而在master也不会存在rebase导致的历史变更后果。

历史如下：

准则：不要对在你的仓库外有副本的分支执行变基。

如果你遵循这条金科玉律，就不会出差错。否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。-- 3.6 Git 分支 - 变基 - 变基的风险

0x002 多人合作开发

1. 新功能开发

开发方式 新功能开发的时候从主分支新建新分支，所有该功能的开发工作都在这个分支上完成。如果主分支有新的发布，使用rebase同步主分支功能：

名称规范 功能分支的命名方式是feat/${name}_${featName}，它的构成如下：

常量feat：表示这是一个功能分支
变量name：你的名字
变量featName：功能名字好处是见名知意，一看就知道是功能分支，是谁负责，是什么功能

2. bug 修复及其发布

开发方式 bug修复大体上和新功能的开发类似，但是bug修复一般时间短，立马上线。 bug修复从主分支新建新分支，所有的bug修复工作都在这个分支上完成。如果主分支有新的发布，使用rebase同步主分支功能（这个步骤其实和新功能开发一样）：

名称规范 bug修复分支的命名方式是hotfix/${name_${bugName}}，它的构成如下：

常量hotfix：表示这是一个功能分支
变量name：你的名字
变量bugName：bug名字好处是见名知意，一看就知道是bug修复分支，是谁负责，是什么bug

bug 发布 bug发布可以直接推送到待发布版本分支，比如1.1.1，然后CodeReview（如果有），然后合并主分支部署上线。

完整过程如下：

2.5 stash

一般我们修复bug的时候都在开发新功能，也就是在feat/*上，这时候如何快速进入bug修复状态呢？可以保存当前代码，提交commit，但是这时候会有一些问题，比如，1）当前的代码并未完成，并不想提交；2）commit有钩子，比如ESLint，必须修复语法问题才能提交。

这时候就是使用stash了。stash可以将当前工作区和暂存区的内容暂时保存起来，之后再使用。

如下：

开发功能中
```
$ echo "this is a feat" >> feat.txt
```

收到bug通知

$ git stash
Saved working directory and index state WIP on master: ef3450c feat: b

$ git switch master
$ git checkout -b hotfix/bugA
Switched to a new branch 'hotfix/bugA'

修复bug之后

$ git switch feat/A
$ git stash pop
On branch hotfix/bugA
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	new file:   feat.txt

Dropped refs/stash@{0} (32cf119fc1dcbe7088d1a12e290b868d6707526d)

stash命令有一整套完整的增删改查指令，可以查看git-pro 7.3 Git 工具 - 储藏与清理了解更多。

3. 新功能发布

新功能发布和bug发布有些不同，1）可能会有多个功能共同发布，需要提前合并，避免大冲突；2）可能有bug修复需要插队。3）可能需要等待后端发布，时间长。

因为（2），所有无法像bug发布那样直接推送到版本分支，等待发布。因为在真正发布之前，是无法知道准确版本的。

因为（1）、（3），所以需要提前合并，所以引入一个“日期分支”的概念，即以日期为分支名，比如pub/191205。

所以发布过程如下：

(其实我还画了一张贼复杂的图，把自己都恶心了，有空还是画个动态图吧（没空）)

0x003 标准化 commit message

标准化 commit message 可以参考阮一峰 - Commit message 和 Change log 编写指南。（阮一峰真的是写博客跨不过去的坎😢，写啥都可以引用他）

安装commitizen

$ npm install -g commitizen

在项目目录中初始化commitizen

$ commitizen init cz-conventional-changelog --save --save-exact

使用git cz代替git commit，以下是我常用的类型：

$ git cz
feat:       一个新功能
fix:        一个 bug 修复
docs:       只改变文档
refactor:   改变代码但是不添加或者修复功能，我一般用于优化或者重构
test:       添加测试代码
chore:      其他改变
style:      样式更新

0x004 commit 精细化管理

首先是为什么？为什么要管理commit，commit有啥好管理的？

在以前，我觉得git是用来记录代码操作的，我对代码的任何操作都应该被记录下来，而且就像历史一样，是神圣不可侵犯的。通过git历史，我必须要可以知道我在某一刻做了什么，就算我在一个commit添加了一行代码，然后在后一个commit删除了它，我也必须可以从log中看出来。

所以我的git历史中充满了各种无效的commit，因为有时候真的不知道如何为命名。

但是后来，我就想通了，我使用git的目标是不是为了记录，而是为了项目的稳定发展。只要实现了这个目的，手段不是问题，更何况git只是一个工具，工具是用来用的，不是用来供奉的。让自己快乐快乐才叫做意义。

所谓的管理commit，就是对commit执行增、删、改、拆操作。会在后面的章节一一列出。而管理的目的，是为了让每一个commit都有存在的意义，让Git成为项目管理真正的后盾。

后面的例子将同时提供SourceTree的操作，命令式可以看上一篇文章[前端漫谈]一巴掌拍平Git中的各种概念。

1. 排序 commit

场景：完成登陆页面之后，提交一个commit，message是feat(登陆): 完成登陆页面。然后进入其他功能的开发，之后又回到登陆页面的开发。提交记录如下：

我们有两个feat(登陆)或者多个相关的的commit，但是却分布于不同的地方，假设每一个feat(登陆)只会与前一个feat(登陆)有文件修改的交集，那么我们希望feat(登陆)相关的功能可以放在一起。如下：

如何实现：

2. 合并 commit

场景：完成登陆页面之后，提交一个commit，message是feat(登陆): 完成登陆页面。然后进入其他功能的开发，后来发现登陆有一个文案错误，继续修改，完成之后又提交一个commit，message为feat(登陆): 修改文案。提交记录如下：

在我看来，feat(登陆): 修改文案这个commit的存在是不应该的，比如，1）如果有一天我们需要单独上“登陆”功能，还有可能被遗漏；2）单独占据一个commit可能只是为了修复一个符号问题，在回溯历史的时候有不必要的浪费。也就是我希望一个commit它是独立的，不依赖后续commit的存在。

所以我希望将这两个commit合并：

操作过程：

3. 更新 commit

更新commit的场景有两个：

更新message
- 正好上面有一个不符合标准的message:
- 我希望改为：
- 操作说明
更新、添加、删除
- 1）有时候我们会通过修改某个变量来做一些测试，然后提交的时候突然发现忘记改回来；2）忘记或者误添加文件；3）忘记删除文件。这时候可以通过再创建一个commit再改回来，但是误添加的文件依旧会在历史中存在，占据一定的空间。我们可以根据上面的“合并”方式合并commit消除影响，也可以一步到位：
- feat(mine): 个人中心提交中有一个mime.html文件，我希望删掉bad line；还有一个mineBad.bad这么一个看起来坏坏的文件，我希望删除它。
- 操作过程（略复杂）:

4. 增加/分离 commit

增加一个commit的意义其实不大，在更新commit的过程中我们选择的是更正上一次提交，也就是git commit --amend，但是如果我们不选择，而是创建一个提交，其实就是增加一个commit了。
- 我希望在feat(mine): 完成个人中心和feat(main): 完成主页中间添加一个commit，可以通过新建一个commit然后之后通过前面的排序手段来做到，也可以一步到位：
- 操作过程（和前面差不多，只是不选择更正上一次提交）：
分离commit的意义重大，有时候我们希望只发布一个功能，却发现这个功能的commit中包含我们不希望发布的另一个功能，可能是因为本来要放到两个commit的功能误添加到一个commit，
- 我们有一个feat(detail): 完成详情页的commit，却不小心把other的功能给包含进去了，这时候我希望只发布detail页面，因此，对于commit的分离是必须的：
- 操作过程

5. 删除 commit

当我们做了一次修改后来发现这个修改没有必要，就可以删除这个commit，但是不推荐，除非真的确认。

在feat(detail): 完成详情页面后面做了一个不需要的提交：
删除步骤

7. cherry-pick

有时候，我们需要发布一个分支中的几个功能，比如我们在一次统一优化中修复了 5 个 bug，做了 5 个优化，但是其中几个并没有通过验证：

refactor/A 分支中有 3 个commit，通过了 2（用 ok 标记）个
fix/A 分支中有 3 个 commit，通过了 2（用 ok 标记）个

我们只能发布通过的 bug 修复和优化（标注了 ok 的），而这些修复和优化并不一定在哪个分支，是随机分布的：

在这种场景中，虽然可以用分支去处理，但是有点麻烦，这个时候 cherry-pick 是最好的工具。

操作过程

0x005 reflog

上面的很多操作都涉及到历史的操作，用普通的 revert 或者 reset 是无法消除影响的，只有在清楚这些命令的原理和本质的情况下才应该使用这些命令。但是对于这些操作也是有办法处理的，那就是 reflog：

在git中，所有的操作都会被记录下来，比如切换分支、合并分支等，可以使用 reflog查看这个记录，下面是cherry-pick例子产生的记录：

$ git reflog
# 执行 cherry-pick，一共 4 个 commit
b185e09 (HEAD -> pub/191206) HEAD@{0}: cherry-pick: feat(A): ok
dd67bf5 HEAD@{1}: cherry-pick: fix(A): ok
1d0237e HEAD@{2}: cherry-pick: feat(A): ok
51f808e HEAD@{3}: cherry-pick: refactor(A): ok
### 从 master 新建分支 pub/191206
a48cdd2 (master) HEAD@{4}: checkout: moving from master to pub/191206

如果我们撤销cherry-pick，可以执行以下命令：

$ git reset --hard HEAD@{4}
HEAD is now at a48cdd2 chore: 项目初始化

就没啦

再次查看reflog，多了一条记录

$ git reflog
a48cdd2 (HEAD -> pub/191206, master) HEAD@{0}: reset: moving to HEAD@{4}
b185e09 HEAD@{1}: cherry-pick: feat(A): ok
dd67bf5 HEAD@{2}: cherry-pick: fix(A): ok
1d0237e HEAD@{3}: cherry-pick: feat(A): ok
51f808e HEAD@{4}: cherry-pick: refactor(A): ok
a48cdd2 (HEAD -> pub/191206, master) HEAD@{5}: checkout: moving from master to pub/191206

撤销cherry-pick又后悔啦

$ git reset --hard HEAD@{1}
HEAD is now at b185e09 feat(A): ok

效果
又又后悔啦！！！滚

0x006 总结

勿忘初心，砥砺前行。我们一开始使用git是为了更好的辅助项目，而不是让项目更加复杂，如果不使用这些方式可以让你的项目更加简单，那就不要用，为了使用git而使用git，不如不使用。
要理解工具的原理，再去使用，不要盲目。使用上面的命令之前，务必了解这些命令或者操作背后发生了什么。

0x007 后记

我一直在寻找一种好的表达方式，从截图标注、绘图，到 gif 等，希望可以将文章讲的更加透彻。现在看来，可能还是 gif 比较好。
写一篇文章真的有点难啊，构思、布局、实验、总结，每一步都需要花很大的功夫，但是一篇精心总结的文章，对自己的帮助还是很大的，希望对各位也有帮助把。

0x008 资源

0x009 带货

最近发现一个好玩的库，作者是个大佬啊--基于 React 的现象级微场景编辑器。

[前端漫谈]Git 在项目中的完全控制实践

导读

0x000 前言

0x001 merge 还是 rebase

1. merge

2. rebase

3. merge 还是 rebase

0x002 多人合作开发

1. 新功能开发

2. bug 修复及其发布

2.5 stash

3. 新功能发布

0x003 标准化 commit message

0x004 commit 精细化管理

1. 排序 commit

2. 合并 commit

3. 更新 commit

4. 增加/分离 commit

5. 删除 commit

7. cherry-pick

0x005 reflog

0x006 总结

0x007 后记

0x008 资源

0x009 带货

0x001 `merge` 还是 `rebase`