工作流其实不是一个初级主题，背后的本质问题其实是有效的项目流程管理和高效的开发协同约定。 这篇指南以大家在 SVN 中已经广为熟悉使用的集中式工作流作为起点，循序渐进地演进到其它高效的 Git 分布式工作流，还介绍了如何配合使用便利的 Pull Request 功能，体系地讲解了各种工作流的应用。
工作流是一种非常常见的场景，比如企业内部审批、采购订单、ETL等日常企业事务，或者大数据处理流水线，常规或定制化自动化运维等。此外，音视频行业的多媒体文件分片转码、格式转换、审核校验和人脸识别等长时任务，电商旅游行业的客户线上订单，AI 行业的机器学习流水线， 生信行业的基因测序也会有工作流。
下面的示例演示了 Pull Request 如何在在 Forking 工作流中使用。 也同样适用于小团队的开发协作和第三方开发者向开源项目的贡献。在示例中，小红是个开发，小明是项目维护者。他们各自有一个公开的 Bitbucket 仓库，而小明的仓库包含了正式工程。小红 fork 正式项目小红先要 fork 小明的 Bitbucket 仓库，开始项目的开发。
Pull Request 可以和功能分支工作流、 或 一起使用。但一个 Pull Request 要求要么分支不同要么仓库不同，所以不能用于集中式工作流。 在不同的工作流中使用 Pull Request 会有一些不同，但基本的过程是这样的：开发者在本地仓库中新建一个专门的分支开发功能。开发者 push 分支修改到公开的 Bitbucket 仓库中。开发者通过 Bitbucket 发起一个 Pull Request 。
项目维护者初始化正式仓库和任何使用 Git 项目一样，第一步是创建在服务器上一个正式仓库，让所有团队成员都可以访问到。 通常这个仓库也会作为项目维护者的公开仓库。公开仓库应该是裸仓库，不管是不是正式代码库。 所以项目维护者会运行像下面的命令来搭建正式仓库：ssh user@hostgit init --bare /path/to/repo.
和其它的 Git 工作流一样，Forking 工作流要先有一个公开的正式仓库存储在服务器上。 但一个新的开发者想要在项目上工作时，不是直接从正式仓库克隆，而是 fork 正式项目在服务器上创建一个拷贝。这个仓库拷贝作为他个人公开仓库 ——其它开发者不允许 push 到这个仓库，但可以 pull 到修改（后面我们很快就会看这点很重要）。
Forking 工作流是分布式工作流，充分利用了 Git 在分支和克隆上的优势。可以安全可靠地管理大团队的开发者（ developer ），并能接受不信任贡献者（ contributor ）的提交。Forking 工作流和前面讨论的几种工作流有根本的不同，这种工作流不是使用单个服务端仓库作为『中央』代码基线，而让各个开发者都有一个服务端仓库。
下面的示例演示本工作流如何用于管理单个发布循环。假设你已经创建了一个中央仓库。创建开发分支第一步为 master 分支配套一个 develop 分支。简单来做可以本地创建一个空的 develop 分支， push 到服务器上：git branch developgit push -u origin develop以后这个分支将会包含了项目的全部历史，而 master 分支将只包含了部分历史。
Gitflow 工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并 push 分支到要中央仓库中。
Gitflow 工作流通过为功能开发、发布准备和维护分配独立的分支，让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。这节介绍的 Gitflow工作流 借鉴自在 nvie的 Vincent Driessen 。Gitflow 工作流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工作流复杂几分，但提供了用于一个健壮的用于管理大型项目的框架。
下面的示例演示了如何把 Pull Requests 作为 Code Review 的方式，但注意 Pull Requests 可以用于很多其它的目的。小红开始开发一个新功能在开始开发功能前，小红需要一个独立的分支。使用下面的命令新建一个分支：git checkout -b marys-feature master这个命令检出一个基于 master 名为 marys-feature 的分支， Git 的 -b 选项表示如果分支还不存在则新建分支。
功能分支工作流仍然用中央仓库，并且 master 分支还是代表了正式项目的历史。但不是直接提交本地历史到各自的本地 master 分支，开发者每次在开始新功能前先创建一个新分支。功能分支应该有个有描述性的名字，比如 animated-menu-items 或 issue-#1061 ，这样可以让分支有个清楚且高聚焦的用途。
让我们一起逐步分解来看看一个常见的小团队如何用这个工作流来协作的。有两个开发者小明和小红，看他们是如何开发自己的功能并提交到中央仓库上的。有人先初始化好中央仓库第一步，有人在服务器上创建好中央仓库。如果是新项目，你可以初始化一个空仓库；否则你要导入已有的 Git 或 SVN 仓库。
像 Subversion 一样，集中式工作流以中央仓库作为项目所有修改的单点实体。相比 SVN 缺省的开发分支 trunk ，Git 叫做master，所有修改提交到这个分支上。本工作流只用到 master 这一个分支。开发者开始先克隆中央仓库。在自己的项目拷贝中像 SVN 一样的编辑文件和提交修改；但修改是存在本地的，和中央仓库是完全隔离的。开发者可以把和上游的同步延后到一个方便时间点。
如果你的开发团队成员已经很熟悉 Subversion ，集中式工作流让你无需去适应一个全新流程就可以体验 Git 带来的收益。这个工作流也可以作为向更 Git 风格工作流迁移的友好过渡。 转到分布式版本控制系统看起来像个令人生畏的任务，但不改变已用的工作流你也可以用上 Git 带来的收益。团队可以用和 Subversion 完全不变的方式来开发项目。
工作流有各式各样的用法，但也正因此使得在实际工作中如何上手使用变得很头大。这篇指南通过总览公司团队中最常用的几种 Git 工作流让大家可以上手使用。在阅读的过程中请记住，本文中的几种工作流是作为方案指导而不是条例规定。在展示了各种工作流可能的用法后，你可以从不同的工作流中挑选或揉合出一个满足你自己需求的工作流。
工作流其实不是一个初级主题，背后的本质问题其实是有效的项目流程管理和高效的开发协同约定，不仅是 Git 或 SVN 等 VCS 或 SCM 工具的使用。这篇指南以大家在 SVN 中已经广为熟悉使用的集中式工作流作为起点，循序渐进地演进到其它高效的分布式工作流，还介绍了如何配合使用便利的 Pull Request 功能，体系地讲解了各种工作流的应用。
工作流(Workflow): 工作流就是通过计算机技术对业务流程进行自动化管理。实现多个参与者按照预定的流程去自动执行业务流程。
本文通过一个工作流Activiti框架的具体使用示例，具体详尽的介绍了工作流Activiti框架的使用方式。包括创建流程，发布流程，启动一个流程实例，完成一个流程实例以及挂起和激活一个流程实例。通过对工作流Activiti的具体使用步骤的掌握，基本上就能够学会了工作流Activiti的工作流程和具体使用。
在 Forking 工作流中，开发者 push 完成的功能到他自己的仓库中，而不是共享仓库。 然后，他发起一个 Pull Request ，让项目维护者知道他的功能已经可以 Review 了。在这个工作流，Pull Request 的通知功能非常有用，因为项目维护者不可能知道其它开发者在他们自己的仓库添加了提交。由于各个开发有自己的公开仓库，Pull Request 的源仓库和目标仓库不是同一个。
关注时代Java
