git规范

1.概览

  • 项目默认分支为 线上master预发布 develop

  • commit信息必须完整描述修改内容

  • commit之前必须进行pull或者fetch进行同步

  • 所有需求建立新分支进行修改

  • develop 分支作为开发阶段主分支 各需求负责人本地建立新分支进行修改 修改完成后使用rebase合并冗余commit信息合并至develop分支

2.commit规范

  • 保证commit尽量只做一件事
  • 书写commit message言简意赅
  • 规范commit message格式
  1. 完整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 或者需求链接

  1. 开发过程中遇到单行无法完整描述commit信息时必须使用完整commit信息提交

  2. 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进行更新