前端开发-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创建一个新的分支
git branch feature/me1124
然后经历了N次提交，测试后准备上线。
假设此时我们的版本是1.0.0
使用merge
// 从master分支创建release/1.0.0分支
git checkout -b release/1.0.0
git merge feature/me1124
git branch -d feature/huafang
使用rebase
// 从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
git checkout master
git merge release/v1.0.0
git tag v1.0.0
git branch -d release/v1.0.0
使用rebase
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:
-
存在多个业务需求并行开发，并在同一个版本发布的情况。
-
开发过程中有线上bug修复。
-
1，2情况需要进行回归测试。
-
使用release分支在语义上更加符合开发流程。
线上bug修复
线上bug修复的逻辑和新需求开发基本一致，个别地方有所区别。
假设我们需要修复一个名为missing-phone的bug，
git checkout master
git branch hotfix/missing-phone
然后经历了N次修复，测试完毕后准备上线。
与feature分支不同的是，hotfix分支的代码基于稳定的功能，测试完毕后不需要通过release分支即可发布上线。hotfix分支同样需要打上tag.
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标签了。
