如何选择版本控制系统之二---Git的研发应用场景

之前写了一篇《如何选择版本控制系统 ---为什么选择Git版本控制系统》,地址是:http://laoyudage.blog.51cto.com/12854334/1927409,有兴趣的可以去看看,本篇文章算是这个系列的第二篇文章。

Git诞生于2002年,由Linux之父Linus Torvalds和他的团队开发并不断完善,它秉承了Linux的开源精神,为广大研发团队带来了非常棒的版本控制体验。本文立足Git的工作原理,深入探讨各种研发场景中工作流等问题。

Git工作模式

代码提交过程

一次修改被成功提交到远端仓库会历经四个阶段,1本地工作区->2缓存区->3版本库->4远端版本库,通过执行相应的Git命令,文件在这四个区域跳转,并呈现不同的状态:

1.已修改(modified):包括三种文件,新增文件,被修改的文件,被删除的文件

2.已暂存(staged):对已修改的文件执行git add或git rm操作,文件就变成已暂存状态,进入暂存区。暂存区实际上就是一个文件索引目录树,记录了所有文件名、文件状态信息,它已索引的方式建立了文件名和文件内容(在对象库.git/objects中保存)的对应关系。

3.已提交(committed):对已暂存的文件执行git commit操作,文件就变成已提交状态,进入本地版本仓库。

4.已上传:对已提交的文件执行git push操作,文件就变成已上传状态,进入远端版本仓库。

Git如何记录每次提交

我们思考一下,版本控制系统应该如何记录每次提交呢?正常的思维肯定是记录“差异”(delta),也就是前后两个版本中文件内容的不同,确实大多数版本控制系统是这么做的,比如我们所熟悉的CVS,SVN。但是,Git却不这样!每次提交更新时,Git会对全部文件作一个快照(snapshot),并保存指向这次快照的索引。

这种保存方式带来很多好处,切换版本时,直接引用指向目标版本的索引即可,不需要像差异存储那样,需要版本之间的merge,速度会快很多,更重要的是,为后文所讲到的轻量级分支切换提供了前提条件。

Git分支

Git新建分支的本质就是创建一个指向最后一次提交的可变指针,所以,Git分支的创建不是复制版本库的内容,仅仅是新建了一个指针,它以40个字符长度SHA-1字串形式保存在文件中,这难以想象的轻量级就是源于“快照”保存的版本设计理念。

Git工作流

什么是Git工作流?你可以理解为代码管理的分支策略。这里从典型的GitFlow工作流出发,配合我正在使用的代码托管平台(华为软件开发云),给大家详细讲解工作流是如何服务于项目流程管理和团队协同开发。

master:主线分支,版本有较强稳定性,供生产环境部署使用,这个分支只能从其它分支合并,不能在这个分支上直接提交修改。

新建分支:

在开发云界面输入新分支名,并选择从哪个分支检出即可。

develop:主开发分支,用来集成测试最新合入的开发成果,包含要发布到下一个Release的代码。

feature:特性分支,每个特性一个分支,用于开发人员提交代码并进行自测。一旦开发完成,我们合并回Develop分支进入下一个Release。

hotfix:补丁分支,生产环境发现新Bug时创建的临时分支,问题验证后,合并到Master和Develop分支,所以Hotfix的改动会进入下一个Release

release:发布分支,发布新版本时,基于Develop分支创建,发布完成后,合并到master和develop分支。

各个分支之间的关系可以从开发云的“仓库网络”中查看:

优点:项目管理流程明确

缺点:相对复杂,需要同时维护两个长期分支,不适合网站项目。

分支合并

无论哪种工作流都会涉及到分支合并(把一个分支中的修改整合到当前分支),主要有两种方法:三方合并(merge)和衍合(rebase)。我们通过对同一种场景进行不同操作体会两种合并方法的区别。

场景:master分支新增了C4节点,hotfix分支新增了C3节点,现将hotfix分支合并到master分支:

1.三方包括hotfix新增节点C3,master新增节点C4,以及两者的共同祖先节点C2。这种合并操作简单,但新增合并节点C5,形成了环形,版本记录可读性差。

a)PC端命令操作方式:

#git checkout master

#git merge hotfix

b)开发云平台页面操作:

第一步:

第二步:

2.衍合先将master分支新增节点C4以补丁形式保存在.git/rebase目录中,然后同步hotfix分支最新代码,再应用补丁C4’。

#git checkout master

#git rebase hotfix

冲突解决

类型一:两个合并分支修改了同一行代码

解决方法:

1.分析哪种修改方法正确,手动合并;

2.提交修改。

类型二:文件被重命名为不同的名字

解决方法:

1.确认哪个名字是正确的,删除错误的;

2.提交修改。

结语

