| 首先，不同项目不同团队git的规范和习惯会有区别 |
|
| 使用原生git更自由和定制化，为了简单不少项目会选择git flow的方案 |
|
| 使用git flow的，一方面是简化规范一些操作，避免可能因不熟悉git和多人操作的冲突,因为git flow是在git的一个受约束的环境和规范下使用git，分枝管理并不如git一样自由 |
|
| 一般的简单项目的上线环境分为测试，预览，正式，再深入到灰度/金丝雀，ci/cd自动上线的话，需要规范好git branch/tag 和 测试/预览/正式的关系 |
|
|
|
|
|
|
|
| 则项目的开发流程如下 |
|
| * 1 git flow feature start feature_01 |
|
| 在develop分枝上新建feature_01分枝 |
|
| * 2 git commit -a -m "feature_01 finish" |
|
| 在feature_01分枝开发完成后提交更改 |
|
| * 3 git flow feature finish feature_01 |
|
| 将feature_01分枝merge至develop分枝，cicd自动执行布署test运行环境 |
|
| * 4 git flow release start v0.1 |
|
| 在develop上新建v0.1分枝,在这个分枝上可以再做一部分修改，但不建议这样操作。 |
|
| * 5 git commit -a -m "release_v0.1 finish" |
|
| 提交修改 |
|
| * 6 git flow release finish v0.1 |
|
| merge release_v0.1分枝至master，cicd自动执行布署preview运行环境 |
|
| 发布为该次合并的结果创建tag 例如v0.1，cicd自动执行布署prod运行环境 |
|
|
|
| --- |
|
| 补充 |
|
| 主要纠结在git flow和gitlab runner结合的切入点 |
|
| git flow 流程里分三类master develop tag |
|
| develop对应test环境，通常都没有疑问 |
|
| 默认git push会提交master分枝,而tag需要手动指定 |
|
| master分枝做为prod的话容易误操作，小型项目/单人维护的项目的版本控制没这么严格，太严格了反而低效，developer基本都有master操作权限。 |
|
| 为避免误提交至master，因此把master做为preview环境，tag作为prod环境。 |
|
| 也可以禁用developer的master权限，所有master在gitlab/github页面手动审核，也是种办法，这要根据个人/团队的习惯，项目规模的大小而定。 |
