西安外贸网站建设公司,做业务在那几个网站上找客户端,wordpress仿站插件,建站用wordpress好吗分支命名
master 分支 master 为主分支#xff0c;也是用于部署生产环境的分支#xff0c;需要确保master分支稳定性。master 分支一般由 release 以及 hotfix 分支合并#xff0c;任何时间都不能直接修改代码。
develop 分支 develop 为开发环境分支#xff0c;始终保持…分支命名
master 分支 master 为主分支也是用于部署生产环境的分支需要确保master分支稳定性。master 分支一般由 release 以及 hotfix 分支合并任何时间都不能直接修改代码。
develop 分支 develop 为开发环境分支始终保持最新完成以及bug修复后的代码用于前后端联调。一般开发的新功能时feature分支都是基于develop分支创建的。
feature 分支 开发新功能时以develop为基础创建feature分支。 分支命名时以 feature/开头后面可以加上开发的功能模块 命名示例feature/user_module、feature/cart_module 主线开发分支每个迭代只有一个主线开发分支大部分功能在这个分支上开发 命名规范 feature-${迭代发版日期}-${版本号}例如 feature-20220710-1.3.0 支线开发分支用于主线开发分支并行的支线功能开发由于此类功能开发周期长与主线功能相对独立为避免开发过程对主线分支造成影响单独拉出支线分支 命名规范 以主线开分支命称为前缀即可例如 feature-20220710-1.3.0-springboot-upgrade其中前缀feature-20220710-1.3.0 对应的主线开发分支名称
我们现在版本号我们用产品Prd 定义的为准
test分支 test为测试环境分支外部用户无法访问专门给测试人员使用版本相对稳定。
release分支 release 为预上线分支预发布分支UAT测试阶段使用。一般由 test 或 hotfix 分支合并不建议直接在 release 分支上直接修改代码。
Uat 分支同release Uat 分支为交付验收分支其实和release的作用一样
hotfix 分支 线上出现紧急问题时需要及时修复以master分支为基线创建hotfix分支。修复完成后需要合并到 master 分支和 develop 分支test/uat cherry pick 合并 同时保证问题再其他主线分支上修复。 分支命名以hotfix/ 开头的为修复分支它的命名规则与 feature 分支类似。 分支与环境对应关系
在系统开发过程中常用的环境 DEV 环境Development environment用于开发者调试使用 FAT环境Feature Acceptance Test environment功能验收测试环境用于测试环境下的软件测试者测试使用 UAT环境 User Acceptance Test environment用户验收测试环境用于生产环境下的软件测试者测试使用 PRO 环境Production environment生产环境
对应关系
分支功能环境可访问合并人员master主分支稳定版本PRO是运维人员管理develop开发分支最新版本DEV是研发人员feature开发分支实现新特性否研发人员test测试分支功能测试FAT是测试人员管理releasecat预上线分支发布新版本UAT是测试人员、运维人员管理hotfix紧急修复分支修复线上bug否运维人员管理
分支合并流程规范 业界常见的两大主分支master、develop、三个辅助分支feature、release、hotfix的生命周期 以上生命周期仅作参考不同开发团队可能有不同的规范可自行灵活定义。
例如我们团队在开发时至少需要保证以下流程 develop 分支和 hotfix 分支必须从 master 分支检出 由 develop 分支合并到 test 分支 功能测试无误后由 test 分支合并到uat 分支 UAT测试通过后从master 拉 release 分支将uat 和 新拉的 release中 , 线上验证没问题再 合并到 master分支 对于工作量小的功能开发工时小于1天可以直接在devolop 分支进行开发否则由 develop 分支检出 feature 分支进行开发开发完后合并到develop 分支
具体操作流程 产品根据需求的优先级提前做好规划确定每个迭代需要完成的需求并规划好迭代的版本和评估大致的上线日期基于产品规划的迭代研发即可介入需求实现的设计和研发在研发的过程中Git需遵循如下流程 研发组长基于develop分支创建feature类的分支并将该分支推送到远程分支名: feature-版本号示例: feature-3.7.0 研发同事将feature-3.7.0拉取到本地然后在本地feature-3.7.0开发。 研发完成个人任务并自测通过后即可将【本地】feature-3.7.0的分支推送到【远程】feature-3.7.0 并将feature分支合并到develop分支把develop部署到开发联调环境中进行联调 联调通过后研发人员发起测试申请转入测试阶段。测试人员把feature-3.7.0合并到test分支然后test分支部署到测试环境进行测试 测试过程中发现的bug研发人员仍在feature-3.7.0上修复修复完再通知测试人员每次可多修复一些减少部署测试环境的次数测试人员再通过合并到test分支的方式部署到测试环境如此反复 测试结束后测试人员将test分支合并到uat分支uat分支部署到UAT环境进行产品验收 这个可以按照具体要上uat的内容 按需发布 产品验收通过后研发组长从master分支拉出相同版本号的release分支示例: release-3.7.0然后把UAT分支合并到release-3.7.0由运维同事把release-3.7.0发到正式环境开始线上验证 线上验证通过后研发组长将release-3.7.0合并到master打tag并删除相应的主线feature分支 如果线上验证不通过则运维直接把master分支部署到正式环境来实现回滚相应的release-3.7.0分支删除其它分支不要删除 分支版本号
prd tapt. 蓝湖 版本号 保持一致 Git Commit Message规范
Git commit message规范指提交代码时编写的规范注释编写良好的Commit messages可以达到3个重要的目的 加快代码review的流程 帮助我们编写良好的版本发布日志 让之后的维护者了解代码里出现特定变化和feature被添加的原因
Angular Git Commit Guidelines
业界应用的比较广泛的是Angular Git Commit Guidelines
type(scope): subject
BLANK LINE
body
BLANK LINE
footer type提交类型 scope可选项本次 commit 波及的范围 subject简明扼要的阐述下本次 commit 的主旨在Angular Git Commit Guidelines中强调了三点。使用祈使句首字母不要大写结尾无需添加标点 body: 同样使用祈使句在主体内容中我们需要把本次 commit 详细的描述一下比如此次变更的动机 footer: 描述下与之关联的 issue 或 break change
简易版
项目中实际可以采用简易版规范 type(scope):subject
type规范
Angular Git Commit Guidelines中推荐的type类型如下 feat: 新增功能 fix: 修复bug docs: 仅文档更改 style: 不影响代码含义的更改空白、格式设置、缺失 分号等 refactor: 既不修复bug也不添加特性的代码更改 perf: 改进性能的代码更改 test: 添加缺少的测试或更正现有测试 chore: 对构建过程或辅助工具和库如文档的更改
除此之外还有一些常用的类型 delete删除功能或文件 modify修改功能 build改变构建流程新增依赖库、工具等例如webpack、gulp、npm修改 test测试用例的新增、修改 ci自动化流程配置修改 revert回滚到上一个版本
单次提交注意事项 提交问题必须为同一类别 提交问题不要超过3个 提交的commit发现不符合规范git commit --amend -m 新的提交信息或 git reset --hard HEAD 重新提交一次
配置.gitignore文件
.gitignore是一份用于忽略不必提交的文件的列表项目中可以根据实际需求统一.gitignore文件减少不必要的文件提交和冲突净化代码库环境。
通用文件示例
HELP.md
target/
!.mvn/wrapper/maven-wrapper.jar
!**/src/main/**/target/
!**/src/test/**/target/
## STS ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache
## IntelliJ IDEA ###
.idea
*.iws
*.iml
*.ipr
## NetBeans ###
/nbproject/private/
/nbbuild/
/dist/
/nbdist/
/.nb-gradle/
build/
!**/src/main/**/build/
!**/src/test/**/build/
## VS Code ###
.vscode/
# Log file
*.log
/logs*
# BlueJ files
*.ctxt
# Mobile Tools for Java (J2ME)
.mtj.tmp/
# Package Files #
*.jar
*.war
*.ear
*.zip
*.tar.gz
*.rar
*.cmd
其他
此外还有一些其他建议 master 分支的每一次更新都建议打 tag 添加标签通常为对应版本号便于管理 feature分支、hotfix分支在合并后可以删除避免分支过多管理混乱 每次 pull 代码前提交本地代码到本地库中否则可能回出现合并代码出错导致代码丢失 每次提交说明清楚“小步”前进
如何解决合并冲突 feature或hotix分支合并到develop或test、uat冲突
1、从develop分支checkout一个临时分支tmp_develop_XXX(或tmp_test_XXX)
2、然后把feature合并到tmp_develop_XXX(或tmp_test_XXX)合并过程的代码冲突在tmp__develop_XXX(或tmp_test_XXX)上解决注意不是在feature上也不是在develop或test上
3、解决完冲突后把tmp_develop_XXX(或tmp_test_XXX)合并到develop或test
4、删除tmp_develop_XXX(或tmp_test_XXX)
关于maven仓库的管理 1、目前maven仓库deploy操作暂时在develop/test/uat 分支进行大家不要在其它分支上进行deploy操作相关的操作规范正在完善 2、将来计划计划再弄一个开发专有maven私服以后会有两套maven私服以后的规范是以我们有两套私服为前提 常见问题
1、release分支发布到【正式环境】在【正式环境】验证发现bug时在哪个分支修复 直接在release分支修复。修复完再发【正式环境】再【线上验证】
2、线上验收通过后支线开发分支是否可以删除 如果支线开发分支已经合并到主线开发分支则可以放心删除 如果支线开发分支的代码没有合并的到主线开发分支则说明此次线上验证并没有此分支的代码需要找相应的开发人员问清楚后处理
3、开发人员可以在哪些分支上【提交】代码 feature分支release分支只有release分支在线上验证发现bug时才能在release分支提交代码hotfix分支其它一律禁止直接提交代码
4、开发人员可以向哪些分支【合并】代码 develop分支主线featrue分支
5、任何情况下绝对禁止develop合并到其它任何分支当然有的工程仍没有完成规范改造改造过程 中暂不用考虑此条
