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的通知功能非常有用,因为项目维护者不可能知道其它开发者在他们自己的仓库添加了提交。

由于各个开发有自己的公开仓库,Pull Request的源仓库和目标仓库不是同一个。源仓库是开发者的公开仓库,源分支是包含了修改的分支。如果开发者要合并修改到正式代码库中,那么目标仓库是正式仓库,目标分支是master分支。

Pull Request也可以用于正式项目之外的其它开发者之间的协作。比如,如果一个开发者和一个团队成员一起开发一个功能,他们可以发起一个Pull Request,用团队成员的Bitbucket仓库作为目标,而不是正式项目的仓库。然后使用相同的功能分支作为源和目标分支。

2个开发者之间可以在Pull Request中讨论和开发功能。完成开发后,他们可以发起另一个Pull Request,请求合并功能到正式的master分支。在Forking工作流中,这样的灵活性让Pull Request成为一个强有力的协作工具。

示例

下面的示例演示了Pull Request如何在在Forking工作流中使用。也同样适用于小团队的开发协作和第三方开发者向开源项目的贡献。

在示例中,小红是个开发,小明是项目维护者。他们各自有一个公开的Bitbucket仓库,而小明的仓库包含了正式工程。

小红fork正式项目

小红先要fork小明的Bitbucket仓库,开始项目的开发。她登陆Bitbucket,浏览到小明的仓库页面,
Fork按钮。

然后为fork出来的仓库填写名字和描述,这样小红就有了服务端的项目拷贝了。

小红克隆她的Bitbucket仓库

下一步,小红克隆自己刚才fork出来的Bitbucket仓库,以在本机上准备出工作拷贝。命令如下:

git clone https://user@bitbucket.org/user/repo.git

请记住,git clone会自动创建origin远程别名,是指向小红fork出来的仓库。

小红开发新功能

在开始改代码前,小红要为新功能先新建一个新分支。她会用这个分支作为Pull Request的源分支。


git checkout -b some-feature

编辑代码

git commit -a -m "Add first draft of some feature"

在新功能分支上,小红按需要添加提交。甚至如果小红觉得功能分支上的提交历史太乱了,她可以用交互式rebase来删除或压制提交。对于大型项目,整理功能分支的历史可以让项目维护者更容易看出在Pull Request中做了什么内容。

小红push功能到她的Bitbucket仓库中

小红完成了功能后,push功能到她自己的Bitbucket仓库中(不是正式仓库),用下面简单的命令:

git push origin some-branch

这时她的变更可以让项目维护者看到了(或者任何想要看的协作者)。

小红发起Pull Request

Bitbucket上有了她的功能分支后,小红可以用她的Bitbucket账号浏览到她的fork出来的仓库页面,点右上角的【Pull Request】按钮,发起一个Pull Request。弹出的表单自动设置小红的仓库为源仓库,询问小红以指定源分支、目标仓库和目标分支。

小红想要合并功能到正式仓库,所以源分支是她的功能分支,目标仓库是小明的公开仓库,而目标分支是master分支。另外,小红需要提供Pull Request的标题和描述信息。如果需要小明以外的人审核批准代码,她可以把这些人填在【Reviewers】文本框中。

创建好了Pull Request,通知会通过Bitbucket系统消息或邮件(可选)发给小明。

小明review Pull Request

在小明的Bitbucket仓库页面的【Pull Request】Tab可以看到所有人发起的Pull Request。点击小红的Pull Request会显示出Pull Request的描述、功能的提交历史和每个变更的差异(diff)。

如果小明想要合并到项目中,只要点一下【Merge】按钮,就可以同意Pull Request并合并到master分支。

但如果像这个示例中一样小明发现了在小红的代码中的一个小Bug,要小红在合并前修复。小明可以在整个Pull Request上加上评注,或是选择历史中的某个提交加上评注。

小红补加提交

如果小红对反馈有任何疑问,可以在Pull Request中响应,把Pull Request当作是她功能讨论的论坛。

小红在她的功能分支新加提交以解决代码问题,并push到她的Bitbucket仓库中,就像前一轮中的做法一样。这些提交会进入的Pull Request,小明在原来的评注旁边可以再次review变更。

小明接受Pull Request

最终,小明接受变更,合并功能分支到master分支,并关闭Pull Request。至此,功能集成到项目中,其它的项目开发者可以用标准的git pull命令pull这些变更到自己的本地仓库中。

下一站

到了这里,你应该有了所有需要的工具来集成Pull Request到你自己的工作流。请记住,Pull Request并不是为了替代任何基于Git的协作工作流,而是它们的一个便利的补充,让团队成员间的协作更轻松方便。


« Forking工作流    概述 »

