一、制定目的
统一团队Git commit日志标准，便于后续代码review，版本发布以及日志自动化生成等等。
统一团队的Git工作流，包括分支使用、tag规范、issue等
二、Git工作流
分支规范
分支类型 | 命名规范 | 创建自 | 合并到 | 说明 |
master | master | -- | -- | 长期分支，部署到生产环境中的代码 |
develop | develop | -- | master | 长期分支，进行代码集成的分支 |
feature | feature/* | develop | develop | 短期分支，新功能分支 |
release | release/* | develop | develop和master | 短期分支，一次新版本的发布 |
hotfix | hotfix/* | master | develop 和 master | 短期分支，生产环境中发现的紧急 bug 的修复，唯一可以直接从master分支fork出来的分支 |
三个短期分支类型一旦完成开发，它们就会被合并进develop或master，然后被删除。
分支的名称应该遵循一定的命名规范，以方便开发人员识别。
工作方式
当需要开发一个新的功能时，基本的流程如下：
从 develop 分支创建一个新的 feature 分支，如 feature/my-xxx。
在该 feature 分支上进行开发，提交代码。
当代码完成之后，合并到 develop 分支，push 到远端仓库，并删除当前 feature 分支。
开发新功能Git 命令流程：
git checkout -b feature/my-xxx develop
git add xxx；git commit 新功能完成并提交commit
git pull origin develop
git checkout develop
git merge feature/my-xxx 若存在冲突，则解决冲突后commit
git push origin develop
git branch -d feature/my-xxx
三、Commit规范
概述
一个commit 应该包括一个准确的逻辑改动。一个逻辑改动包括增加新的特性或修改特定的Bug，如果不能在较高层次用简短语句描述这个改动，就说明它对于单个commit 来说太复杂了，应该拆分它！把你的代码改动拆分为多个 commit。
以下习惯，有则改之，无则加冕：
总是在每天下班前commit今天所有的改动，这种commit不会清晰。
懒汉式的commit信息，如“修改了几个Bug”，这种信息毫无意义。
两个改动放在一次 commit 中。如“修改用户注册不成功的处理和用户登录的验证”，请把它拆开分别 commit。
有些动词用现在时，而不是完成时，例如不要说“改好了(fixed)…，解决了(solved)…, 增加了(added)…，修改了(revised)…”，而应该说“增加(add)…，修改(revise)…，解决(solve)…”
在git commit 上增加 -m <msg> 或 --message=<msg> 参数进行提交，提倡使用git commit或可视化的提交
Git commit日志基本格式
<type>(<scope>): <subject>
<BLANK LINE>
<body>
格式说明
type代表某次提交的类型，比如是修复一个bug还是增加一个新的feature。所有的type类型如下：
feat： 新增feature
fix: 修复bug
docs: 仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等
style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
refactor: 代码重构，没有加新功能或者修复bug
perf: 优化相关，比如提升性能、体验
test: 测试用例，包括单元测试、集成测试等
chore: 改变构建流程、或者增加依赖库、工具等
revert: 回滚到上一个版本
格式要求
# 标题行：50个字符以内，描述主要变更内容
# 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
# * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险?
# * 修复BUG时，关联BUG编号
示例：
# feat:新增登录注册功能
# 新增系统登录登录功能，可使用邮箱、密码进行用户注册，邮箱发送验证码，验证通过后，即可登录
留言评论
暂无留言