您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
     
   
 订阅
  捐助
Git分布式版本管理详解
 
304 次浏览     评价:  
 2018-10-8 
 
编辑推荐:

本文来自csdn,本文主要详细描述了Git分布式,Git分支和工作流程,希望对大家有帮助。

Git分布式版本管理使用详情

1. Git的诞生

2. Svn集中式 <-VS-> Git分布式

3. Git分支介绍

4. Git分支之工作流程

1. 最早诞生的工作流程Git flow

功能分支(feature branch):

预发分支(release branch):

补丁分支(hotfix branch):

2. Github flow:

3. Gitlab flow:5. Git分支之工作技巧

干活之前:

Pull Request

Protected branch

issue

merge节点

1. Git的诞生

Linus创建了Linux,Linux的壮大是靠全世界热心的志愿者参与的。世界各地的志愿者把源代码文件通过diff的方式发给Linus,然后由Linus本人通过手工方式合并代码!

时间到了2002年,Linux系统已经发展了十年,代码库之大让Linus很难继续通过手工方式管理了,社区的弟兄们也对这种方式表达了强烈不满,于是Linus选择了一个商业的版本控制系统BitKeeper,BitKeeper的东家BitMover公司出于人道主义精神,授权Linux社区免费使用这个版本控制系统。

安定团结的大好局面在2005年就被打破了,原因是Linux社区牛人聚集,不免沾染了一些梁山好汉的江湖习气。开发Samba的Andrew试图破解BitKeeper的协议(这么干的其实也不只他一个),被BitMover公司发现了(监控工作做得不错),于是BitMover公司怒了,要收回Linux社区的免费使用权。

Linus可以向BitMover公司道个歉,保证以后严格管教弟兄们。但,这是不可能的。实际情况是这样的:

Linus花了两周时间自己用C写了一个分布式版本控制系统,这就是Git诞生!一个月之内,Linux系统的源码已经由Git管理了!大家可以体会一下,牛是怎么定义的!

Git迅速成为最流行的分布式版本控制系统。尤其是2008年,GitHub网站上线。它为开源项目免费提供Git存储,无数开源项目开始迁移至GitHub,包括jQuery,PHP,Ruby等等。

2. Svn集中式 <-VS-> Git分布式

集中式版本控制系统:版本库是集中存放在中央服务器的,而干活的时候,用的都是自己的电脑。所以要先从中央服务器取得最新的版本,然后开始干活,干完活了,再把自己的活推送给中央服务器。中央服务器比作一个图书馆,你要改一本书,必须先从图书馆借出来,然后回到家自己改,改完了,再放回图书馆。

分布式版本控制系统:没有“中央服务器”,每个人的电脑上都是一个完整的版本库,这样工作的时候,就不需要联网了,因为版本库就在电脑上。

既然每台电脑上都有一个完整的版本库,那多个人如何协作呢?

比方说你在自己电脑上改了文件A,你的同事在他的电脑上改了文件A。你们俩之间只需要把各自的修改推送给对方,就可以互相看到对方的修改了。

实际使用分布式版本控制系统的时候,很少在两台电脑之间推送版本库的修改。因为可能两台电脑之间不能互相访问,也可能其中一台电脑压根就没有开机。因此,分布式版本控制系统通常也有一台充当“中央服务器”的电脑,这个服务器的作用仅仅是用来方便“交换”大家的修改。没有它大家也一样干活,只是交换修改不方便而已。

集中式版本控制系统的中央服务器要是出了问题,所有人都没法干活了。

分布式版本控制系统的每台电脑里都有完整的版本库,某台电脑坏掉了不要紧,从其他电脑里复制一份就可以。因此,代码安全性要高很多。

Git的优势是拥有极其强大的分支管理,把Svn等远远抛在了身后。

3. Git分支介绍

每次提交代码,Git都会生成支点,它们串成一条时间线,这条时间线就是一个分支。

每次提交,master分支都会向前移动一步。随着你不断提交,master分支的线也越来越长。目前只有一条时间线,在Git里,这个分支叫主分支。

创建新的分支:

例如dev时,Git新建一个指针叫dev,指向master相同的提交,再把HEAD指向dev,就表示当前分支在dev上。

重点:HEAD指向的就是当前正在使用的分支!

创建好dev分支开始,对工作区的修改和提交就是针对dev分支了。比如新提交一次后,dev指针往前移动一步,而master指针不变。

