专门做ppt会员网站,怎么让别人访问自己做的网站,优秀网页案例,农产品网站建设主要工作分支命名 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
test分支 test为测试环境分支外部用户无法访问专门给测试人员使用版本相对稳定。
release分支 release 为预上线分支预发布分支UAT测试阶段使用。一般由 test 或 hotfix 分支合并不建议直接在 release 分支上直接修改代码。
hotfix 分支 线上出现紧急问题时需要及时修复以master分支为基线创建hotfix分支。修复完成后需要合并到 master 分支和 develop 分支。
分支命名以hotfix/ 开头的为修复分支它的命名规则与 feature 分支类似。
分支与环境对应关系 在系统开发过程中常用的环境
DEV 环境Development environment用于开发者调试使用 FAT环境Feature Acceptance Test environment功能验收测试环境用于测试环境下的软件测试者测试使用 UAT环境 User Acceptance Test environment用户验收测试环境用于生产环境下的软件测试者测试使用 PRO 环境Production environment生产环境 对应关系 分支合并流程规范 业界常见的两大主分支master、develop、三个辅助分支feature、release、hotfix的生命周期
例如我们团队在开发时至少需要保证以下流程
develop 分支和 hotfix 分支必须从 master 分支检出 由 develop 分支合并到 test 分支 功能测试无误后由 test 分支合并到 release 分支 UAT测试通过后由 release 分支合并到 master分支 对于工作量小的功能开发工时小于1天可以直接在devolop 分支进行开发否则由 develop 分支检出 feature 分支进行开发开发完后合并到develop 分支
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 代码前提交本地代码到本地库中否则可能回出现合并代码出错导致代码丢失
