Pull Request 可以和功能分支工作流、 或 一起使用。但一个 Pull Request 要求要么分支不同要么仓库不同，所以不能用于集中式工作流。 在不同的工作流中使用 Pull Request 会有一些不同，但基本的过程是这样的：开发者在本地仓库中新建一个专门的分支开发功能。开发者 push 分支修改到公开的 Bitbucket 仓库中。开发者通过 Bitbucket 发起一个 Pull Request 。
和其它的 Git 工作流一样，Forking 工作流要先有一个公开的正式仓库存储在服务器上。 但一个新的开发者想要在项目上工作时，不是直接从正式仓库克隆，而是 fork 正式项目在服务器上创建一个拷贝。这个仓库拷贝作为他个人公开仓库 ——其它开发者不允许 push 到这个仓库，但可以 pull 到修改（后面我们很快就会看这点很重要）。
Gitflow 工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并 push 分支到要中央仓库中。
功能分支工作流仍然用中央仓库，并且 master 分支还是代表了正式项目的历史。但不是直接提交本地历史到各自的本地 master 分支，开发者每次在开始新功能前先创建一个新分支。功能分支应该有个有描述性的名字，比如 animated-menu-items 或 issue-#1061 ，这样可以让分支有个清楚且高聚焦的用途。
像 Subversion 一样，集中式工作流以中央仓库作为项目所有修改的单点实体。相比 SVN 缺省的开发分支 trunk ，Git 叫做master，所有修改提交到这个分支上。本工作流只用到 master 这一个分支。开发者开始先克隆中央仓库。在自己的项目拷贝中像 SVN 一样的编辑文件和提交修改；但修改是存在本地的，和中央仓库是完全隔离的。开发者可以把和上游的同步延后到一个方便时间点。
关注时代Java
