Git 作为一个源码管理系统，不可避免涉及到多人协作。
协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。"工作流程"在英语里，叫做 "workflow" 或者 "flow"，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。
有许多广泛使用的工作流，这里我们使用 Gitlab flow，因为最适合我们。
一、功能驱动
本文的工作流程：采用"功能驱动式开发"（Feature-driven development，简称FDD）。
它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
二、Gitlab flow
是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。
2.1 上游优先
Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。
1. Linus Torvalds的分支
2. 子系统（比如netdev）的分支
3. 设备厂商（比如三星）的分支2.2 持续发布
Gitlab flow 分成两种情况，适应不同的开发流程。
对于"持续发布"的项目，它建议在 master 分支以外，再建立不同的环境分支。比如，"开发环境"的分支是 master，"预发环境"的分支是 pre-production，"生产环境"的分支是 production。
开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。比如，生产环境出现了 bug，这时就要新建一个功能分支，先把它合并到 master，确认没有问题，再 cherry-pick 到 pre-production，这一步也没有问题，才进入 production。
只有紧急情况，才允许跳过上游，直接合并到下游分支。
2.3 版本发布
对于"版本发布"的项目，建议的做法是每一个稳定版本，都要从 master 分支拉出一个分支，比如 2-3-stable、2-4-stable 等等。
以后，只有修补 bug，才允许将代码合并到这些分支，并且此时要更新小版本号。
三、一些小技巧
3.1 Pull Request
功能分支合并进 master 分支，必须通过 Pull Request（Gitlab里面叫做 Merge Request）。
前面说过，Pull Request 本质是一种对话机制，你可以在提交的时候，@ 相关人员或团队，引起他们的注意。
3.2 Protected branch
master 分支应该受到保护，不是每个人都可以修改这个分支，以及拥有审批 Pull Request 的权力。
3.3 Issue
Issue 用于 Bug 追踪和需求管理。建议先新建 Issue，再新建对应的功能分支。功能分支总是为了解决一个或多个 Issue。
功能分支的名称，可以与 issue 的名字保持一致，并且以 issue 的编号起首，比如 "15-require-a-password-to-change-it"。
开发完成后，在提交说明里面，可以写上 "fixes #14" 或者 "closes #67" 。Github 规定，只要 commit message 里面有下面这些动词 + 编号，就会关闭对应的 issue。
close
closes
closed
fix
fixes
fixed
resolve
resolves
resolved这种方式还可以一次关闭多个 issue ，或者关闭其他代码库的 issue，格式是username/repository#issue_number。Pull Request 被接受以后，issue 关闭，原始分支就应该删除。如果以后该 issue 重新打开，新分支可以复用原来的名字。
3.4 Merge 节点
Git有两种合并：一种是"直进式合并"（fast forward），不生成单独的合并节点；另一种是"非直进式合并"（none fast-forword），会生成单独节点。
前者不利于保持commit信息的清晰，也不利于以后的回滚，建议总是采用后者（即使用 --no-ff 参数）。只要发生合并，就要有一个单独的合并节点。
3.5 Squash 多个commit
为了便于他人阅读你的提交，也便于 cherry-pick 或撤销代码变化，在发起 Pull Request 之前，应该把多个 commit 合并成一个。（前提是，该分支只有你一个人开发，且没有跟 master 合并过。）
这可以采用 rebase 命令附带的 squash 操作，具体方法请参考我写的。
开发规范
一 开始项目
// 开发中的分支 最上游的分支
master
// 基于 master 分支 创建 预发布分支
git checkout -b pre-production master
// 基于 预发布 分支 创建 产品分支
git checkout -b production pre-production
应该忽略的
缓存
环境配置信息
上传的文件
支付证书等
二 功能开发
要开发一个新功能流程：
// 基于 master 分支 新建一个功能分支
git checkout -b new-feature master
// 开发完后，合并回 master 分支
git checkout master
git merge new-feature --no-ff
三 线上 Bug 修复
从 production 分支切换一个新分支
修复完合并回 production
必须合并到 master
git checkout -b hotfix production
git checkout production
git merge hotfix
git checkout master
git merge productionGit commit 规范
一个 commit 提交的内容要尽量是一个功能的（意思是，在写这这个功能，在以前写的功能中突然有一个想法，然后把那也改下，这就导致了这次的提交不单一了，就更其它的功能搅在一块，这样以后的回退会非常的麻烦），并且注释要清晰，方便以后的回退。