Git - Pull Request工作流的更多相关文章

  1. Pull Request 工作流——更高效的管理代码

    目录 Pull Request 工作流--更高效的管理代码 1.问题 2.解决方案 3.Git分支流管理代码具体实施 3.1本地分支操作管理 3.1.1查看分支 3.1.2创建分支 3.1.3切换分支 ...

  2. git pull request 流程

    git pull request 用于在 fork 官方 repo 到个人 github, 在本地修改后,向官方 repo 请求合并.在官方团队审查过代码后,就可以将自己所做的改动合并到官方 repo ...

  3. Git工作流指南:Pull Request工作流

    参考地址:http://blog.jobbole.com/76854/ Pull Requests是Bitbucket上方便开发者之间协作的功能.提供了一个用户友好的Web界面,在集成提交的变更到正式 ...

  4. git pull request

    如何发 PR 以下以 wiki-pages 为例 把项目 fork 到自己名下,然后 clone 到本地 git clone git@code.xiaojukeji.com:yexiliang/wik ...

  5. git fork , git pull request那回事

    git fork 原理 相当于你在原项目的主分支上又建立了一个分支,你可以在该分支上任意修改,如果想将你的修改合并到原项目中时,可以pull request,这样原项目的作者就可以将你修改的东西合并到 ...

  6. 好代码是管出来的——Git的分支工作流与Pull Request

    上一篇文章介绍了常用的版本控制工具以及git的基本用法,从基本用法来看git与其它的版本控制工具好像区别不大,都是对代码新增.提交进行管理,可以查看提交历史.代码差异等功能.但实际上git有一个重量级 ...

  7. GIT团队合作探讨之二--Pull Request

    pull request是github/bitbucket给开发人员实现便利合作提供的一个feature.他们提供一个用户友好的web界面在进代码之前来讨论这些变更. 简单说,pull request ...

  8. git 上的pull request 是什么意思?

    1.git 上有常见的pull request 功能 2.pull request 的含义 解释一:    有一个仓库,叫Repo A.你如果要往里贡献代码,首先要Fork这个Repo,于是在你的Gi ...

  9. Git使用之pull request

    一直对git的使用都不熟,由于工作需要经常需要在github上pull request,第一次还是有些麻烦的,写个笔记记录下 1. fork源项目到自己的github仓库中 fork之后自己也会多出一 ...

随机推荐

  1. 制作做最小的fedora、ubuntu , jeos系统

    之前做过, 2018年4月底,最新的fedora28 .ubuntu18.04发布后,自己又尝试做了下. ubuntu的成功了,比较简单: fedora的其实不用自己去制作,直接定制官方的Atomic ...

  2. Mapper method 'com.autoyol.mapper.trans.AccountLogMapper.getTotalIncomByMemNoLastest attempted to return null from a method with a primitive return type (int).解决方法

    1.打开日志输出,降低日志级别. <AppenderRef ref="console" level="trace"></AppenderRef ...

  3. 申请LINE 帐号的所有方法

    如果你打算用LINE 交朋友或是做行销,你就必须先要拥有一个甚至许多个LINE 帐号.在本篇文章中,将分享给你目前申请LINE 帐号的所有可能方法. 目前LINE 公司允许大家使用以下二种身分申请LI ...

  4. OpenVPN多处理之-多队列TUN多实例

    两年前我以前提到了多个OpenVPN共享一个tun虚拟网卡,旨在降低管理开销和切换开销,由于我讨厌在外面对一大堆网卡做Bridge或者Bonding,除了初衷不同,其实的关于TUN的进展一直没有偏离我 ...

  5. JQuery难点备忘

    1 jquery绑定事件如何传递参数 $("#btn").bind("click",{"id":"111"," ...

  6. iOS - 解决Unable to add a source with url `https://github.com/CocoaPods/Specs.git` named

    1  本来cocopods没有问题,最近创建项目,利用cocopods导入第三方库的时候,出现如下错误: [!] Unable to add a source with url `https://gi ...

  7. DATAGUARD的搭建

    ORACLE Data Guard 理论知识 请查看此blog :http://blog.csdn.net/haibusuanyun/article/details/11519241 Oracle D ...

  8. GC--垃圾收集器

    把周末的文章放在现在才来写,是自己太忙了?还是堕落了? 好吧直接进入主题吧,简单干脆的理解会让自己记忆深刻: 首先说明:GC垃圾收集器关注两件事情: 第一件:查找所有存活对象. 第二件:抛弃死对象(不 ...

  9. 开源CMS的比较和选择

    最近就cms系统折腾了一下,主要还是以 构架为主,以下做一个大概的比较: 1. Nuke 一般称为DNN,这是最开始Microsoft发布 的时候,用vb做了一个web的演示例子,最终这个例子发展成了 ...

  10. linux 停止对某个端口的监听

    1.通过"netstat -anp" 来查看哪些端口被打开. 2.关掉对应的应用程序,则端口就自然关闭了,如:"kill -9 PID" (PID:进程号)