一旦你玩转了集中式工作流,在开发过程中可以很简单地加上功能分支,用来鼓励开发者之间协作和简化交流。

功能分支工作流背后的核心思路是所有的功能开发应该在一个专门的分支,而不是在master分支上。这个隔离可以方便多个开发者在各自的功能上开发而不会弄乱主干代码。另外,也保证了master分支的代码一定不会是有问题的,极大有利于集成环境。

功能开发隔离也让pull requests工作流成功可能,pull requests工作流能为每个分支发起一个讨论,在分支合入正式项目之前,给其它开发者有表示赞同的机会。另外,如果你在功能开发中有问题卡住了,可以开一个pull requests来向同学们征求建议。这些做法的重点就是,pull requests让团队成员之间互相评论工作变成非常方便!

工作方式

功能分支工作流仍然用中央仓库,并且master分支还是代表了正式项目的历史。但不是直接提交本地历史到各自的本地master分支,开发者每次在开始新功能前先创建一个新分支。功能分支应该有个有描述性的名字,比如animated-menu-itemsissue-#1061,这样可以让分支有个清楚且高聚焦的用途。

master分支和功能分支之间,Git是没有技术上的区别,所以开发者可以用和集中式工作流中完全一样的方式编辑、暂存和提交修改到功能分支上。

另外,功能分支也可以(且应该)push到中央仓库中。这样不修改正式代码就可以和其它开发者分享提交的功能。由于master仅有的一个『特殊』分支,在中央仓库上存多个功能分支不会有任何问题。当然,这样做也可以很方便地备份各自的本地提交。

Pull Requests

功能分支除了可以隔离功能的开发,也使得通过Pull Requests讨论变更成为可能。一旦某个开发完成一个功能,不是立即合并到master,而是push到中央仓库的功能分支上并发起一个Pull Request请求去合并修改到master。在修改成为主干代码前,这让其它的开发者有机会先去Review变更。

Code ReviewPull Requests的一个重要的收益,但Pull Requests目的是讨论代码一个通用方式。你可以把Pull Requests作为专门给某个分支的讨论。这意味着可以在更早的开发过程中就可以进行Code Review。比如,一个开发者开发功能需要帮助时,要做的就是发起一个Pull Request,相关的人就会自动收到通知,在相关的提交旁边能看到需要帮助解决的问题。

一旦Pull Request被接受了,发布功能要做的就和集中式工作流就很像了。首先,确定本地的master分支和上游的master分支是同步的。然后合并功能分支到本地master分支并push已经更新的本地master分支到中央仓库。

仓库管理的产品解决方案像BitbucketStash,可以良好地支持Pull Requests。可以看看StashPull Requests文档

示例

下面的示例演示了如何把Pull Requests作为Code Review的方式,但注意Pull Requests可以用于很多其它的目的。

小红开始开发一个新功能

在开始开发功能前,小红需要一个独立的分支。使用下面的命令新建一个分支

git checkout -b marys-feature master

这个命令检出一个基于master名为marys-feature的分支,Git-b选项表示如果分支还不存在则新建分支。这个新分支上,小红按老套路编辑、暂存和提交修改,按需要提交以实现功能:

git status
git add
git commit

小红要去吃个午饭

早上小红为新功能添加一些提交。去吃午饭前,push功能分支到中央仓库是很好的做法,这样可以方便地备份,如果和其它开发协作,也让他们可以看到小红的提交。

git push -u origin marys-feature

这条命令push marys-feature分支到中央仓库(origin),-u选项设置本地分支去跟踪远程对应的分支。设置好跟踪的分支后,小红就可以使用git push命令省去指定推送分支的参数。

小红完成功能开发

小红吃完午饭回来,完成整个功能的开发。在合并到master之前,她发起一个Pull Request让团队的其它人知道功能已经完成。但首先,她要确认中央仓库中已经有她最近的提交:

git push

然后,在她的Git GUI客户端中发起Pull Request,请求合并marys-featuremaster,团队成员会自动收到通知。Pull Request很酷的是可以在相关的提交旁边显示评注,所以你可以很对某个变更集提问。

小黑收到Pull Request

小黑收到了Pull Request后会查看marys-feature的修改。决定在合并到正式项目前是否要做些修改,且通过Pull Request和小红来回地讨论。

小红再做修改

要再做修改,小红用和功能第一个迭代完全一样的过程。编辑、暂存、提交并push更新到中央仓库。小红这些活动都会显示在Pull Request上,小黑可以断续做评注。

如果小黑有需要,也可以把marys-feature分支拉到本地,自己来修改,他加的提交也会一样显示在Pull Request上。

小红发布她的功能

一旦小黑可以的接受Pull Request,就可以合并功能到稳定项目代码中(可以由小黑或是小红来做这个操作):

git checkout master
git pull
git pull origin marys-feature
git push

无论谁来做合并,首先要检出master分支并确认是它是最新的。然后执行git pull origin marys-feature合并marys-feature分支到和已经和远程一致的本地master分支。你可以使用简单git merge marys-feature命令,但前面的命令可以保证总是最新的新功能分支。最后更新的master分支要重新push回到origin

这个过程常常会生成一个合并提交。有些开发者喜欢有合并提交,因为它像一个新功能和原来代码基线的连通符。但如果你偏爱线性的提交历史,可以在执行合并时rebase新功能到master分支的顶部,这样生成一个快进(fast-forward)的合并。

