git 工作流

发表于

git 是目前最流行的源代码管理工具，Git 的确可以在各个方面做很多事情，然而任然存在采用何种分支管理的问题，Git 分支管理并没有普遍适用的最佳做法，只有对每个团队和项目而言最适合的工作流。
git 的操作还是有一定复杂度的，错误的操作影响也比较大，异步小心就会导致部分代码丢失，还很难查到具体出问题的时间点和功能点。

我们采用的是 git-flow 流程,包含 4 类分支，分别是 master、develop、新功能分支（feature）和 hotfix。

新建仓库

在 github 中创建一个新的仓库，只有一个 master 分支

新建分支

每次开发新功能，都应该从当前主开发分支新建一个功能分支。

1
git checkout -b feature-wz-qx

提交分支

模块开发差不多，提交代码

1
2
3
git status
git add -F
git commit -m 'add xxxxx'

关于 commit 完整的 log 由 类别(必须) 简短描述(必须) 详细描述(可选) 三部分组成：

  • 类别
    • add 增加
    • fix 修复 bug
    • change 修改
    • del 移除
    • refactor 代码重构
    • docs 文档

eg:

1
git commit -m 'add xxxxx'

如果增加详细描述，具体内容前空一行，兼容 Markdown。
还可以可以配合 gitmoji 强化信息可读性。

合并提交记录

为了避免太多的 commit 而造成版本控制的混乱，通常我们推荐将这些 commit 合并成一个。假如我们提交了四次记录。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
commit 14c69cf825c17bd3e48154994e6f722db251fcfb
Author: lennonover <lennonover@163.com>
Date:   Tue Jan 23 16:38:57 2018 +0800

    add forth 

commit 969161b68ab3b479fc52a26c4f053395ce4f3c63
Author: lennonover <lennonover@163.com>
Date:   Tue Jan 23 16:01:12 2018 +0800

    add third 

commit 44adff48febeb65e5f89e2dc18ecc3ba7c9c31ba
Author: lennonover <lennonover@gmail.com>
Date:   Tue Jan 23 15:56:27 2018 +0800

    add second 

commit a897c7ac82eb2de3e8268454d19f2ec91a5be9bd
Author: lennonover <lennonover@gmail.com>
Date:   Tue Jan 23 15:56:04 2018 +0800

    add first

如何把四次合并到一起，并且只保留 最后一次 的 Git message 呢？推荐 git rebase 进行合并操作。

合并最后四个

1
git rebase -i HEAD~4

git 会打开一个互动界面，方便用户对历史提交进行修改

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
pick 969161b add first
pick 14c69cf add second 
pick b246936 add third
pick 5b192dc add forth 

# Rebase 44adff4..5b192dc onto 44adff4 (4 command(s))
#
# Commands:
# p, pick = 使用该提交
# r, reword = 使用该提交，但需要编辑提交信息
# e, edit = 使用该提交，但此处暂停并提供修改机会
# s, squash = 使用该提交，但合并到上一个提交记录中
# f, fixup = 类似 squash，但丢弃当前提交记录的提交信息
# x, exec = 执行 shell 命令
# d, drop = 移除当前提交

我们需要把前面的 pick 改为 squash 这样：

1
2
3
4
pick 969161b add first
squash 14c69cf add second 
squash b246936 add third
squash 5b192dc add forth

完成后，使用 :wq 保存并退出。这个时候则需要在下一步中对这 4 条 commit 信息进行修改和保存(如果 fixup 的话，则直接丢弃其它记录，省去下一步操作)：

1
2
3
4
5
6
7
8
9
# This is a combinatin of 4 commits.
# This is the 1st commit message:
add first 
# This is the commit message #2:
add second 
# This is the commit message #3:
add third
# This is the commit message #4:
add forth

使用 :wq 后，通过 git log 可以看到仅剩一条 commit 记录：

1
2
3
4
5
commit c2391a59bf51240a60ab4c8455b251cff1ec3cdd
Author: lennonover <lennonover@163.com>
Date:   Wed Jan 24 15:01:12 2018 +0800

    add stylelint-0.0.3

rebase 的风险：

当待合并 commit 记录中杂糅着他人的 commit 记录，此时就不可以再对这部分 commit 记录做合并操作。

但只要新开分支且保持分支独立开发，杂糅的情况就不存在。

推送到仓库

1
git push origin feature-wz-qx

提交 Merge Request 申请

请求相关同学从你的 feature-wz-qx 合并分支

  • 提交 Merge Request：

通过「＋Create Merge Request」按钮创建一个 Merge Request；

  • 指定「Assignee」：

指定需要 review 你代码的同学，禁止指定自己；

  • 更改「Target branch」：

改变为需要合并进去的目标分支；

  • 设置合并后删除被合并分支的选项：

勾选「Remove source branch when merge request is accepted.」选项，在合并完成后删除源分支，控制分支总数量；

  • 提交合并请求

完成上述设置后，相关同学将会收到邮件通知，此时可进入 GitLab 进行 code review。如果发现问题则对问题代码进行点评并拒绝关闭申请，反之则通过合并申请。

修复 Bug

发现 bug 了,从 develop 分支上新建分支

1
git checkout -b hotfix/xxx develop

改完推送到仓库后提交 Merge Request 申请

减少冲突

从我们的工作流程上来说，代码合并导致的问题，一般都发生在特性、修复分支合并到 master 或者 develop 的时候，因为这个时候开始，才是真正与其他分支汇合，不同的改动会发生冲突。而且合并没法完全避免，我们只能去思考如何减少合并冲突。

  • 合理的分工，人员职责划分尽量清晰，减少互相之间的交叉，减少多个人同时改动同一份代码的几率
  • 合适的合并工具
  • 合并后的代码检查
  • 公共代码改动，要通知各使用方变化点
  • code review