首页手记投稿004期|gitflow开发流程学习（第一部分）

投稿004期|gitflow开发流程学习（第一部分）

标签：

前端工具

gitflow 流程是非常专业而且标准的 git 处理流程，因为要学习其核心思想和应用，故有此文章系列，本文章系列会分为两部分，第一部分学习基本的内容和基础的流程，第二部分会学习其他流程和hotfix，release 和 tag 之类的高级用法。

一、gitflow 的分支学习

项目中长期存在的两个分支：

master：主分支，负责记录上线版本的迭代，该分支代码与线上代码是完全一致的。
develop：开发分支，该分支记录相对稳定的版本，所有的feature分支和bugfix分支都从该分支创建。

在 gitlab 里面可以设置这2个分支的权限是受保护的，只允许某些人才能进行操作。

其它分支为短期分支，其完成功能开发之后需要删除：

feature/*：特性（功能）分支，用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 develop 分支，之后删除该分支。
bugfix/*：bug修复分支，用于修复不紧急的bug，普通bug均需要创建bugfix分支开发，开发完成自测没问题后合并到 develop 分支后，删除该分支。
release/*：发布分支，用于代码上线准备，该分支从develop分支创建，创建之后由测试同学发布到测试环境进行测试，测试过程中发现bug需要开发人员在该release分支上进行bug修复，所有bug修复完后，在上线之前，需要合并该release分支到master分支和develop分支。
hotfix/*：紧急bug修复分支，该分支只有在紧急情况下使用，从master分支创建，用于紧急修复线上bug，修复完成后，需要合并该分支到master分支以便上线，同时需要再合并到develop分支。

标准的流程如下图：

因为这些图涉及的流程太多，一下子很难接受，所以需要逐个分解来学习。

二、真实应用案例学习理解

项目背景：有一群人共同开发一个 blog 系统。

需要角色：

开发人员（负责代码开发，包含新功能，修复 bug）
开发人员leader（负责代码 review，审核代码，合并代码到 develop 和 master 分支）
测试人员（测试检查功能或者 bug 修复是否正常）
部署人员（将代码发布到线上环境）

项目人员：

开发人员： a、b
开发leader：c
测试人员： d
部署人员：e

项目分工：

a 负责 articles 文章模块，b 负责 login 登录模块
c 负责审核和合并代码（代码 review和合并代码到 develop 和 master 分支），a 和 b 开发的模块代码
d 需要等模块开发完毕后，才能进行测试
测试正常的情况下，e 才会执行部署

（一）基本开发流程

首先学习一个基本的流程，类似下图，但是本次暂时不涉及 tag 处理：

先创建一个服务端代码仓库，用 gitlab 来管理这个仓库，名字叫做 blog-project，仓库地址是git@xxx服务器地址/blog-project.git。

项目刚开始，分支并不需要那么多，在代码仓库里只需要建两个分支即可：

// 远程服务器上代码
master  // 默认主分支（受保护）
develop // 开发分支（受保护）

备注：

master 和 develop 分支是受保护分支，除了个别人员，例如 leader 外无法操作。
因为我们使用的 gitlab，项目一开始可以暂时手工操作项目的初始化信息，所以直接在界面建立分支，后期可以不使用界面创建分支。

开发者 clone 这个库下来到本地：

// git 命令
git clone git@xxx服务器地址/blog-project.git

// clone 后每个人的本地仓库都如下：
master  // 默认主分支
develop // 开发分支

备注：

所有相关参与的开发者都要 clone 这个库。
部署人员和测试人员按需 clone。

项目正式开始后，我们需要分工开发，有以下两种情况我们会遇到：

人手充足，时间充足，各自功能都能归到各人头上，并且能够很好的开发完成。
1. a 单独负责feature/articles功能。
2. b 单独负责feature/login功能。
人手不足，时间不充足，各自的功能可能需要各人混合开发，使用共享分支合力完成开发。
1. feature/login和feature/articles功能都成为共享分支，所有人都参与开发

1. 针对第一种情况：开发者 clone 远端代码仓库后，不同的开发者进入不同的分支进行开发：

// 开发者 a 执行 git 命令
// 创建feature/articles 功能分支，并直接切换到该分支上进行开发
git checkout -b feature/articles

// 开发者 b 执行 git 命令
// 创建feature/login 功能分支，并直接切换到该分支上进行开发
git checkout -b feature/login

那么现在开发者 a 和 b 本地的代码库如下：

// 开发者 a 
master  // 默认主分支
develop // 开发分支
feature/articles // 功能分支 articles 模块

// 开发者 b
master  // 默认主分支
develop // 开发分支
feature/login // 功能分支 login 模块

备注：

因为 clone 整个项目，所以 master 和 develop 分支也会存在于本地，但因为受保护，所以无法提交。
feature 相关分支是从 develop 分支拉取的，基点在当前的 develop head 位置。
各自开发者不同的feature 功能分支，互不干涉。

开发完成后各自提交代码到远端代码仓库：

// 开发者 a
git add . // 添加当前目录所有文件的改动到本地 git 仓库
git commit --m "Add user API" // 需要按照 commit 规范，这个只是样例
git push origin feature/articles // 

// 开发者 b
git add . // 添加当前目录所有文件的改动到本地 git 仓库
git commit --m "Add user API" // 需要按照 commit 规范，这个只是样例
git push origin feature/login

备注：

需要注意的是 commit 需要按照一定的规范来做，这些对整个项目都比较好，文章后面会徐徐道来。
上例只是描述一个基本过程，开发代码可能会多次添加add和提交 push，这里只是做一个示范。
git add 是添加文件到本地git仓库缓冲区，换句话来说，是将有改动的文件放在本地的 git 代码仓库中，以便记录版本和提交版本。
- 上例只是描述一个基本过程，但是在开发的过程中，可能只需要添加某个文件，不需要添交所有文件

2. 针对第二种情况：开发者 clone 远端代码仓库后，不同的开发者进入相同的分支进行开发（共享分支）：

// 开发者 a 执行命令，切换到相应到分支
git fetch  // 取回远端所有分支（branch）的更新
git checkout feature/articles // a 切换到feature/articles分支
git pull origin feature/articles // 拉取远端feature/articles分支的所有更新到本地代码
git checkout feature/login // a 切换到feature/login分支
git pull origin feature/login // 拉取远端feature/login分支的所有更新到本地代码

// 开发者 a 的本地代码
master  // 默认主分支
develop // 开发分支
feature/articles // 功能分支 articles 模块
feature/login // 功能分支 login 模块

// 开发者 b 执行命令，切换到相应到分支
git fetch  // 取回远端所有分支（branch）的更新
git checkout feature/articles // b 切换到feature/articles分支
git pull origin feature/articles // 拉取远端feature/articles分支的所有更新到本地代码
git checkout feature/login // b 切换到feature/login分支
git pull origin feature/login // 拉取远端feature/login分支的所有更新到本地代码

// 开发者 b 的本地代码
master  // 默认主分支
develop // 开发分支
feature/articles // 功能分支 articles 模块
feature/login // 功能分支 login 模块

解释：

这里feature/articles 分支和feature/login分支都会由开发者 a 或者 b 同时开发，因为是在共享分支开发，所有有可能会有共享冲突的问题，在代码开发之前，应先更新好本地代码仓库，可以减少冲突的发生。
在共享分支开发的时候，有很多机会发生代码合并冲突的，这个时候 git 会提醒开发者进行合和解决冲突（git merge conflict）

备注：

这里先使用 fetch 的用意在这里：与git pull相比git fetch相当于是从远程获取最新版本到本地，但不会自动merge。如果需要有选择的合并git fetch是更好的选择。
- 由于git pull把过程的细节都隐藏了起来，以至于你不用去了解git中各种类型分支的区别和使用方法。当然，多数时候这是没问题的，但一旦代码有问题，你很难找到出错的地方。
- 将下载（fetch）和合并（merge）放到一个命令里的另外一个弊端是，你的本地工作目录在未经确认的情况下就会被远程分支更新。
- 单独进行下载和合并是一个好的做法，你可以先看看区别（diff），然后再决定是否和本地代码合并。而且分开来做，可以清晰的区别开本地分支和远程分支，方便选择使用。所以尽量少用git pull，多用git fetch和merge。

3. 最终顺利完成某个功能开发

开发者本地进行来基本的测试验证，确认功能满足需求，并且没有大的问题，然后会由开发者 leader 在 gitlab 上进行分支合并：

由开发者 leader c 来进行合并，将feature/articles 和 feature/login 分支合并到 develop 分支，合并完成后删除源分支（feature/articles 和 feature/login）。

至此使用基本流程完成开发。

三、备忘学习Commit规范和合并冲突解决

（一）关于合并冲突解决

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
最简单的编辑冲突的办法，就是直接编辑冲突了的文件（test.txt），把冲突标记删掉，把冲突解决正确。

发生冲突的地方不止 pull 还有 merge 和 rebase，只要发生合并的地方就可能会有冲突的发生。

以下例子以 git pull 来样例:

// git pull 拉取代码的时候发生冲突了
git pull XXXXX

// 报错提示
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.

// 冲突文件 test.txt 内容
a123
<<<<<<< HEAD
b789
=======
b45678910
>>>>>>> 6853e5ff961e684d3a6c02d4d06183b5ff330dcc
c

解释：

这个地方的提示意思是在文件 test.txt 内容中，在 a123和 c 之间有一个地方发生了冲突，有一部分是我修改的内容，有一部分是别人修改的内容。
其中：冲突标记<<<<<<<与=======之间的内容是我的修改，=======与>>>>>>>之间的内容是别人的修改。
- 如果保留我的修改，那么删掉别人的修改即可。
- 反之亦然。
- 如果各取一半，那么你可以将他们全部提取出来，删掉不需要的，改掉不符合的，然后再放回去。

备注：

如果无法确认是否有冲突，也不想执行一次 pull来触发检查，可以使用git status命令查看。

// 执行 git 命令
git status

// 输出提示
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)
// 你可以放弃合并，git merge --abort 选项会尝试恢复到你运行合并前的状态。
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
// 冲突的文件
    both modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

你可以通过 git diff --base来查看文件在两边是如何改动的。

// 执行 git 命令
git diff --base -b  // -b 是为了去除空白内容

// 输出信息
* Unmerged path hello.rb
// 结果为git格式的diff。
// 进行比较的是，a版本的f1（即变动前）和b版本的f1（即变动后）。
diff --git a/hello.rb b/hello.rb
index ac51efd..44d0a25 100755
// "---"表示变动前的文件，"+++"表示变动后的文件。
--- a/hello.rb
+++ b/hello.rb
// 前面的"-1,7"分成三个部分：减号表示第一个文件（即f1），"1"表示第1行，"7"表示连续7行。合在一起，就表示下面是第一个文件从第1行开始的连续7行。同样的，"+1,8"表示变动后，成为第二个文件从第1行开始的连续9行
@@ -1,7 +1,8 @@
// 文件内容的每一行最前面，还有一个标记位。如果为空，表示该行无变化；如果是感叹号（!），表示该行有改动；如果是减号（-），表示该行被删除；如果是加号（+），表示该行为新增。
 #! /usr/bin/env ruby

+# prints out a greeting
 def hello
-  puts 'hello world'
+  puts 'hello mundo'
 end

 hello()

如果有强烈意愿只保留自己的代码的情况下也是可以的：
- 使用gitpush origin master --force或gitpush origin master -f。但是这种方式存在覆盖掉其他人提交的危险，当确定不会影响到其他人提交的情况下可以使用，比如使用gitcommit –amend修改提交日志等情况。

（二）Commit规范

为什么需要 commit 规范？主要是为了看清楚每次 commit 的内容，清楚知道 commit 变动的地方，从而方便排错和控制代码。

1. commit 的原则：

提交时的粒度是一个小功能点或者一个 bug fix，这样进行恢复等的操作时能够将「误伤」减到最低。
用一句简练的话写在第一行，然后空一行稍微详细阐述该提交所增加或修改的地方。
不要每提交一次就推送一次，多积攒几个提交后一次性推送，这样可以避免在进行一次提交后发现代码中还有小错误。
commit 规范的内容规则如下：

// 提交类型
feat: 添加新特性
fix: 修复bug
docs: 仅仅修改了文档
style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
refactor: 代码重构，没有加新功能或者修复bug
perf: 增加代码进行性能测试
test: 增加测试用例
chore: 改变构建流程、或者增加依赖库、工具等

// 提交范围 scope
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

// 提交的subject内容
subject是 commit 目的的简短描述，不超过50个字符。
以动词开头，使用第一人称现在时，比如change，而不是changed或changes
第一个字母小写，结尾不加句号（.）

// 提交的 body 内容
Body 部分是对本次 commit 的详细描述，可以分成多行。

2. 一个标准且优美的 git 提交记录图应该是这样的：

3. 要实现规范的 commit 则需要安装一些工具来简化操作：

npm install -g commitizen 这个是一个格式化commit message的工具。
npm install -g conventional-changelog-cli 这个是生成changelog的工具，changelog 是为了将这些格式化的 commit message 生成一个 CHANGELOG.md文件的，这个文件可以规范看到提交的内容（如上图一个标准且优美的 git 提交记录图）。

4. 执行过程：

// 执行git 命令
git cz 

// 输出  
cz-cli@2.10.1, cz-conventional-changelog@2.1.0

Line 1 will be cropped at 100 characters. All other lines will be wrapped after 100 characters.
// 提示输入你的 commit类型，他会弹出提示给你选择
? Select the type of change that you're committing: fix:      A bug fix
// 提示输入你的 scope类型，没有可以跳过
? What is the scope of this change (e.g. component or file name)? (press enter to skip)
 test
// 提示输入你的 subject，即标题
? Write a short, imperative tense description of the change:
 我来测试这个 commit 格式
// 提示输入你的 body 内容，就是详细信息
? Provide a longer description of the change: (press enter to skip)
 详细
? Are there any breaking changes? No
// 当你有使用 issues 的时候就会关联到 issues
? Does this change affect any open issues? No
[master a4fd22c] fix(test): 我来测试这个 commit 格式
 3 files changed, 14 insertions(+), 1 deletion(-)

提交记录会变成这样（使用 git log 命令可以查看）：

// 输出结果是
fix(test): 我来测试这个 commit 格式
详细

至于 CHANGELOG.md内容则如下：

<a name="1.0.0"></a>
# 1.0.0 (2017-03-05)
### Bug Fixes
* fixed ([a9c3110](https://192.168.2.107/zpu/hello-koa/commits/a9c3110))
### Features
* add something ([53becaa](https://192.168.2.107/zpu/hello-koa/commits/53becaa))

解析 md 文件之后，会很清晰的知道每个版本或者提交都负责了那些内容，类似这样：