团队开发中，遵循一个合理、清晰的 Git 规范，是非常重要的。
否则，每个人都提交一堆杂乱无章的 commit 和 分支，项目很快就会变得难以协调和维护。
流程规范
- 拉取最新代码。开始开发前，首先确保自己的代码为最新。
- 新建分支。每次开发新功能，都应该新建一个单独的分支。
- 提交分支 commit，撰写提交信息。
- 与主分支同步。
- 合并 commit。分支开发完，可能有一堆的 commit，但是合并到主干的时候，往往希望只有一个（或最多两三个）commit，这样不仅清晰，也容易管理。
- 推送到远程仓库。
- 请求别人进行 code review，确认无误可以合并到 master。
分支规范
-
master 分支（主分支） 稳定版本
-
develop 分支（开发分支） 最新版本
-
release 分支（发布分支） 发布新版本
-
fixbug 分支（热修复分支） 修复线上 Bug
-
feature 分支（特性分支） 实现新特性
功能分支
它是为了开发某种特定功能，从 Develop 分支上面分出来的。
开发完成后，要再并入 Develop。
功能分支的名字，可以采用 feature-*的形式命名。
预发布分支
它是指发布正式版本之前（即合并到 Master 分支之前），我们可能需要有一个预发布的版本进行测试。
预发布分支是从 Develop 分支上面分出来的，预发布结束以后，必须合并进 Develop 和 Master 分支。
它的命名，可以采用 release-* 的形式。
修补 bug 分支
软件正式发布以后，难免会出现 bug。这时就需要创建一个分支，进行 bug 修补。
修补 bug 分支是从 Master 分支上面分出来的。
修补结束以后，再合并进 Master 和 Develop 分支。
它的命名，可以采用 fixbug-* 的形式。
Commit message 规范
格式化的 Commit message，有几个好处。
- 提供更多的历史信息，方便快速浏览。
- 可以过滤某些 commit（比如文档改动），便于快速查找信息。
- 可以直接从 commit 生成 Change log。
格式
每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
Header
Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和 subject（必需）。
type 用于说明 commit 的类别。
- feature：新功能（feature）
- fixbug：修补 bug
- docs：文档（documentation）
- refactor：重构（即不是新增功能，也不是修改 bug 的代码变动）
- test：增加测试
scope 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
subject 是 commit 目的的简短描述，不超过 50 个字符。
- 以动词开头，使用第一人称现在时，比如 change，而不是 changed 或 changes
- 第一个字母小写
- 结尾不加句号（.）
Body
本次 commit 的详细描述，可以分成多行。
Footer
Footer 部分只用于两种情况。
不兼容变动：如果当前代码与上一个版本不兼容，则 Footer 部分以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动理由和迁移方法。
关闭 Issue：如果当前 commit 针对某个 issue，那么可以在 Footer 部分关闭这个 issue 。也可以一次关闭多个 issue 。
Closes #123, #245, #992
2745
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
