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