根据实际研发场景制定合理的工作流,能有效提高项目管理水平和团队协同开发能力,而这些分支操作,对于不习惯使用命令的人来说,可以在PC端下载使用图形化工具tortoisegit,也可以在代码托管平台华为软件开发云(https://www.hwclouds.com/devcloud/)配置管理服务使用页面操作。下篇文章会详细讲解代码托管平台可视化操作方法。

时间: 2024-10-05 04:55:03

如何选择版本控制系统之二---Git的研发应用场景的相关文章

如何选择版本控制系统之二---Git的研发应用场

之前写了一篇<如何选择版本控制系统 ---为什么选择Git版本控制系统>,地址是:http://www.cnblogs.com/goldenfish/p/6876864.html,有兴趣的可以去看看,本篇文章算是这个系列的第二篇文章. Git诞生于2002年,由Linux之父Linus Torvalds和他的团队开发并不断完善,它秉承了Linux的开源精神,为广大研发团队带来了非常棒的版本控制体验.本文立足Git的工作原理,深入探讨各种研发场景中工作流等问题. Git工作模式 代码提交过程 一

如何选择版本控制系统之二

之前写了一篇<如何选择版本控制系统 ---为什么选择Git版本控制系统>,地址是:http://www.cnblogs.com/goldenfish/p/6876864.html,有兴趣的可以去看看,本篇文章算是这个系列的第二篇文章. Git诞生于2002年,由Linux之父Linus Torvalds和他的团队开发并不断完善,它秉承了Linux的开源精神,为广大研发团队带来了非常棒的版本控制体验.本文立足Git的工作原理,深入探讨各种研发场景中工作流等问题. Git工作模式 代码提交过程 一

如何选择版本控制系统之三

往期文章: <如何选择版本控制系统 ---为什么选择Git版本控制系统> <如何选择版本控制系统之二---Git的研发应用场景> 跨地域开发的需求其实由来已久,并在IT/互联网高速发展的今天越来越普遍,这正是Git版本管理广泛流程的技术原因之一.对于一个开发者如何将本地代码提交到中央仓库,是保证高效异地协同的前提.本文将着重介绍将本地代码提交到托管平台的基本操作. 客户端工具:SourceTree 托管平台:华为软件开发云 如何将本体代码提交到托管平台 1.本地git工具安装&am

如何选择版本控制系统之三---代码托管操作

往期文章: <如何选择版本控制系统 ---为什么选择Git版本控制系统> <如何选择版本控制系统之二---Git的研发应用场景> 跨地域开发的需求其实由来已久,并在IT/互联网高速发展的今天越来越普遍,这正是Git版本管理广泛流程的技术原因之一.对于一个开发者如何将本地代码提交到中央仓库,是保证高效异地协同的前提.本文将着重介绍将本地代码提交到托管平台的基本操作. 客户端工具:SourceTree 托管平台:华为软件开发云 如何将本体代码提交到托管平台 1.本地git工具安装&am

如何选择版本控制系统 ---为什么选择Git版本控制系统

版本控制系统 "代码"作为软件研发的核心产物,在整个开发周期都在递增,不断合入新需求以及解决bug的新patch,这就需要有一款系统,能够存储.追踪文件的修改历史,记录多个版本的开发和维护.于是,版本控制系统(Version Control Systems)应运而生,主要分为两类,集中式和分布式. 集中式版本控制系统 集中式版本控制系统的特点是只有一台中央服务器,存放着所有研发数据,而其它客户端机器上保存的是中央服务器最新版本的文件快照,不包括项目文件的变更历史.所以,每个相关人员工作

如何选择版本控制系统

版本控制系统 "代码"作为软件研发的核心产物,在整个开发周期都在递增,不断合入新需求以及解决bug的新patch,这就需要有一款系统,能够存储.追踪文件的修改历史,记录多个版本的开发和维护.于是,版本控制系统(Version Control Systems)应运而生,主要分为两类,集中式和分布式. 集中式版本控制系统 集中式版本控制系统的特点是只有一台中央服务器,存放着所有研发数据,而其它客户端机器上保存的是中央服务器最新版本的文件快照,不包括项目文件的变更历史.所以,每个相关人员工作

GIT分布式版本控制系统使用教程

版本控制工具大概有: RCS单机版 CVS.SVN集中式版本控制系统 GIT分布式版本控制系统 这里介绍GIT,它四大位置:本地代码工作区---待提交列表staging area---本地仓库local repo---远程仓库remote repo(git服务器).从左往右是上传代码,从右往左是下载代码. 备注1:git比svn多了待提交列表. 备注2:最好本地一个分支.远程一个分支,没有必要搞多个分支,只有每个人合并的时候就要花很多时间. 备注3:帮git当作高级svn来用. 备注4:更改服务

iOS - Git 分支(分布式版本控制系统)

前言 几乎所有的版本控制系统都以某种形式支持分支.使用分支意味着你可以把你的工作从开发主线上分离开来,以免影响开发主线.在很多版本控制系统中,这是一个略微低效的过程--常常需要完全创建一个源代码目录的副本.对于大项目来说,这样的过程会耗费很多时间. 有人把 Git 的分支模型称为它的"必杀技特性",也正因为这一特性,使得 Git 从众多版本控制系统中脱颖而出.为何 Git 的分支模型如此出众呢?Git 处理分支的方式可谓是难以置信的轻量,创建新分支这一操作几乎能在瞬间完成,并且在不同分

版本控制系统Git介绍与部署

一.Git的简介 Git是一个开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目.Git是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源代码的版本控制软件.Git与常用的版本控制工具CVS.Subversion等不同,它采用了分布式版本库的方式,不必服务器端软件支持. 二.Git的诞生 Linus在1991年创建了开源的linux,从此,Linux系统不断发展,已经成为最大的服务器系统软件了.Linus虽然创建了Linux,但Linux的壮大是靠全世界热