Git/Github工作流 (workflow)

1. contribute开源软件工作流

这个工作流适合开发维护开源软件，它依赖于github的Fork功能。

1. 将 GitHub 开源Repo Fork 到 你的远程Repo
2. 将❶的仓库 clone 至本地开发环境
3. 在本地环境中创建特性分支
4. 对特性分支进行代码修改并进行提交
5. 将特性分支 push 到❶的仓库中
6. 在 GitHub 上对 Fork 来源仓库发送 Pull Request

2. 以部署为中心的工作流

总体流程非常简单，如下图：

在实际开发中往往 1 天之内会实施几十次部署，而支撑这一切的，就是足够简单的开发流程以及完全的自动化。简单的开发流程能够让问题应对变得更加灵活。以笔者的经验，由 20 人左右的团队使用这个流程来共同开发一个项目，基本不会出现什么大问题。

整个开发流程大致如下：

1. 令 master 分支时常保持可以部署的状态
2. 进行新的作业时要从 master 分支创建新分支，新分支名称要具有
   描述性
3. 在❷新建的本地仓库分支中进行提交
4. 在 GitHub 端仓库创建同名分支，定期 push
5. 需要帮助或反馈时创建 Pull Request，以 Pull Request 进行交流
6. 让其他开发者进行审查，确认作业完成后与 master 分支合并
7. 与 master 分支合并后立刻部署

注意：

• Stage1
  
  • 随时部署，没有发布的概念。
  • 没有进行过测试或者测试未通过的代码绝不可以合并到 master 分支。
• Stage2
  
  • 所谓具有描述性的名称，是指该名称能直观正确地表达这个分支的特性，比如：login-module
• Satge3
  
  • 修改代码时要注意，绝对不能进行与该分支工作内容无关的修改。
  • 在这一阶段，开发者要在提交的粒度上多花心思。有意识地减小提交的规模，一方面便于清楚地表达目的，另一方面有助于其他开发者对Pull Request 进行审查。
• Stage5
  
  • Pull Request 不一定非要在与 master 分支合并时才使用。既然是团队开发，完全可以尽早创建 Pull Request 让其他开发者进行审查，一边听取反馈一边编写代码，没必要等到与 master 分支合并时再进行。

3. 以发布为中心的工作流

在这个开发流程中，每个分支都显示出代码的当前状态。流程中设置了负责管理软件发布 Release 的发布管理员，适用于以发布为中心的软件开发。

开发流程：

1. 从开发版的分支（develop）创建工作分支（feature branches），进行功能的实现或修正
2. 工作分支（feature branches）的修改结束后，与开发版的分支（develop）进行合并
3. 重复上述❶和❷，不断实现功能直至可以发布
4. 创建用于发布的分支（release branches），处理发布的各项工作
5. 发布工作完成后与 master 分支合并，打上版本标签（Tag）进行发布
6. 如果发布的软件出现 BUG，以打了标签的版本为基础进行修正（hotfixes）

流程图示：

解释：

1. master 分支时常保持着软件可以正常运行的状态。由于要维持这一状态，所以不允许开发者直接对 master 分支的代码进行修改和提交。其他分支的开发工作进展到可以发布的程度后，将会与 master 分支进行合并，而且这一合并只在发布成品时进行。发布时会附加包含版本编号的 Git 标签（Tag）。
2. develop 分支是开发过程中的代码中心分支。与 master 分支一样，这个分支也不允许开发者直接进行修改和提交。程序员要以 develop 分支为起点新建 feature 分支，在 feature 分支中进行新功能的开发或者代码的修正。
3. release 分支在自己的branch内只允许进行bug修复commit。
4. hotfix 分支并不是预期中计划出现的分支。它是一个紧急应对措施，只有当前发布的版本中出现 BUG 或漏洞，而且其严重程度要求开发方必须立刻处理，无法等到下一个版本发布时， hotfix 分支才会被创建。因此， hotfix 分支都是以发布版本的标签或 master 分支为起点。借助 hotfix 分支，可以在不影响 develop 分支正常开发的情况下，由其他开发者处理成品的修正工作。

Ref:

《Github入门与实践》