04.Git工作流指南

学好Git工作流很有必要，让你在代码管理上胜人一筹。通过几种工作流的介绍，让你找到适合于你的工作流

集中式工作流

此工作流类似与SVN，用过SVN的可快速上手

示例

• 中央仓库初始化
• 张三、李四克隆仓库
• 张三开发好功能提交到master并推送到中央仓库
• 紧接着李四开发好功能提交到master并推送到中央仓库时报错了，原因是因为中央仓库的版本与李四本地的版本有冲突，需要拉取中央仓库合并之后才可推送到中央仓库
  注： 习惯推送代码前先拉取代码
  适用： 小型团队1-5个人左右

功能分支工作流

该工作流基于集中式工作流，不直接对master主分支进行代码操作，通过创建功能分支来进行版本控制

示例

• 张三要开发登录功能，我们可针对功能进行分支创建。首选创建分支feature_login，然后切换到该分支，此时中央仓库并无feature_login分支，所以最后一步是要推送分支（ps： 此时无代码提交，只需推送分支即可）
• 紧接着张三在feature_login上按集中式工作流开发完功能后，他想把代码提交到master上，这时张三需要发起一个pull request请求，请求有合并权限的人（开发经理）来进行合并操作（ps： 这样有合并权限的人就知道张三干了什么，代码写了什么，可以进行代码评审）
• 如果代码评审没过，可重新修改再提交推送代码
• 通过时，有合并权限的人可Merge pull request，把分支合并到master上，此时master上就有张三开发的登入功能了
• Merge后张三会收到消息，此时张三需要切换到master主流进行代码拉取操作，查看确认是否成功合并。
• 最后，张三删除多余的feature_login分支，包括本地以及远程
  好处： master主干代码不会被污染
  适用： 小型团队8-12个人左右

GitFlow 工作流

此工作流适用于企业开发，比功能分支流会复制点，是一个围绕项目发布的严格分支模型。

分支结构

• mater 主干分支
• develop 代码开发分支，基于master创建
• feature 功能代码分支，基于develop创建，最终合并到develop分支
• release 预发布分支，基于develop创建，最终合并到master分支
• hotfix 本版补丁分支，基于master创建，最终合并到master分支

示例

1. 基于master创建develop分支，切换并推送。（ps： 必须在develop上开发，避免污染master主干分支）
2. 基于develop做功能分支工作流开发。功能开发完成后pull request时，需确保一定要合并到develop上
3. 等版本功能完成好了，可以发布预发布版让测试人员测试。此时基于develop创建release-1.0.0分支
4. 测试无问题跳过此步骤，有问题则删除release-1.0.0分支，继续2步骤（此时预发布分支要命名为release-1.0.1）。
5. 若测试无问题，把release-1.0.x分支pull request到master
6. 切换到mater，本地拉取最新代码，基于最新代码创建tgs命名为1.0.x-release并推送（包括标签）到中央仓库
7. 最后删除本地和远程仓库的feature和release分支
8. 如果正式版本有bug的话就提issues，然后切换到tgs标签时会自动创建分支，我们命名为hotfix_0000014（命名规则是根据issues后面的标记#14来的），修复后直接pull request到master，再做7、8两步操作。注意： 此时要删除hotfix_0000014分支

Forking工作流

适用大型开源项目，做代码贡献用，一般步骤：

• fork别人的项目代码到自己的中央仓库
• 拉取到自己本地开发，开发完之后提交推送到中央仓库
• 作者发起pull request请求

总结

我们要熟练掌握的是GitFlow 工作流，因为其遵从了严格的版本发布流程。但通常我们会对其做一些简化，不做feature分支，直接在develop使用集中式工作流。好了，上面只是笔述了一些可能用法的例子，并不是只有这几种工作流，大家可以根据自己的实际情况出发，做出相应调整，让Git为你所用