版本号使用x.x.x.x进行定义.
简称 | 全称 | 作用 |
---|---|---|
DEV | Development environment | 用于开发者调试使用 |
FAT | Feature Acceptance Test environment | 功能验收测试环境,用于测试环境下的软件测试者测试使用 |
UAT | User Acceptance Test environment | 用户验收测试环境,用于生产环境下的软件测试者测试使用 |
PRO | Production environment | 生产环境 |
分支 | 名称 | 作用 |
---|---|---|
master | 主分支 | 用于生产部署,最新稳定版本,一般由 release 或 hotfix 分支合并,任何情况下不允许直接在 master 分支上修改代码。 |
release | 预上线分支 | 预上线分支,是develop与master之间的一个缓冲,始终保持与 master 分支一致,一般由 develop 或 hotfix 分支合并,不建议直接在 release 分支上直接修改代码。(UAT) |
hotfix | 紧急修复分支 | 紧急分支,名规则为 hotfix- 开头,从master生成,bug修正后自动合并到master和develop并且生成tag; |
develop | 测试分支 | 功能验收测试环境,用于测试环境下的软件测试者测试使用,可根据需求大小程度确定是由 feature 分支合并,还是直接在上面开发。,FAT,如果开发工时 < 1d,直接在 develop 开发,如果开发工时 > 1d,那就需要创建分支,在分支上开发。 |
feature | 需求开发分支 | 用于开发新需求和需要较长时间的BUG修改,(正式环境) 测试通过后,研发人员需要删除 feature- 分支。 |
提交信息一定要认真填写!
建议参考规范:(scope):
比如:fix(首页模块):修复弹窗 JS Bug。
type 表示 动作类型,可分为:
fix:修复 xxx Bug feat:新增 xxx 功能 test:调试 xxx 功能 style:变更 xxx 代码格式或注释 docs:变更 xxx 文档 refactor:重构 xxx 功能或方法 scope 表示 影响范围,可分为:模块、类库、方法等。
subject 表示 简短描述,最好不要超过 60 个字,如果有相关 Bug 的 Jira 号,建议在描述中加上。
git flow feature start xxxxx(开始新需求) 在feature/xxxxx分支下进行开发 git flow feature finish xxxxx(开发完成后等待研发经理确认可以完成时执行) git push origin develop(发布develop分支) 每天工程师都需要git pull origin develop来更新develop分支,然后将develop分支合并到你正在开发得feature/xxxxx分支上来保持代码最新 切记不能直接在develop上进行开发
开发和DEBUG流程同工程师流程
研发经理必须维护release分支,将最新的hotfix都合并进去,保证代码最新,减少合并时的冲突。
在提交代码时还要注意判断对代码的修改是否是自己的,多用diff工具,多查看log,防止代码回溯