一些GUI客户端可以只要点一下『接受』按钮执行好上面的命令来自动化Pull Request接受过程。如果你的不能这样,至少在功能合并到master分支后能自动关闭Pull Request

与此同时,小明在做和小红一样的事

当小红和小黑在marys-feature上工作并讨论她的Pull Request的时候,小明在自己的功能分支上做完全一样的事。

通过隔离功能到独立的分支上,每个人都可以自主的工作,当然必要的时候在开发者之间分享变更还是比较繁琐的。

下一站

到了这里,但愿你发现了功能分支可以很直接地在集中式工作流的仅有的master分支上完成多功能的开发。另外,功能分支还使用了Pull Request,使得可以在你的版本控制GUI客户端中讨论某个提交。

功能分支工作流是开发项目异常灵活的方式。问题是,有时候太灵活了。对于大型团队,常常需要给不同分支分配一个更具体的角色。Gitflow工作流是管理功能开发、发布准备和维护的常用模式。

本文由伯乐在线-李鼎翻译。未经许可,禁止转载!   源文地址:http://blog.jobbole.com/76857/
英文出处:
atlassian

译注
自己理解粗浅,译文源码GitHub,翻译中不足和不对之处,欢迎建议(提交Issue)和指正(Fork后提交代码)!

Git工作流指南:功能分支工作流(转)的更多相关文章

  1. Git工作流指南:Gitflow工作流

    git工作流 1.Git flow 核心分支:master,dev 可能还会有:功能分支,bug修复分支,预发布分支 2.github flow:只一个长期分支,就是master 第一步:根据需求,从 ...

  2. Git工作流指南:Gitflow工作流 Comparing Workflows

    Comparing Workflows The array of possible workflows can make it hard to know where to begin when imp ...

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

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

  4. Git工作流指南:集中式工作流

    转载:http://blog.jobbole.com/76847/ 本文由 伯乐在线 - 李鼎 翻译.未经许可,禁止转载!英文出处:atlassian.欢迎加入翻译组. 转到分布式版本控制系统看起来像 ...

  5. git 七图七模式 -- 工作流

    git 是现在最流行的代码合作工作方式,本文通过七张图来描述一下当下最流行的 git 工作模式 集中式工作流 集中式工作流 功能分支工作流 Gitflow工作流 Forking 工作流 Pull Re ...

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

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

  7. (Git 钩子)自定义你的工作流 和引用日志

    Git 钩子是在 Git 仓库中特定事件发生时自动运行的脚本.它可以让你自定义 Git 内部的行为,在开发周期中的关键点触发自定义的行为. Git 钩子最常见的使用场景包括推行提交规范,根据仓库状态改 ...

  8. 8.3 Customizing Git - Git Hooks 钩子 自动拉取 自动部署 提交工作流钩子,电子邮件工作流钩子和其他钩子

    https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks https://github.com/git/git/blob/master/temp ...

  9. 我的微型工作流引擎-功能解析及API设计

    一.前言 上一篇我给大家介绍了我的工作流的模型和基本的设计,这篇我想详细说明下我这款工作流的功能及使用示例.这款工作流主要是面向开发者设计的,为了先让大家有个全局的认识,局部功能的设计实现就不细说了, ...

随机推荐

  1. RTT之内核服务函数

    一 延时函数: rt_thread_delay(t) //调用时进入系统调度. rt_kprintf()函数在kservice.c中实现,如果不使用设备驱动,则由自定义函数void rt_hw_con ...

  2. WSGI学习系列WSME

    Introduction Web Services Made Easy (WSME) simplifies the writing of REST web services by providing ...

  3. (转)Linux命令:使用dig,nslookup命令解析域名

    Linux命令:使用dig命令解析域名 Linux下解析域名除了使用nslookup之外,开可以使用dig命令来解析域名,dig命令可以得到更多的域名信息. dig的全称是 (domain infor ...

  4. Linux常用操作命令介绍

     Linux常用操作命令介绍 重要概念 CPU:就像人的大脑,主要负责相关事情的判断以及实际处理的机制.查询指令:cat /proc/cpuinfo 内存:大脑中的记忆区块,将皮肤.眼睛等所收集到的信 ...

  5. SuperSpider(简书爬虫JAVA版)

    * 建站数据SuperSpider(简书)* 本项目目的:* 为练习web开发提供相关的数据:* 主要数据包括:* 简书热门专题模块信息.对应模块下的热门文章.* 文章的详细信息.作者信息.* 评论区 ...

  6. Spring boot-(3) Spring Boot特性1

    本节将深入Spring Boot的细节,可以学到你想使用的或定制的Spring Boot的主要特性. 1. SpringApplication SpringApplication类为引导一个Sprin ...

  7. crypto-js遇到的坑

    最近在做H5网站,用websocket跟后台交互时,需要对数据进行加密,于是选了crypto-js组件,GitHub上api也不少,写的也清晰,但实际使用上会遇到不少坑: 加密解密时,传入的密钥key ...

  8. JS的函数参数传递为值传递

    function setAge(i) { alert(i);//24 i = 18; alert(i);//18,i的改变不会影响外面的age }; var age = 24; setAge(age) ...

  9. 如何使用Nunit进行测试

    如何使用Nunit进行测试(Visual Studio 2017 comminity) 原文:如何使用Nunit进行测试(Visual Studio 2017 comminity) 一.环境 操作系统 ...

  10. selenium googleDrive

    http://chromedriver.storage.googleapis.com/index.html?path=2.1/下载地址 把googledriver.exe 放到google浏览器下目录 ...