Git 作为一个源码管理系统,不可避免涉及到多人协作。

  协作必须有一个规范的流程,让大家有效地合作,使得项目井井有条地发展下去。"协作流程"在英语里,叫做"workflow"或者"flow",原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡。

  本文介绍三种广泛使用的协作流程:

  • Git flow
  • Github flow
  • Gitlab flow

  如果你对Git还不是很熟悉,可以先阅读下面的文章。

  一、功能驱动

  本文的三种协作流程,有一个共同点:都采用"功能驱动式开发"(Feature-driven development,简称FDD)。

  它指的是,需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(hotfix branch)。完成开发后,该分支就合并到主分支,然后被删除。

  二、Git flow

  最早诞生、并得到广泛采用的一种协作流程,就是Git flow 。

  2. 1 特点

  它最主要的特点有两个。

  首先,项目存在两个长期分支。

  • 主分支master
  • 开发分支develop

  前者用于存放对外发布的版本,任何时候在这个分支拿到的,都是稳定的分布版;后者用于日常开发,存放最新的开发版。

  其次,项目存在三种短期分支。

  • 功能分支(feature branch)
  • 补丁分支(hotfix branch)
  • 预发分支(release branch)

  一旦完成开发,它们就会被合并进developmaster,然后被删除。

  Git flow 的详细介绍,请阅读我翻译的中文版《Git 分支管理策略》

  2. 2 评价

  Git flow的优点是清晰可控,缺点是相对复杂,需要同时维护两个长期分支。大多数工具都将master当作默认分支,可是开发是在develop分支进行的,这导致经常要切换分支,非常烦人。

  更大问题在于,这个模式是基于"版本发布"的,目标是一段时间以后产出一个新版本。但是,很多网站项目是"持续发布",代码一有变动,就部署一次。这时,master分支和develop分支的差别不大,没必要维护两个长期分支。

  三、Github flow

  Github flow 是Git flow的简化版,专门配合"持续发布"。它是 Github.com 使用的协作流程。

  3. 1 流程

  它只有一个长期分支,就是master,因此用起来非常简单。

  官方推荐的流程如下。

  第一步:根据需求,从master拉出新分支,不区分功能分支或补丁分支。

  第二步:新分支开发完成后,或者需要讨论的时候,就向master发起一个pull reqest(简称PR)。

  第三步:Pull Request既是一个通知,让别人注意到你的请求,又是一种对话机制,大家一起评审和讨论你的代码。对话过程中,你还可以不断提交代码。

  第四步:你的Pull Request被接受,合并进master,重新部署后,原来你拉出来的那个分支就被删除。(先部署再合并也可。)

  3. 2 评价

  Github flow 的最大优点就是简单,对于"持续发布"的产品,可以说是最合适的流程。

  问题在于它的假设:master分支的更新与产品的发布是一致的。也就是说,master分支的最新代码,默认就是当前的线上代码。

  可是,有些时候并非如此,代码合并进入master分支,并不代表它就能立刻发布。比如,苹果商店的APP提交审核以后,等一段时间才能上架。这时,如果还有新的代码提交,master分支就会与刚发布的版本不一致。另一个例子是,有些公司有发布窗口,只有指定时间才能发布,这也会导致线上版本落后于master分支。

  上面这种情况,只有master一个主分支就不够用了。通常,你不得不在master分支以外,另外新建一个production分支跟踪线上版本。

  四、Gitlab flow

  Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点,既有适应不同开发环境的弹性,又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。

  4. 1 上游优先

  Gitlab flow 的最大原则叫做"上游优先"(upsteam first),即只存在一个主分支master,它是所有其他分支的"上游"。只有上游分支采纳的代码变化,才能应用到其他分支。

  Chromium项目就是一个例子,它明确规定,上游分支依次为:

  1. Linus Torvalds的分支
  2. 子系统(比如netdev)的分支
  3. 设备厂商(比如三星)的分支

  4. 2 持续发布

  Gitlab flow 分成两种情况,适应不同的开发流程。

  对于"持续发布"的项目,它建议在master分支以外,再建立不同的环境分支。比如,"开发环境"的分支是master,"预发环境"的分支是pre-production,"生产环境"的分支是production

  开发分支是预发分支的"上游",预发分支又是生产分支的"上游"。代码的变化,必须由"上游"向"下游"发展。比如,生产环境出现了bug,这时就要新建一个功能分支,先把它合并到master,确认没有问题,再cherry-pickpre-production,这一步也没有问题,才进入production

  只有紧急情况,才允许跳过上游,直接合并到下游分支。

  4. 3 版本发布

  对于"版本发布"的项目,建议的做法是每一个稳定版本,都要从master分支拉出一个分支,比如2-3-stable2-4-stable等等。

  以后,只有修补bug,才允许将代码合并到这些分支,并且此时要更新小版本号。

  五、一些小技巧

  5. 1 Pull Request

  功能分支合并进master分支,必须通过Pull Request(Gitlab里面叫做 Merge Request)。

  前面说过,Pull Request本质是一种对话机制,你可以在提交的时候,@相关人员团队,引起他们的注意。

  5. 2 Protected branch

  master分支应该受到保护,不是每个人都可以修改这个分支,以及拥有审批 Pull Request 的权力。

  Github 和 Gitlab 都提供"保护分支"(Protected branch)这个功能。

  5. 3 Issue

  Issue 用于 Bug追踪和需求管理。建议先新建 Issue,再新建对应的功能分支。功能分支总是为了解决一个或多个 Issue。

  功能分支的名称,可以与issue的名字保持一致,并且以issue的编号起首,比如"15-require-a-password-to-change-it"。

  开发完成后,在提交说明里面,可以写上"fixes #14"或者"closes #67"。Github规定,只要commit message里面有下面这些动词 + 编号,就会关闭对应的issue。

  • close
  • closes
  • closed
  • fix
  • fixes
  • fixed
  • resolve
  • resolves
  • resolved

  这种方式还可以一次关闭多个issue,或者关闭其他代码库的issue,格式是 username/repository#issue_number

  Pull Request被接受以后,issue关闭,原始分支就应该删除。如果以后该issue重新打开,新分支可以复用原来的名字。

  5. 4 Merge节点

  Git有两种合并:一种是"直进式合并"(fast forward),不生成单独的合并节点;另一种是"非直进式合并"(none fast-forword),会生成单独节点。

  前者不利于保持commit信息的清晰,也不利于以后的回滚,建议总是采用后者(即使用--no-ff参数)。只要发生合并,就要有一个单独的合并节点。

  5. 5 Squash 多个commit

  为了便于他人阅读你的提交,也便于cherry-pick或撤销代码变化,在发起Pull Request之前,应该把多个commit合并成一个。(前提是,该分支只有你一个人开发,且没有跟master合并过。)

  这可以采用rebase命令附带的squash操作,具体方法请参考我写的《Git 使用规范流程》

  (完)