假如在dev上的工作完成了,就可以把dev合并到master上。最简单的方法,就是直接把master指向dev的当前提交,就完成了合并。

合并分支完成后,如果dev分支不在使用,可以直接删除dev分支。删除dev分支就是把dev指针给删掉,就剩下了一条master分支。

4. Git分支之工作流程

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

三种广泛使用的工作流程:

1.Git flow

2.Github flow

3.Gitlab flow

三种工作流程,有一个共同点,都采用“功能驱动式开发”(Feature-driven development,简称FDD)。

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

1. 最早诞生的工作流程Git flow

项目存在二个长期分支:

- 主分支(master)

- 开发分支(develop)

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

项目存在三种短期分支:

1.功能分支(feature branch)

2.预发分支(release branch)

3.补丁分支(hotfix branch)

这三种分支都属于临时性需要,使用完以后,应该删除,使得代码库的常设分支始终只有master和develop。

功能分支(feature branch):

它是为了开发某种特定功能,从develop分支上面分出来的。开发完成后,要再并入develop分支。它的命名,可以采用feature-*的形式。

预发分支(release branch):

它是指发布正式版本之前(即合并到master分支之前),需要有一个预发布的版本进行测试。预发布分支是从develop分支上面分出来的,预发布结束以后,必须合并进develop和master分支。它的命名,可以采用release-*的形式。

补丁分支(hotfix branch):

软件正式发布以后,难免会出现bug。这时就需要创建一个分支,进行bug修补。修补bug分支是从master分支上面分出来的。修补结束以后,再合并进master和develop分支。它的命名,可以采用fixbug-*的形式。

Git flow总结:

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

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

2. Github flow:

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

它只有一个长期分支master,因此用起来非常简单。操作步骤:

1、根据需求,从master拉出新分支,不区分功能分支或补丁分支。

2、新分支开发完成,有需要讨论的时候,就向master发起一个Pull Request(简称PR)。

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

4、PR被接受时,合并进master,重新部署。把新拉出来的那个分支删除。

Githubdevelopflow总结:

优点就是简单,对于“持续发布”的产品是最合适的流程。

它的问题在于假设要成立。master分支的更新与产品的发布是一致的。保证master分支的最新代码就是当前线上的代码。

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

3. Gitlab flow:

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

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

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

1、持续发布:

它建议在master分支以外,建立不同的环境分支。“开发环境”的分支是master,“预发环境”的分支是pre-production,“生产环境”的分支是production。

开发分支是预发分支的“上游”,预发分支是生产分支的“上游”。代码的变化,必须由“上游”向“下游”发展。例如,生产环境出现bug,新建一个功能分支修正bug,先把它合并到master,确认没有问题。再cherry-pick到pre-production,确认没有问题。才能进入production。

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

2、版本发布:

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

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

Gitlab flow总结:

优点是很多公司都使用这种工作流程。

5. Git分支之工作技巧

干活之前:

首先,每次开发新功能,都应该新建一个单独的分支。

Pull Request

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

Pull Request本质是一种对话机制,可以在提交的时候@相关人员或团队,引起他们的注意。及时的查看提交的内容。

Protected branch

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

Github.com 和 Gitlab.com 都提供“保护分支”(Protected branch)这个功能。

issue

GitHub.com 的issue 功能就如同TODO list。想要在下一步完成的工作,如feature添加、bug修改等,都写成一个个的issue。放在上面,可以作为提醒,可以统一管理。

开发完成后,在提交说明里面,可以选择性的与某个issue关联。比如在message中添加#n,就可以与第n个issue进行关联。

commit message title, #1

只要commit message里面有下面这些动词 + 编号,就会关闭对应的issue。

- close #n
- closes #n
- closed #n
- fix #n
- fixes #n
- fixed #n
- resolve #n
- resolves #n
- resolved #n
`commit message title, fix #n`

 

merge节点

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

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

 

   
304 次浏览  评价: 差  订阅 捐助
相关文章

每日构建解决方案
如何制定有效的配置管理流程
配置管理主要活动及实现方法
构建管理入门
相关文档

配置管理流程
配置管理白皮书
CM09_C配置管理标准
使用SVN进行版本控制
相关课程

配置管理实践
配置管理方法、工具与应用
多层次集成配置管理
产品发布管理
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号