GitFlow工作流介绍

---

author:

• 徐子木

---

git原理过程

在工作中我们使用git时一般的流程是这样的

1. 从服务器上做 git pull origin master先去把代码同步下来
2. 做好自己工作后,git commit到本地仓库
3. 然后git push origin master到远程仓库,这样项目内人员就会得到你的代码

冲突情况
如果在push步骤发现失败,一般是因为别人已经提交了,那么你需要先把服务器上的代码给pull下来,为了避免有merge动作, 使用git pull --rebase ,从服务器上的提交合并到你的代码中,然后再本地一个一个的解决冲突 随后提交

当项目人员对git的分支情况掌握不了解,并且项目没有清晰的CI CD流程,那么难免会有人员内部扯皮,所以避免这种情况发生,通常公司都会采用规范的GitFlow工作流来处理分支走向

image.png

GitFlow五大分支介绍

• Master 也就是主干分支,也就是发布环境,或生产环境
• Feature 功能分支,用于开发者单独开发功能,隔离多个开发者代码上传
• Developer 开发分支,当开发人员在Feature分支开发完成,就会像Developer分支合并,合并完成后删除功能分支
• Release 版本分支,当Developer分支测试可以达到发布时,会开出一个Release分支做发布前准备工作,对应预发环境,也可作为一个版本节点,常用于项目中结算一个当前版本的最终迭代.
  当Release分支可以达到上线的状态,则向Master分支和Developer分支同事合并,以保证代码的一致性,随后删除Release分支
• Hotfix 补丁分支,用于处理生产线上代码的Bug-fix,当线上环境遇到紧急bug需要修复,时常会开一个Hotfix分支,完成后像Developer和Master分支合并,随后删除Hotfix

---

结合日常工作使用总结

1. 架构师先构建好项目底层框架代码,随后建立Master rebase版本,或使用sourcetree等工具初始化工作流
2. 初始化工作流,会同时产生2个分支 Master ,Developer
3. 开发人员进入工作,从Developer分支检出单独的Feature分支去开发
4. 当所有开发人员完成工作,将各自的Feature分支向Developer分支合并
5. Developer分支交给测试人员介入,当功能验证完毕后检出Release分支发布至预发环境
   6.Release分支可作为一层版本迭代的存档点,并且在预发环境一阵时间运行流程,那么发布最终生产环境Master
6. 当Master出现紧急bug -fix,则打出Hotfix补丁分支并修复代码,验证无误后向Master和Release分支同时向下兼容合并

规范及建议

在建立Gitflow分支时,应当严格遵守工作流分支命名规范,如下图

image.png

我的个人习惯如,功能分支则取为 "feature/20220202(时间点)/xxxx(功能意义)",可参考