抓取结果
Git规范-初版 | Pota Blog Wrpota Categories Tags Search Archives About 主页 » Posts Git规范-初版 Git规范-初版 七月 2, 2021 · 1 分钟 · wrpota 目录 git规范 1.概览 2.commit规范 3. 分支规范 4. 操作规范 git规范 # 1.概览 # 项目默认分支为 线上 master 预发布 develop commit信息 必须 完整描述修改内容 commit之前 必须 进行pull或者fetch进行同步 所有需求建立新分支进行修改 develop 分支作为开发阶段主分支 各需求负责人本地建立新分支进行修改 修改完成后使用rebase合并冗余commit信息合并至develop分支 2.commit规范 # 保证commit尽量只做一件事 书写commit message言简意赅 规范commit message格式 完整commit信息大致如下 参考 Angular Git Commit Guidelines ： # 标题行：50个字符以内，描述主要变更内容 # # 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括: # # * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等 # * 他如何解决这个问题? 具体描述解决问题的步骤 # * 是否存在副作用、风险? # # 如果需要的化可以添加一个链接到issue地址或者其它文档 复制 <type>: <subject> <BLANK LINE> <body> <BLANK LINE> <footer> type: 本次 commit 的类型，诸如 bugfix docs style 等 scope: 本次 commit 波及的范围 subject: 简明扼要的阐述下本次 commit 的主旨，结尾无需标点 body: 主体内容 footer: 描述下与之关联的 bug 或者需求链接 复制 开发过程中遇到单行无法完整描述commit信息时 必须 使用完整commit信息提交 commit信息开头 必须 指明此次提交类型 包括但是不限于以下几种： feat: 添加新特性 update: 因需求 添加了新的逻辑 作为feat的备选方案，仅在去除一些逻辑时使用 fix: 修复bug docs: 仅修改了文档 style: 仅代码格式调整 refactor: 代码重构，没有加新功能或者修复bug delete: 文档或代码的删除，没有功能修改或者修复bug 复制 3. 分支规范 # 一个稳定 master 分支 一个待发布的 develop 分支 若干个正在开发的 feature 分支 依据需求进行建立 由各实际负责人进行建立，需求关闭后 删除 如遇到线上有十分严重bug，应在master上切换出hotFix分支进行bug修复，并验证好了后随即合并到master上准备发布 如遇到线上有一般的bug，可在develop上切换出hotFix分支进行bug修复，完成后合并到develop上，等下次版本一起发布 分支合并前若有必要先 rebase 待合并的分支 合并到 develop 中 必须 去除调试commit信息 确保主分支commit信息的纯净 如非必须情况 禁止 将 feature 分支push 至origin中 允许情况如下： 除实际负责人之外需其余团队成员配合 本地环境无法满足测试情况 4. 操作规范 # 禁止 使用 git push --force 进行提交 禁止 在 develop master 分支使用 rebase 操作， rebase 仅可在无合作者的 feature 中进行 分支合并出现冲突 必须 解决后才能提交， 禁止 直接撤销修改后push 合作分支 commit 之前需先 fetch 或 pull 进行更新 Git « 上一页 使用doker搭建DNS服务 下一页 » Git教程-初版 © 2025 Pota Blog Powered by Hugo & PaperMod
网站标题
Git规范-初版 | Pota Blog
关键词
git
站点描述
Git规范-初版