修改代码后保存本地
push 前先 pull 线上代码
Git commit
fix: feat(0429留言下单): add 'graphiteWidth' option
提交的具体情况
| type（必需） | scope（可选） | subject（必需） | (可选) |
|---|---|---|---|
| 说明 commit 的类别 | 说明 commit 影响的范围 | commit 的简短描述 | 对本次 commit 的详细描述 |
type用于说明 commit 的类别:
br: 此项特别针对 bug 号，用于向测试反馈 bug 列表的 bug 修改情况
**feat：**新功能（feature）
**fix：**修补 bug
**docs：**文档（documentation）
style： 格式（不影响代码运行的变动）
**refactor：**重构（即不是新增功能，也不是修改 bug 的代码变动）
**test：**增加测试
**chore：**构建过程或辅助工具的变动
revert: feat(pencil): add ‘graphiteWidth’ option (撤销之前的 commit)
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
subject是 commit 的简短描述，不超过 50 个字符。以动词开头，使用第一人称现在时，比如 change，而不是 changed 或 changes。第一个字母小写。结尾不加句号（.）
Body 部分是对本次 commit 的详细描述，可以分成多行。
实例：
fix: 修改了某某某内容
feat: 新增了某某某内容
chore: 更新了某某某版本
Master
master 和 develop 分支都是主分支，主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。
master 分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。当开发活动告一段落，产生了一份新的可供部署的代码时，master 分支上的代码会被更新。同时，每一次更新，都有对应的版本号标签（TAG）。
Develop
develop 分支是保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码（Nightly build）。因此这个分支有时也可以被称作“integration branch”。
当 develop 分支上的代码已实现了软件需求说明书中所有的功能，通过了所有的测试后，并且代码已经足够稳定时，就可以将所有的开发成果合并回 master 分支了。对于 master 分支上的新提交的代码建议都打上一个新的版本号标签(TAG),供后续代码跟踪使用
Release
从 develop 分支派生
必须合并回 develop 分支和 master 分支
release 分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。通过在 release 分支上进行这些工作可以让 develop 分支空闲出来以接受新的 feature 分支上的代码提交，进入新的软件开发迭代周期。
当 develop 分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建 release 分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到 release 分支之内（避免由此引入一些不可控的系统缺陷）。
成功的派生了 release 分支，并被赋予版本号之后，develop 分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。
Hotfix
从 master 分支派生
必须合并回 master 分支和 develop 分支
除了是计划外创建的以外，hotfix 分支与 release 分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从 master 分支上指定的 TAG 版本派生 hotfix 分支来组织代码的紧急修复工作。
Feature
从 develop 分支发起 feature 分支
代码必须合并回 develop 分支
feature 分支（有时也可以被叫做“topic 分支”）通常是在开发一项新的软件功能的时候使用，这个分支上的代码变更最终合并回 develop 分支或者干脆被抛弃掉（例如实验性且效果不好的代码变更）。
一般而言，feature 分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。
历史分支
Gitflow 工作流使用 2 个分支来记录项目的历史。master 分支存储了正式发布的历史，而 develop 分支作为功能的集成分支。
功能分支(Feature)
feature 不是从 master 分支上拉出新分支，而是使用 develop 分支作为父分支。当新功能完成时，合并回 develop 分支。新功能提交应该从不直接与 master 分支交互。
发布分支(Release)
develop 分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从 develop 分支上 fork 一个发布分支。新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上
这个分支只应该做 Bug 修复、文档生成和其它面向发布任务。一旦对外发布的工作都完成了，发布分支合并到 master 分支并分配一个版本号打好 Tag。另外，这些从新建发布分支以来的做的修改要合并回 develop 分支。
使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。
维护分支(Hotfix)
维护分支或说是热修复（hotfix）分支用于生成快速给产品发布版本（production releases）打补丁，这是唯一可以直接从 master 分支 fork 出来的分支。修复完成，修改应该马上合并回 master 分支和 develop 分支（当前的发布分支），master 分支应该用新的版本号打好 Tag。
为 Bug 修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。你可以把维护分支想成是一个直接在 master 分支上处理的临时发布。
参考：https://www.jianshu.com/p/3c5e6d41cc16