Files
translations/git-workflows-and-tutorials/pull-request.md
2014-08-31 03:01:45 +08:00

4.1 KiB
Raw Blame History

Pull Request工作流

Pull RequestsBitbucket上方便开发者之间协作的功能。 提供了一个用户友好的Web界面,在集成提交的变更到正式项目前可以对变更进行讨论。

开发者向团队成员通知功能开发已经完成,Pull Requests是最简单的用法。 开发者完成功能开发后,通过Bitbucket账号发起一个Pull Request。 这样让涉及这个功能的所有人知道要去做Code Review和合并到master分支。

但是,Pull Request远不止一个简单的通知,而是一个专门为提交的功能的论坛。 如果变更有任何问题,团队成员反馈在Pull Request中,甚至push提交微调功能。 在Pull Request中,所有的这些活动都直接跟踪了。

相比其它的协作模型,这种分享提交的形式有助于打造一个更流畅的工作流。 SVNGit都能通过一个简单的脚本收到通知邮件;但是,讨论变更时,开发者通常只能去回复邮件。 这样做会变得杂乱,尤其还要涉及后面的几个提交时。 Pull Requests把所有相关功能整合到一个和Bitbucket仓库界面集成的用户友好Web界面中。

解析Pull Request

当要发起一个Pull Request,你所要做的就是请求(Request)另一个开发者(比如项目的维护者) 来pull你仓库中一个分支到他的仓库中。这意味着你要提供4个信息以发起Pull Request 源仓库、源分支、目的仓库、目的分支。

这几值多数Bitbucket会设置合适的缺省值。但取决你用的协作工作流,你的团队可能会指定不同的值。 上图显示了一个Pull Request请求合并一个功能分支到正式的master分支上,但可以有多种不同的Pull Request用法。

🍺 工作方式

Pull Request功能分支工作流Gitflow工作流Forking工作流一起使用。 但一个Pull Request需求要么分支不同要么仓库不同,所以不能用于集中式工作流。 在不同的工作流中使用Pull Request会稍许不同,但基本的过程是这样的:

  1. 开发者在本地仓库中新建一个专门的分支开发功能。
  2. 开发者push分支修改到公开的Bitbucket仓库中。
  3. 开发者通过Bitbucket发起一个Pull Request
  4. 团队的其它成员review code,讨论并修改。
  5. 项目维护者合并功能到官方仓库中并关闭Pull Request

本方后面内容说明,Pull Request如何在不同协作工作流应用。

在功能分支工作流中使用Pull Request

功能分支工作流用一个共享的Bitbucket仓库来管理协作,开发者在专门的分支上开发功能。 但不是合并到master分支上,而是在合并到主代码库之前开发者应该开一个Pull Request发起功能的讨论。

功能分支工作流只有一个公有的仓库,所以Pull Request的目的仓库和源仓库总是同一个。 通常开发者会指定他的功能分支作为源分支,master分支作为目的分支。

收到Pull Request后,项目维护者要决定如何做。如果功能没问题,就简单地合并到master分支,关闭Pull Request。 但如果提交的变更有问题,他可以在Pull Request中反馈。之后新加的提交也会评论之后接着显示出来。

在功能还没有完全开发完的时候,也可能发起一个Pull Request。 比如开发者在实现某个需求时碰到了麻烦,他可以发一个包含正在进行中工作的Pull Request。 其它的开发者可以在Pull Request提供建议,或者甚至直接添加提交来解决问题。

Gitflow工作流中使用Pull Request


« Forking工作流                            概述 »