Git 基于分支的工作流程
详细内容看：https://github.com/xirong/my-…
集中式工作流
集中式工作流是集中式版本控制工具中常用的开发流程，以主分支 (mater) 为核心，所有开发人员通过更新主分支代码完成代码的开发工作。
工作流程是这样的：
现在团队里面有两个人，子旺和金康，他们两个人分别克隆了远程的仓库 gitdemo
现在子旺进行了一次提交，远程仓库就多了一个版本的提交 git push orgin master
现在金康想要提交到远程仓库，发现没办法提交 push，需要先 git pull –rebase origin master 拉取的时候，同时进行变基操作，保证代码版本历史的漂亮（当然这种漂亮有时候也需要付出一些代价）
总的来说，集中式的工作流，就需要不断拉取远程仓库和本地的进行同步，即 push 前需要先 pull。（不断的 pull 是非常友好的，也是公司开发需要的）
功能开发工作流
功能分支工作流以集中式工作流为基础，不同的是为各个新功能分配一个专门的分支来开发。这样可以在把新功能集成到正式项目前，用 Pull Requests 的方式讨论变更。pull requests 工作流能为每个分支发起一个讨论，在分支合入正式项目之前，给其它开发者有表示赞同的机会。
工作流程是这样的：
团队里面的子旺在 master 分支上开了一个功能分支 feature-xxx，现在子旺饿了，要去吃点东西，在去之前要把编写的代码提交 push git push -u origin feature-xxx（- u 选项设置本地分支去跟踪远程对应的分支）到远程的 feature-xxx 分支上面。
现在子旺完成了功能开发，并且 push 到他的远程分支 feature-xxx，他发起一个 Pull Request 让团队的其它人知道功能已经完成。
现在金康变成了领导，领导收到了子旺发来的 pull request，金康对工作有些不满意，所以让子旺进行修改，这些修改对话都是在 pull request 上完成的。终于，金康接受了 pull request 进行了 merge，金康在合并前一定要检出 master 分支并确认是它是最新的，这样才可以合并到 master 上。
Gitflow 工作流
相对于使用仅有的一个 master 分支，Gitflow 工作流使用两个分支来记录项目的历史。master 分支存储了正式发布的历史，而 develop 分支作为功能的集成分支。
每个新功能位于一个自己的分支，这样可以 push 到中央仓库以备份和协作。但功能分支不是从 master 分支上拉出新分支，而是使用 develop 分支作为父分支。
一旦 develop 分支上有了做一次发布的功能，就从 develop 分支上 checkout 一个发布 release 分支。新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上 —– 这个分支只应该做 Bug 修复、文档生成和其它面向发布任务。一旦对外发布的工作都完成了，发布 release 分支合并到 master 分支并分配一个版本号打好 Tag。另外，这些从新建发布分支以来的做的修改要合并回 develop 分支。
维护分支或说是热修复（hotfix）分支用于给产品发布版本快速生成补丁，这是唯一可以直接从 master 分支 fork 出来的分支。修复完成，修改应该马上合并回 master 分支和 develop 分支（当前的发布分支），master 分支应该用新的版本号打好 Tag。
Forking 工作流
Forking 工作流和前面讨论的几种工作流有根本的不同，这种工作流不是使用单个服务端仓库作为『中央』代码基线，而让各个开发者都有一个服务端仓库。这意味着各个代码贡献者有 2 个 Git 仓库而不是 1 个：一个本地私有的，另一个服务端公开的。
工作流程是这样的：
团队里面的金康出去创业了，开了一家新公司，但是子旺舍不得金康，所以还在帮助金康开发，现在金康初识化了一个仓库，并进行了一些提交，自己在玩。
子旺是一个好心人，想帮助金康做一些贡献，因此子旺 fork 了金康的项目，此时子旺需要在自己的仓库中开设 2 个远程别名 —— 一个指向正式仓库（金康的仓库），另一个指向开发者自己的服务端仓库（子旺的仓库）。这样做的目的是为了能够拉取金康的仓库更新。代码如下：
# 给金康的仓库起了一个远程别名 upstream
git remote add upstream https://github/guojinkang/gitdemo
git pull upstream master
子旺完成了功能的开发，准备合并到金康的库上，需要先进行一个 pull request，他想集成他的功能分支到上游远程仓库的 master 分支中
金康收到了 pull request，金康此时要检查子旺的代码是否可以合并 git fetch https://github/fuziwang/gitdemo feature-branch 发现可以合并，因此进行合并。
此时子旺需要拉取最新的代码 git pull upstream master