【Git之窗】(五)Git分支管理的一个实例
2017-03-01 21:44
375 查看
上一篇博客中介绍了Git分支管理的基础概念,这篇博客模拟一个实际场景来分析下为什么要提倡要“频繁”地使用Git分支。
-------------------------------------------
人物:
一名姓“程”,名“序员”的单身程序员,29岁,黑框眼镜、格子衫、牛仔裤、运动鞋、双肩包……
------------------------------------------
场景:
1、开发某“**云平台”项目。
2、为了实现某个新的需求,创建一个分支“iss53”。
3、在这个分支上继续展开工作,并且执行了一次commit操作,此时"iss53"分支已经指到了C3版本的快照上。
之后,“序员”仍然在继续工作……
---------------------------------------------------------------
突发情况:
“序员”突然接到一个电话说线上版本有个很严重的bug需要紧急修补,前提是生产服务器上的程序已经发版,此时你该怎么办?要知道,此时你已经在上线的版本上写了一些新的功能,但是没有测试,你会怎么办?
---------------------------------------------------------------
我的解决方案:
(1)Git方案
1、提交iss53上对新需求开发的版本, 之后checkout到master分支上面,这个时候我的工作目录中的内容已经和线上那个版本的代码一模一样了
2、我在master的基础上,新建“hotfix”分支,此时hotfix分支指向了C4版本的代码:
紧接着,在hotfix分支上修改这个线上的bug,此时序员已经加班到了凌晨1点钟……
突然间,bug消失了,紧接着测试也通过了,太爽了!
3、通过“git rebase”或者“git merge”命令,把hotfix分支合并到master分支上面,如图:
4、此时可以通过命令“git branch -d hotfix”删除掉hotfix分支了,并且通过"git checkout iss53"命令切换到了iss53分支,继续新需求的开发工作,如图:
如果想要把解决线上bug的修复代码也同步到"iss53"上面,执行“git rebase master”,此时的“iss53”分支已经是兼具“解决了线上bug”同时“在开发新功能”的一个分支了。
(2)SVN方案
由于已经写了一部分新需求的代码,首先通过“与资源库同步”按钮,找到最近在每一层、每一个模块里修改过的代码,做好备份后,“还原”到之前的代码版本,此时与线上发版的代码一模一样了,之后解决bug、测试、打包、发版。
紧接着,将之前做修改的那部分代码提取出来,再copy到当前工作目录当中,测试、打包、发版。
比较针对这个突发问题的解决,很显然Git的使用要优于SVN的解决方案,所以,建议使用前者。
-------------------------------------------
人物:
一名姓“程”,名“序员”的单身程序员,29岁,黑框眼镜、格子衫、牛仔裤、运动鞋、双肩包……
------------------------------------------
场景:
1、开发某“**云平台”项目。
2、为了实现某个新的需求,创建一个分支“iss53”。
3、在这个分支上继续展开工作,并且执行了一次commit操作,此时"iss53"分支已经指到了C3版本的快照上。
之后,“序员”仍然在继续工作……
---------------------------------------------------------------
突发情况:
“序员”突然接到一个电话说线上版本有个很严重的bug需要紧急修补,前提是生产服务器上的程序已经发版,此时你该怎么办?要知道,此时你已经在上线的版本上写了一些新的功能,但是没有测试,你会怎么办?
---------------------------------------------------------------
我的解决方案:
(1)Git方案
1、提交iss53上对新需求开发的版本, 之后checkout到master分支上面,这个时候我的工作目录中的内容已经和线上那个版本的代码一模一样了
2、我在master的基础上,新建“hotfix”分支,此时hotfix分支指向了C4版本的代码:
紧接着,在hotfix分支上修改这个线上的bug,此时序员已经加班到了凌晨1点钟……
突然间,bug消失了,紧接着测试也通过了,太爽了!
3、通过“git rebase”或者“git merge”命令,把hotfix分支合并到master分支上面,如图:
4、此时可以通过命令“git branch -d hotfix”删除掉hotfix分支了,并且通过"git checkout iss53"命令切换到了iss53分支,继续新需求的开发工作,如图:
如果想要把解决线上bug的修复代码也同步到"iss53"上面,执行“git rebase master”,此时的“iss53”分支已经是兼具“解决了线上bug”同时“在开发新功能”的一个分支了。
(2)SVN方案
由于已经写了一部分新需求的代码,首先通过“与资源库同步”按钮,找到最近在每一层、每一个模块里修改过的代码,做好备份后,“还原”到之前的代码版本,此时与线上发版的代码一模一样了,之后解决bug、测试、打包、发版。
紧接着,将之前做修改的那部分代码提取出来,再copy到当前工作目录当中,测试、打包、发版。
比较针对这个突发问题的解决,很显然Git的使用要优于SVN的解决方案,所以,建议使用前者。
相关文章推荐
- 【Git之窗】(四)Git分支管理
- git是一种分布式代码管理工具,git通过树的形式记录文件的更改历史,比如: base'<--base<--A<--A' ^ | --- B<--B' 小米工程师常常需要寻找两个分支最近的分割点,即base.假设git 树是多叉树,请实现一个算法,计算git树上任意两点的最近分割点。 (假设git树节点数为n,用邻接矩阵的形式表示git树:字符串数组matrix包含n个字符串,每个字符串由字符'0
- Git工作区储藏兼谈分支管理中的一个小问题
- 阮一峰:Git分支管理策略
- git使用笔记3--分支合并与管理
- 我也说Git分支管理
- GIT分支管理是一门艺术
- 管理一个ORACLE实例
- git 分支管理
- SVN管理的项目工程创建一个分支
- GIT分支管理是一门艺术
- GIT分支管理是一门艺术
- 一个JBPM工作流管理实例
- Git 创建管理分支
- 一个成功的Git分支模型
- git-分支管理
- git学习笔记(一):创建和管理远程分支
- 管理一个ORACLE实例
- Git 管理多个分支的公共部分 How to manage the common part of multiple branches
- git创建与管理远程分支