本文结合了自己的项目经验及网上资料,再加上个人的一些体会。出于对git管理工具的热爱,特编写此文。
git管理模型
分布式但集中化,这是对git管理模型最好的阐述。模型图如下图所示:
上图中origin是一个"中心库",当然这个中心库只是被认为是这样(因为Git是分布式的,从技术层面上来说是没有中心库的)。
每个开发者pull和push到origin,但除了中心化的push-pull关系外,每个开发者还可以从其他开发者那pull changes。比如说,对于一个比较大的新特性,在把代码提交到origin之前,很可能会安排2个或多个开发者。上图中有几个小团队:Alice和Bob,Alice和David,Clair和David。团队成员先把代码pull到队长那里,再由队长pull到origin库。
主要分支设计
中心仓库有两个分支:master和develop。
origin上的master分支,Git用户应该很熟悉,跟master并行的有一个develop分支
我们把origin/master作为主要分支,源码的HEAD总是表示production-ready(可随时部署)状态。而origin/develop上的代码是为下一次的代码发布准备的。每日构建也是基于此分支。
当develop分支达到了一个稳定状态并准备发布时,所有的改变都要合并到master分支,并标上版本号。这样每次与master合并都会会有新的部署发布。如下是相关命令:
$git checkout –b develop master
在develop分支上进行开发工作。
$git checkout master
$git merge –no-ff develop
支持分支设计
我们的开发模型使用了一些支持分支放在master和develop分支的旁边,方便开发小组之间的并行开发。不像主要分支,这些分支是有时间限制的,因为他们最终都会被移除。
我们会使用到的不同的分支有:Feature branches、Release branches、Hotfix branches。
每个分支都有各自的作用,并且有严格的规定,如:只能从哪个分支上去新开分支,只能合并到那个分支。
Feature branches
规定如下:
继承分支: develop
合并分支:develop
命名规范:除了master,develop,release-,hotfix-
Feature branches是用来开发新特性的(短期,远期都可以)。当开始开发新特性时,很可能不知道这个特性会出现在哪个目标版本。一旦开发完成就可以合并到develop,当然如果开发失败,就可以抛弃。
创建及完成一个 Feature branch
根据Feature branches的规定,创建命令如下:
$ git checkout -b myfeature develop
新特性完成时,可以合并到develop
$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop
—no-ff (注:no fast foward)标签,使得每一次的合并都创建一个新的commit记录。即使这个commit只是fast-foward,这样可以避免丢失信息
Release branch
规定如下:
继承分支: develop
合并分支:develop 和 master
命名规范:release-*
Release branch 是为新的production release准备的,可以有一些小的bug,并为发布准备一些元数据(版本号,构建日期等等)。把所有的这些工作都放到 Release branch,develop branch就能更清晰地知道下一个版本要开发哪些特性。
从develop分支合并到release分支的关键因素是:develop分支达到了release分支所要求的状态。至少所有针对该release的特性要被合并。至于那些将来会有的特性可以先放一放。然后就是为接下来即将要发布的版本分配一个版本号。
创建一个Release branch
Release branch是通过develop分支而创建。举个例子,假如1.1.5是当前的production release,然后会有一个比较大的版本发布。develop的状态已经可以发布版本了,经过商榷后,决定发布为1.2版本,所以我们创建一个release分支,并给这个分支一个新的版本号
$ git checkout -b release-1.2 develop
这个新分支可能会存在一定的时间,直到可以被合并到production branch。这段时间内,bug修补可以在这个分支上进行(而不是develop分支)。添加新特性(尤其比较大的)是不允许的。最后还是要被合并到develop,然后继续在develop分支上开发,直到下一个版本。
完成一个release branch
当release branch已经准备就绪,需要做几件事。首先,release分支被合并到master分支上(每一个提交到master上的commit都是一个新版本,切记)。然后master上的commit都要添加tag,方便将来查看和回滚。最后release上所做的修改必须合并到develop分支上,保证bug已被修补。
前两个步骤:
$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2
为了把release上的改变保存到develop,我们需要合并到develop
$ git checkout develop
$ git merge --no-ff release-1.2
这个步骤可能会导致冲突,如果这样的话,解决冲突,然后再提交。
现在一切都完成了,可以把release branch干掉了。
$ git branch -d release-1.2
Hotfix branch
规定如下:
继承分支: master
合并分支:develop 和 master
命名规范:hotfix-*
Hotfix branch和Release branch有几分相似,都是为了新的production release而准备的。比如运行过程中发现了bug,就必须快速解决,这时就可以创建一个Hotfix branch,解决完后合并到master分支上。好处是开发人员可以继续工作,有专人来负责搞定这个bug。
创建Hotfix branch
Hotfix是从master分支上创建的。假如当前运行版本是1.2,然后发现有bug,但是develop还在开发中,不太稳定,这时就可以新开一个Hotfix branch,然后开始解决问题。
$ git checkout -b hotfix-1.2.1 master
解决问题,一次或几次commit
$ git commit -m "Fixed severe production problem"
完成Hotfix branch
当结束时,bugfix要被合并到master,同时也要合并到develop,保证下个版本发布时该bug已被修复。这跟release branch完成时一样。
首先更新master和tag release
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1
接下来与develop合并
$ git checkout develop
$ git merge --no-ff hotfix-1.2.1
有一个例外,就是当存在一个release branch存在时,bugfix要被合并到release而不是develop,因为release最终会被合并到develop。
最后移除branch
$ git branch -d hotfix-1.2.1
总结
这个管理模型应该算是达到行业标准的一个模型了。在实际的开发过程中,如果不用太过于考虑项目成本及项目成员的能力水平时,这样的模型应当是首选。
相关推荐
18.1 代码管理之殇/ 253 18.1.1 发布分支/ 253 18.1.2 特性分支/ 256 18.1.3 卖主分支/ 257 18.2 分支命令概述/ 258 18.3 “Hello World”开发计划/ 259 18.4 基于特性分支的开发/ 260 18.4.1 创建分支 user1/getopt...
本文来自csdn,文章主要介绍了在ubuntu14.04环境下git的基本使用方法,一个分支模型中,各个操作的流程和其对于开发过程的...Git本身并不能称之为一个完整的配置管理工具,但在开源领域,却是目前做的最好的版本管理工
第1篇介绍了版本控制工具的演变历史、git的各种优点,以及它在3种主流操作系统中的安装与配置。第2篇和第3篇既是本书的基础,又是本书的核心,不仅介绍了git的操作和使用,而且还讲解了git的原理。第2篇详细讲解了...
接下来,你可以继续学习 Git 如何存储对象、Git 的对象模型是怎样的、打包文件的细节、服务器协 议等更多知识。 本书自始至终都将引用本章的内容,以便你能够在当时就可以深入了解。但是,如果你像我们 一样希望深入...
第1篇介绍了版本控制工具的演变历史、git的各种优点,以及它在3种主流操作系统中的安装与配置。第2篇和第3篇既是本书的基础,又是本书的核心,不仅介绍了git的操作和使用,而且还讲解了git的原理。第2篇详细讲解了...
3. Git 的分支模型 4. 服务器端的 Git 5. 多种分布式工作流的细节,以及如何使用 Git 实现它们 6. 介绍 GitHub 托管服务以及深层次的工具 7. 关于 Git 的高级命令 8. 关于 Git 环境的自定义配置,包括设置用于增强或...
客户端,服务端采用websocket链接,避免poll 支持使用git作为配置版本管理 支持git branch,tag, commitId作为获取配置条件 支持仓库路由 支持动态仓库配置,参见"仓库模型
- 工具:IDEA、Navicat、Git - 环境:JDK 1.8、Tomcat 9.0、Mysql 5.0 - 项目管理: - ## 开发流程: 1、数据库设计 2、Model:模型定义,与数据库相匹配 3、Dao层:数据操作 4、Service:服务包装 5、...
本项目是一个基于Python语言开发的科大讯飞130亿参数认知大模型iFlytekSpark-13B,包含324个文件,主要文件类型包括Python源代码、Shell脚本、JSON配置文件、Markdown文档、文本文件、C++源代码、C源代码、HTML页面...
它是居于Spring容器之上,封装了DAO(含Hibernate和MongoDB)操作、多模块统一管理、统一配置管理、统一日志管理等优雅的工程管理开发模型,并提供大量工具包、Json操作、分页辅助工具。 开发工具在软件开发生命...
支持使用git作为配置版本管理 支持git branch,tag, commitId作为获取配置条件 支持仓库路由 支持动态仓库配置,参见"仓库模型" 支持按需推送配置更新 *计划支持 提供webhook api *计划支持 可在浏览器页面直接修改...
通过集成Git、SVN等版本控制系统,支持团队成员间的代码共享、分支管理、合并请求和冲突解决。 可视化设计与原型制作: 对于UI/UX设计,有界面设计工具,如Sketch、Adobe XD,可以帮助设计师快速构建应用程序...
2、 后台系统设置:导航栏目、分类管理、 OAuth设置 、支付设置、扩展字段 、频道管理、模型管理、站点基本信息等功能设置 3、 订单管理:在线购物订单查看、发货、确认 4、 产品管理:分类管理 、产品管理 、 积分...
工具:IDEA、Navicat、Git 环境:JDK 1.8、Tomcat 7.0、Mysql 8.0 项目管理:Maven 代码托管平台:GitHub 开发流程: 1、数据库设计 2、Model:模型定义,与数据库相匹配 3、Dao层:数据操作 4、Service:...
mitgcm_python软件包是用于在MITgcm中构造模型设置的工具包。 在BAS HPC上,我首先导航到Expose驱动器上的合适目录。 接下来,我克隆了MITgcm和mitgcm_python的新副本: git clone https://github.com/mitgcm/mitgcm...
NETCONF 协议之 netopeer 软件安装 NETCONF 协议是一种基于...NETCONF 协议之 netopeer 软件安装是一个相对复杂的过程,但通过遵循上述步骤,我们可以成功安装 netopeer 软件,并使用它来自动化我们的网络配置和管理。
2、 后台系统设置:导航栏目、分类管理、 OAuth设置 、支付设置、扩展字段 、频道管理、模型管理、站点基本信息等功能设置 3、 订单管理:在线购物订单查看、发货、确认 4、 产品管理:分类管理 、产品管理 、 ...
2、 后台系统设置:导航栏目、分类管理、 OAuth设置 、支付设置、扩展字段 、频道管理、模型管理、站点基本信息等功能设置 3、 订单管理:在线购物订单查看、发货、确认 4、 产品管理:分类管理 、产品管理 、 ...
Cloud为开发人员提供了丰富的使用工具,开发人员基于这些工具可以快速构建分布式系统中的一些常见功能(例如,配置管理,服务发现,断路器,智能路由,微代理,控制总线,一次性令牌,全局锁,领导选举,分布式会话...