前端开发-Gitflow

发表于 | 分类于 | 阅读次数:

主要分支

master

master分支存在于整个项目周期，主分支。master分支不能有任何代码的提交，开发人员只能从其他分支提交PR（pull request），由项目负责人合并。

Q: 为什么没有develop分支

A: develop分支的职责已经分配到feature和hotfix中，将临时分支的修改合并到develop后再合并到master好像没有意义。为了避免引起困惑，所以移除develop分支。

临时分支

feature

feature分支用于开发新的功能，不同业务应该建立不同的feature分支。

  • 从master分支创建

  • 开发测试完成合并至release后删除

release

release分支用于预发布和回归测试。

  • 从master分支创建

  • 发布完成后打上tag合并至master后删除

hotfix

hotfix分支用于修复线上问题。

  • 从master分支创建

  • 发布完成打上tag合并至master后删除

示例

新需求开发

假设项目有一个名为me1124的需求，我们从master创建一个新的分支

1
git branch feature/me1124

然后经历了N次提交，测试后准备上线。

假设此时我们的版本是1.0.0

使用merge

1
2
3
4
// 从master分支创建release/1.0.0分支
git checkout -b release/1.0.0
git merge feature/me1124
git branch -d feature/huafang

使用rebase

1
2
3
4
5
6
7
// 从master分支创建release/1.0.0分支
git checkout -b release/1.0.0
git checkout feature/me1124
git rebase release/1.0.0
git checkout release/1.0.0
git merge feature/me1124
git branch -d feature/me1124

在release/v1.0.0分支进行最终测试后，我们打上tag并变基到master，并删除release分支。此处tag的应该和版本号保持一致。

使用merge

1
2
3
4
git checkout master
git merge release/v1.0.0
git tag v1.0.0
git branch -d release/v1.0.0

使用rebase

1
2
3
4
5
git rebase master
git tag v1.0.0
git checkout master
git merge release/v1.0.0
git branch -d release/v1.0.0

Q: 为什么不直接从feature分支合并到master呢

A:

  1. 存在多个业务需求并行开发，并在同一个版本发布的情况。

  2. 开发过程中有线上bug修复。

  3. 1，2情况需要进行回归测试。

  4. 使用release分支在语义上更加符合开发流程。

线上bug修复

线上bug修复的逻辑和新需求开发基本一致，个别地方有所区别。

假设我们需要修复一个名为missing-phone的bug，

1
2
git checkout master
git branch hotfix/missing-phone

然后经历了N次修复，测试完毕后准备上线。

与feature分支不同的是，hotfix分支的代码基于稳定的功能，测试完毕后不需要通过release分支即可发布上线。hotfix分支同样需要打上tag.

1
2
3
4
5
git rebase master
git tag v1.0.1
git checkout master
git merge hotfix/missing-phone
git branch -d hotfix/missing-phone

Merge vs Rebase

并不强制使用merge或者rebase。但是为了避免冲突，同一个项目尽量使用同一个方式。

参考文档：

Merge

优势在于操作简单，不易出错，而且是很多工具的默认合并方式。

缺点在于协同开发时，2个分支如果都有修改，合并后图形会出现岔路，看起来有些混乱（也有观点认为还原了历史）。

Rebase

优势在于分支的图形线性，清晰。

缺点在于：

  • 协同开发时，拉取远程代码要使用变基拉取(git pull – rebase)。不然在分支变基时要重新解决冲突（简单理解就是之前的提交记录当做patch重新应用，那么之前有冲突也会复现）。

End

以上内容来源于杨骐彰同学的分享，此工作流优点在于维护的分支较少，思路清晰，项目就master和正在开发的分支，剩下的就只有tag标签了。

0%