author:
- 徐子木
git原理过程
在工作中我们使用git时一般的流程是这样的
- 从服务器上做 git pull origin master先去把代码同步下来
- 做好自己工作后,git commit到本地仓库
- 然后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
结合日常工作使用总结
- 架构师先构建好项目底层框架代码,随后建立Master rebase版本,或使用sourcetree等工具初始化工作流
- 初始化工作流,会同时产生2个分支 Master ,Developer
- 开发人员进入工作,从Developer分支检出单独的Feature分支去开发
- 当所有开发人员完成工作,将各自的Feature分支向Developer分支合并
- Developer分支交给测试人员介入,当功能验证完毕后检出Release分支发布至预发环境
6.Release分支可作为一层版本迭代的存档点,并且在预发环境一阵时间运行流程,那么发布最终生产环境Master - 当Master出现紧急bug -fix,则打出Hotfix补丁分支并修复代码,验证无误后向Master和Release分支同时向下兼容合并
规范及建议
在建立Gitflow分支时,应当严格遵守工作流分支命名规范,如下图
image.png
我的个人习惯如,功能分支则取为 "feature/20220202(时间点)/xxxx(功能意义)",可参考