http://kb.cnblogs.com/page/535581/

Git协作流程(转)的更多相关文章

  1. Git协作流程

    Git 作为一个源码管理系统,不可避免涉及到多人协作. 协作必须有一个规范的流程,让大家有效地合作,使得项目井井有条地发展下去."协作流程"在英语里,叫做"workflo ...

  2. 小团队Git协作流程

    git和svn 最大的差异在于git是分布式的管理方式而svn是集中式的管理方式. 集中式 集中式代码管理的核心是服务器,所有开发者在开始coding之前必须从服务器获取代码,然后开发,最后解决冲突, ...

  3. git 的安装使用以及协作流程

    git安装: sudo apt-get install git-core git使用: 转:https://www.liaoxuefeng.com/wiki/0013739516305929606dd ...

  4. SourceTree 实现 git flow 流程

    为什么使用 git 和 git flow,这篇文章 深入理解学习Git工作流 的内容相信能够给你一个完整的答案. 我们以使用SVN的工作流来使用git有什么不妥? git 方便的branch在哪里,团 ...

  5. 前端开发工程师 - 05.产品前端架构 - 协作流程 & 接口设计 & 版本管理 & 技术选型 &开发实践

    05.产品前端架构 第1章--协作流程 WEB系统 角色定义 协作流程 职责说明 第2章--接口设计 概述 接口规范 规范应用 本地开发 第3章--版本管理 见 Java开发工程师(Web方向) - ...

  6. GitHub团队协作流程

    说来惭愧,这么长时间,第一次参与修改开源项目,所以整理了一份GitHub团队协作流程,作为备忘,文章大部分内容参考https://www.cnblogs.com/schaepher/p/4933873 ...

  7. git详情、git工作流程、常用命令、忽略文件、分支操作、gitee远程仓库使用

    今日内容概要 git详情 git工作流程 git常用命令 过滤文件 分支操作 git远程仓库使用 可参照:https://www.cnblogs.com/liuqingzheng/p/15328319 ...

  8. git工作流程

    git工作流程 一般工作流程如下: 克隆 Git 资源作为工作目录. 在克隆的资源上添加或修改文件. 如果其他人修改了,你可以更新资源. 在提交前查看修改. 提交修改. 在修改完成后,如果发现错误,可 ...

  9. 怎样通过git协作开发

    近期iOS群里的一些小伙伴刚刚毕业,刚參加工作的小伙伴们,对于怎样进行git下的一个写作开发抱有较大的疑惑.今天小汤我就给大家分享个git下协作开发的小技巧. 怎样通过git协作开发? 当两个开发人员 ...

