简介
一个大型项目都是由很多人一起开发完成的，所以合理的开发模式是很重要的，不然会带来很多的问题，如代码冲突，合错代码等。
在git开发中一般分为4中工作流，也叫开发模式，如：集中式工作流，功能分支流，Git Flow工作流，Forking工作流。
集中式工作流
图为三个人都有一份本地的远程拷贝，分别开发完后提交commit到远程仓库，如果有冲突先解决冲突。这种模式是最简单的开发模式，它的缺点是不同的人提交的日志混杂一起，难以定位问题，而且容易产生冲突。适合团队少，开发不频繁，不需要同时维护多个版本的小项目。
功能分支工作流
功能分支工作流基于集中式工作流演进而来。在开发新功能时，基于 master 分支新建一个功能分支，在功能分支上进行开发，而不是直接在本地的 master 分支开发，开发完成之后合并到 master 分支，如下图所示：
相较于集中式工作流，这种工作流让不同功能在不同的分支进行开发，只在最后一步合并到 master 分支，不仅可以避免不同功能之间的相互影响，还可以使提交历史看起来更加简洁。
具体流程：
1. 如果新增一个功能，功能分支可以取一些有意义的名字，便于理解，例如 feature/rate-limiting。
git checkout -b feature/rate-limiting
2.在分支开发完成后，提交到功能分支。
git commit -a -m "add reate limiting"
3.push 到远程仓库
git push origin feature/rate-limiting
4.GitHub上会看到Compate&pull request，点击会进入pull request页面，填写评论。点击Create pull request提交、
5.管理员收到PR后，会点击Merge pull request合并到master
Merge pull request: 提供了3种merge方法：
1.Create a merge commit：GitHub 的底层操作是 git merge --no-ff。feature 分支上所有的 commit 都会加到 master 分支上，并且会生成一个 merge commit。这种方式可以让我们清晰地知道是谁做了提交，做了哪些提交，回溯历史的时候也会更加方便。
2. Squash and merge：GitHub 的底层操作是 git merge --squash。Squash and merge 会使该 pull request 上的所有 commit 都合并成一个 commit ，然后加到 master 分支上，但原来的 commit 历史会丢失。
3. Rebase and merge：GitHub 的底层操作是 git rebase。这种方式会将 pull request 上的所有提交历史按照原有顺序依次添加到 master 分支的头部（HEAD）
这种模式简单，能并行开发多个功能，还可以code review。缺点：无法分配明确的目的，不利于团队配合。
Git Flow 工作流
Git Flow 工作流是一个非常成熟的方案，也是非开源项目中最常用到的工作流。它定义了一个围绕项目发布的严格分支模型，通过为代码开发、发布和维护分配独立的分支来让项目的迭代流程更加顺畅，比较适合大型的项目或者迭代速度快的项目。
Git Flow 的 5 种分支：master、develop、feature、release 和 hotfix.
Git Flow开发流程
a. 当前版本为0.9.0
b.需要开发一个功能，使程序输出hello go 字符串
c. 在开发阶段，线上紧急有Bug需要修复、
假设我们项目下有个文件名字为main.go
1.首先创建分支：develop、 git checkout -b develop master (基于master分支创建develop分支)
2. 基于develop分支创建功能分支：feature/print-hello-go git checkout -b feature/print-hello-go
3. feature/print-hello-go 分支中，在 main.go 文件中添加一行代码fmt.Println("Hello")
4. 紧急修复 Bug。当我们正在开发中要修改bug，步骤如下：
$ git stash # 1. 开发工作只完成了一半，还不想提交，可以临时保存修改至堆栈区
$ git checkout -b hotfix/print-error master # 2. 从 master 建立 hotfix 分支
$ vi main.go # 3. 修复 bug
$ git commit -a -m 'fix print message error bug' # 4. 提交修复
$ git checkout develop # 5. 切换到 develop 分支
$ git merge --no-ff hotfix/print-error # 6. 把 hotfix 分支合并到 develop 分支
$ git checkout master # 7. 切换到 master 分支
$ git merge --no-ff hotfix/print-error # 8. 把 hotfix 分支合并到 master
$ git tag -a v0.9.1 -m "fix log bug" # 9. master 分支打 tag
$ git branch -d hotfix/print-error # 11. 修复好后，删除 hotfix/xxx 分支
$ git checkout feature/print-hello-go # 12. 切换到开发分支下
$ git merge --no-ff develop # 13. 因为 develop 有更新，这里最好同步更新下
$ git stash pop # 14. 恢复到修复前的工作状态
5. 继续开发
6. 提交代码到feature/print-hello-go分支 git push origin feature/print-hello-go
7. 我们在 GitHub 上，基于 feature/print-hello-go 创建 pull request, 进行 code review，代码仓库 matainer 将功能分支合并到 develop 分支。
8. 基于 develop 分支，创建 release 分支，测试代码。git checkout -b release/1.0.0 develop
9. 测试通过后，将功能分支合并到 master 分支和 develop 分支
Git Flow 工作流比较适合开发团队相对固定，规模较大的项目
Forking 工作流
而在开源项目中，最常用到的是 Forking 工作流，例如 Kubernetes、Docker 等项目用的就是这种工作流。这里，我们先来了解下 fork 操作。
fork 操作是在个人远程仓库新建一份目标远程仓库的副本，比如在 GitHub 上操作时，在项目的主页点击 fork 按钮（页面右上角），即可拷贝该目标远程仓库。Forking 工作流的流程如下图所示。
1.首先fork代码到本地 并创建远程提交的分支 如下的upstream就是创建远程分支 并且这个分支是在你fork的项目进行pull 和 push的
git remote add upstream https://github.com/****
git remote set-url --push upstream no_push
2. 创建功能分支，并同步本地仓库为最新状态
$ git fetch upstream
$ git checkout master
$ git rebase upstream/master
3. 提交commit,并push
Forking 工作流比较适用于以下三种场景：（1）开源项目中；（2）开发者有衍生出自己的衍生版的需求；（3）开发者不固定，可能是任意一个能访问到项目的开发者。
