gitflow 进阶规范
git cz
通过工具 git-cz 规范 git commit 提交信息。
使用
$ npm install -g git-cz
git commit 的讲究
通过工具使用可以看出 git 本身及 github 社区对 git 提交单位及提交信息是有非常讲究的要求的，这或许也是我之前给国外 repo 提 PR 被dis的主要原因😅。
优点
可以通过命令快速对 log 进行筛选
$ git log <last release> HEAD --grep feat # 通过 feat 关键在查询功能变更
具体如下：
- 如何界定何时提交一个 commit，如何定义 commit 提交目标
- 详细待我口述
- 如何书写 git message
- message 其实包含三部分: header、body、footer
- header 包含两部分: type、subject
<type>[(<scope>)]: <emoji> <subject> // header 部分
[BLANK LINE] //空行
[body] // 长描述
[BLANK LINE]
[breaking changes] //
[BLANK LINE]
[footer]
其中，只有 header 为强制 message 必选项。
其中 header 限制为 50 个字符，其他每行不超过72个字符，主要为了美观，避免换行
- subject
- 动词开头，第一人称一般现在时祈使句。比如 change 而不是 changes 或 changed
- 首字母小写
- 结尾不加句号（.）
- BREAKING CHANGE (不兼容改动)
当代码改动与上个版本不兼容时，需要对 BREAKING CHANGE 进行描述，通常会记录对改动的描述，改动的原因，以及迁移的方法。 - 关闭 Issue
当前 commit 针对某个 issue 时，可以填写 Issue id
#234
husky （自动化神器，git hook 完美辅助）
知乎上有篇文章大概讲了下这个神器。
主要能力是通过安装 husky npm 包及工程根目录的 package.json 部署 git hook。
hook 管理同 repo 一起，避免尴尬的 git hook 复制粘贴式维护，并且支持 node 脚本。
husky 配置已在单独feat分支配置完毕，有兴趣可以看上面的文章和 github 文档学习。
- 使用
$ npm install husky --save-dev // 注意一定要用 --save-dev 安装到本地，而非 -g 全局
lint-staged
那么问题来了，有了 husky，可以书写一些提交的校验脚本，但是却无法区分校验的内容是新提交的还是旧的已经有的。
不用怕，既然我们能想到，社区一定会有人遇到同样的问题。祭出终极杀手锏，lint-staged。
这个东东一定要配合着 husky 使用才有效果，一样，也是为了提供在提交时进行预处理的能力衍生的工具。
- 使用
$ npm install lint-staged --save-dev // 注意一定要用 --save-dev 安装到本地，而非 -g 全局
问题及bug处理
- 当lint工具误判或提交文件太多导致出错时，可在操作后面加上 --no-verify 绕过lint检查。
参考
- imagemin-lint-staged
- 手牵手使用Husky & Nodejs自定义你的Git钩子
- 利用 ESlint、lint-staged 半自动提升项目代码质量
- 用 husky 和 lint-staged 构建超溜的代码检查工作流
- Clean code linter
- 优雅的提交你的 Git Commit Message
- 【工具推荐】使用 husky 避免糟糕的 git commit
github-flow VS gitlab-flow 【三稿】
主干分支开发
特性分支开发
git flow
我们在 Google 上查关键词“branch model”（也就是“分支模型”），有一篇排名比较靠前的文章“A successful Git branching model”，它介绍了 Git Flow 模型。
Git 刚出来的那些年，可参考的模型不多，所以 Git Flow 模型在 2011 年左右被大家当作了推荐的分支模型，至今也还有项目团队在使用。然而，Git Flow 烦琐的流程也被许多研发团队吐槽，大家普遍认为 hotfix 和 release 分支显得多余，平时都不会去用。
简单解释一下：
master
主干分支，用于保存已经发布的稳定代码。图中按时间线该分支已经从 0.1、0.2 发展到了 1.0版本。
develop
开发主干分支，从 master 分支切出，用于平时的集成开发和集成测试，其中的代码主要用于下一次 relaese 发布，图中的节点表示的是 1.0 的下一个版本。
feature branches
用于将来要发布的某个发布版本准备的 feature 特性分支，从 develop 分支切出。这个分支的含义非常丰富。举例：图中从左往右第一个分支，他的feature特性只是说会在将来某个版本上，但没有确定，一般以做完的时间为主。而第二个feature分支却是下个版本主要的特性分支代码。
release branches
用于做发版的分支，一般承载下个版本的代码发布，当然可以存在多个。在某个节点要发版时从 develop 切出。切出后这个分支只会为之后版本发布做 bug fix 相关的 commit 提交。在发版结束后，会同时向 develop 分支和 master 进行合并。并在 master 打 tag。release 分支即可删除。
hotfix branches
一般用于发布后版本的 bug 修复，例如图中，由于要修复 0.1 的一个bug，从 master 0.1 tag处切出 hotfix分支，修复完成后，将 hotfix 合入 develop 分支和 master 分支，在 master 打tag，并删除 hotfix 分支。
GitHub Flow
GitHub Flow 是 GitHub 所使用的一种简单流程。该流程只使用 master 和特性分支，并借助 GitHub 的 pull request 功能。
在 GitHub Flow 中，master 分支中包含稳定的代码，它已经或即将被部署到生产环境。任何开发人员都不允许把未测试或未审查的代码直接提交到 master 分支。对代码的任何修改，包括 Bug 修复、热修复、新功能开发等都在单独的分支中进行。不管是一行代码的小改动，还是需要几个星期开发的新功能，都采用同样的方式来管理。
当需要修改时，从 master 分支创建一个新的分支，所有相关的代码修改都在新分支中进行。开发人员可以自由地提交代码和提交到远程仓库。
当新分支中的代码全部完成之后，通过 GitHub 提交一个新的 pull request。团队中的其他人员会对代码进行审查，提出相关的修改意见。由持续集成服务器（如 Jenkins）对新分支进行自动化测试。当代码通过自动化测试和代码审查之后，该分支的代码被合并到 master 分支。再从 master 分支部署到生产环境。
GitHub Flow 的好处在于非常简单实用，开发人员需要注意的事项非常少，很容易形成习惯。当需要修改时，只要从 master 分支创建新分支，完成之后通过 pull request 和相关的代码审查，合并回 master 分支就可以了。
Gitlab flow
上面提到的 GitHub Flow，适用于特性分支合入 master 后就能马上部署到线上的这类项目，但并不是所有团队都使用 GitHub 或使用 pull request 功能，而是使用开源平台 GitLab，特别是对于公司级别而言，代码作为资产，不会随意维护在较公开的 GitHub 上（除非采用企业版）。
GitLab Flow 针对不同的发布场景，在 GitHub Flow（特性分支加 master 分支）的基础上做了改良，额外衍生出了三个子类模型，如表 2 所示。
GitLab Flow 的特性分支合入 master 用的是“Merge Request”，功能与 GitHub Flow 的“pull request”相同，这里不再赘述。
通过 Git Flow、GitHub Flow 和 GitLab Flow（3 个衍生类别） 这几个具体模型的介绍，我给你总结一下特性分支开发的优缺点。如表 3 所示。
选出最合适的分支策略
上面我跟你讲到的分支模型，都是 IT 研发领域比较流行的。虽然有些策略带上了代码平台的标识，如 GitHub Flow，但并不意味着该策略仅限于 GitHub 代码平台使用，你完全可以在自己搭建的代码平台上使用这些策略。
接下来，我就总体归纳一下什么情况下应该选择什么样的分支策略。如表 4 所示。
SwiftLint 使用
热烈庆祝 SwiftLint 加入 lint-staged 豪华午餐 🎉 🎉 🎉
（之后对项目 swift 整理治理后，会考虑集成到编译脚本中，每次build都会lint检测）
简单说一下需要注意的问题。
首先 SwiftLint 使用 lint-staged 集成，对开发人员基本无感知，在代码提交时会进行 lint操作，并同时进行检测。
lint 成功
如果你的代码符合 lint 规则。
恭喜，你的提交会正常进入git commit log。
lint 失败
你会看到如下提示
husky > pre-commit (node v8.9.1)
↓ Stashing changes... [skipped]
→ No partially staged files found...
❯ Running linters...
↓ Running tasks for *.{png,jpeg,jpg,gif,svg} [skipped]
→ No staged files match *.{png,jpeg,jpg,gif,svg}
❯ Running tasks for *.swift
✖ Pods/SwiftLint/swiftlint lint
✖ Pods/SwiftLint/swiftlint lint found some errors. Please fix them and try committing again.
⛔️ Line 27: Line should be 120 characters or less: currently 218 characters
⚠️ Line 40: Line should be 120 characters or less: currently 128 characters
⚠️ Line 36: Line should be 120 characters or less: currently 194 characters
...
Linting Swift files at paths /Users/chaoyang/Dev/YCMath_New_iOS/b.swift
Linting 'b.swift' (1/1)
Done linting! Found 9 violations, 2 serious in 1 file.
husky > pre-commit hook failed (add --no-verify to bypass)
如何解读错误？
⛔️ Line 27: Line should be 120 characters or less: currently 218 characters
此处是一处错误(error)，在 b.swift 文件中27行,该行长度超出约定，应该控制在 120 字符以内，现在是 218个，严重超标，请立即进行修改。
⚠️ Line 40: Line should be 120 characters or less: currently 128 characters
此处是一处警告(warning)，在 b.swift 文件中40行开始。该行长度超出约定，应该控制在 120 字符以内，现在是 128个，请注意。
修复
根据命令行提示修复结束后，需要通过 git add 添加你修改好的文件（没有特殊要求 git add .即可）。
add 结束后，通过 git commit 进行提交即可通过。
更多教程可点击SwiftLint 中文说明的规则部分查看。
feat 分支开发及合并流程【初稿】
note
下文可能会涉及到 git rebase 的使用，在不熟悉的情况下请遵守以下黄金法则。
1. develop、master、hotfix等多人共用分支请勿直接提交任何 commit，只用于日常的代码拉取和合并。
2. 如果某次操作间隔中发生1的情况，请勿使用 rebase 合并线上代码到本地。
3. rebase 仅限于 1、2、条件满足时的远程代码同步，例如：git rebase origin/develop(分支名)
- 抓取线上代码到本地镜像
这里需要注意，在代码合并前推荐对远程仓库镜像进行抓取，方便后续在合并时根据情况自由的选择合并的方式，选择不同的方式合并，产生的 git log 和分支合并痕迹也是不同的。
$ git fetch origin develop # 抓取主机名为 origin 下的远程仓库的 develop
# 其中 origin 和 develop 为可选参数，用于更精确的数据抓取, zsh 可配置缩写为 gfod
- 合并镜像分支到本地
a. 这里本地分支主要指纯洁的没有本地提交过的公共分支(master、develop、hotfix等)，及其他私有分支(feat/xxx，fix/xxx)。
# 公共分支更新
$ git checkout develop # zsh 缩写为 gco develop
$ git rebase origin/develop # rebase 合并镜像分支 origin/develop 到本地 develop , zsh 为 grb origin/develop
# 私有分支更新
$ git checkout feat/xxxx
$ git rebase origin/develop
b. 如果 a 中公共分支不纯洁，则采用 git merge 进行分支合并
$ git checkout develop
$ git merge origin/develop # 使用 merge 合并
- feat、fix 分支创建及开发
# 基于当前的分支创建私有分支
$ git checkout develop
$ git checkout -b feat/xxxx
开发
这里需要注意规范 commit message 的信息，可使用 git cz 进行控制，后续会讲到用法
$ git add .
$ git cz # 根据提示输入选项
- 私有分支合并主干分支
a. 使用 gitlab 进行 merge request 申请，并勾选 squash commit。
git 提交的一些陋习及解决方案
to be continue...
