文档章节

Git Pull Request工作流

小致dad
 小致dad
发布于 2017/08/19 15:11
字数 2652
阅读 117
收藏 0

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

Gitflow工作流和功能分支工作流类似,但围绕项目发布定义一个严格的分支模型。在Gitflow工作流中使用Pull Request让开发者在发布分支或是维护分支上工作时,可以有个方便的地方对关于发布分支或是维护分支的问题进行交流。

Gitflow工作流中Pull Request的使用过程和上一节中完全一致:当一个功能、发布或是热修复分支需要Review时,开发者简单发起一个Pull Request,团队的其它成员会通过Bitbucket收到通知。

新功能一般合并到develop分支,而发布和热修复则要同时合并到develop分支和master分支上。Pull Request可能用做所有合并的正式管理。

Forking工作流中使用Pull Request

Forking工作流中,开发者push完成的功能到他自己的仓库中,而不是共享仓库。然后,他发起一个Pull Request,让项目维护者知道他的功能已经可以Review了。

在这个工作流,Pull Request的通知功能非常有用,因