随机推荐

  1. Windows Server 架设VPN要点

    PPTP 为给客户端连接的VPN用户帐户设置“允许拨入”属性. VPN服务端与客户端都无需安装任何证书. L2TP/IPSEC VPN服务器与客户端分别需要在自己的“本地计算机帐户>个人”(而非 ...

  2. JS脚本加载与执行对性能的影响

    高性能JavaScript-JS脚本加载与执行对性能的影响 在web产品优化准则中,很重要的一条是针对js脚本的加载和执行方式的优化.本篇文章简单描述一下其中的优化准则. 1. 脚本加载优化 1.1 ...

  3. 转载:ecshop自定义销量

    转自:http://www.phpally.com/ecshop%E8%87%AA%E5%AE%9A%E4%B9%89%E9%94%80%E9%87%8F/ 本补丁以假乱真,对网站销售有一定帮助,计算 ...

  4. oracle12c(oracle12.1.0.1.0)安装指南--实测OEL5.9(RH5)

    [root@oel ora12c]# uname -a Linux oel 2.6.39-300.26.1.el5uek #1 SMP Thu Jan 3 18:31:38 PST 2013 x86_ ...

  5. Lucene40SkipListWriter

    多级跳跃表是保存在tim文件里的. tip是term index,tim是term dictionary.记忆方法是,p是pointer因此是term index. 这个类会保存多个level的las ...

  6. 什么是“Bash”破绽?

    摘要:近来的linux系统出现"Bash"漏洞可以被认为是第一个互联网造成安全讨论和思考.错的资料. 什么是"Bash"漏洞?它是怎样工作的?它是否可以成为新的 ...

  7. FTP文件操作之下载文件

    前面写了采用ftp上传文件,有了上传怎么能够没有下载呢?如果只有上传没有下载,那上传了也没啥用了.所以今天就跟大家一起学习学习使用ftp下载文件. 知道了怎么上传,那么下载也就变得很简单了,上传是把文 ...

  8. Unbound classpath container: 'JRE System Library [jdk17060]' in project ***

    项目报告的错误列表 Unbound classpath container: 'JRE System Library [jdk17060]' in project **** 误. 原因是,我升级JDK ...

  9. MySQL与逻辑模块

    启动MySQL 1.初始化模块运行&&存储引擎初始化运行 2.1中运行完毕后 ---->连接管理模块接手 3.连接管理模块启动处理client连接请求的监听程序(tcp/ip 网 ...

  10. 【Linux探索之旅】第一部分第六课:Linux如何安装在虚拟机中

    内容简介 1.第一部分第六课:Linux如何安装在虚拟机中 2.第二部分第一课预告:终端Terminal,好戏上场 Linux如何安装在虚拟机中 虽然我们带大家一起在电脑的硬盘上安装了Ubuntu这个 ...