git merge 与 rebase 的使用场景分析
来源:互联网 发布:mac图片压缩软件 编辑:程序博客网 时间:2024/06/05 02:07
几乎所有的版本控制工具都有branch功能,branch主要用于以下几个场景:
1,控制产品OEM。
基本上做产品,不同的客户都会提出多种不同特性需求,最简单的例子就是LOGO和标题完全不一样。但是可能产品自身的大部分功能和模块的代码一样的,这个时候如何管理多个客户定制的功能特性,并且不会干扰其他OEM版本的功能呢?
如果你一开始就用if加N多变量定义的话,早晚会累死你,如果你把代码拷贝很多份,每多一个新的OEM就多拷贝一份代码,那如果发现公用模块里面有个BUG,难道你要每个版本的源代码都要修改?万一改错地方了,或者哪个版本的忘记改了,又是一件麻烦事。
这个时候我们就可以考虑使用branch功能,在第一个OEM的基础上分支出第二个OEM,第三个OEM完全取决于和哪个版本更像,就在那个版本的基础上做新的分支,有新的OEM特性需求,就切换到那个分支上修改,放心,所有的的单独分支上的代码看起来都是独立的,不会影响其他版本。
2,多人协作长时间开发功能模块
如果你在一个团队中,那几乎很难做到每天都能按期完成某个模块功能,并且测试通过。那团队成员又必须每日下班前把自己的代码保存一下,万一机器故障了之类的还能有代码备份机制。如果提交了不能工作的代码,别人又获取到了,那其他人的事情就做不下去了。所以,branch另外一个适用场景就是为team单独成员开辟个人工作区域,单元测试无误之后再把成员的工作代码合并到主分支中,既能达到个人代码备份的目的,又能不影响其他人的工作。
其实上面所说的就是rebase和merge的不同适用场景。
在场景1的情况下,如果修改了某个公用代码的BUG,这个时候就应该是把所有的OEM版本分支rebase到这个修复BUG的分支上来,在rebase过程中,Git会要你手动解决代码上的冲突,你需要做的就是把修复BUG的代码放到目标分支代码里面去。rebase的结果是:所有的分支依然存在
在场景2的情况下,因为成员的代码开发工作已经完成了,也不需要再保留这个分支了,所以我们可以把这个成员分支merge到主分支上,当然冲突在所难免,手工解决的工作肯定逃不掉,但是利大于弊不是吗。merge以后,分支就不存在了,但是在Git的所有分支历史中还能看到身影。
根据适用场景不同,采用不同的分支合并策略,让你团队的代码保持生命力吧。
- git merge 与 rebase 的使用场景分析
- 图解git rebase 与merge的区别
- git rebase 与git merge
- git rebase 与 git merge
- git merge与rebase 区别
- Git merge 与 rebase 区别
- git fetch /rebase /merge 使用
- git fetch /rebase /merge 使用
- 闲话git merge 与 git rebase 的区别
- git rebase与git merge区别
- git rebase与git merge区别
- git merge与git rebase小议
- 一语道破git merge与git rebase
- Git Rebase 操作的分析与整理
- 'git merge' 和 'git rebase'的区别?
- git merge和git rebase的区别
- git merge和git rebase的区别
- 更好的理解git rebase git merge
- 基础篇:6.3)形位公差-基准 Datum
- PullToRefreshListView刷新
- 算法 插入排序 的 JS实现及时间复杂度分析
- hadoop安全模式
- SpringBoot 数据库增删改查实例
- git merge 与 rebase 的使用场景分析
- 2006年培养学员8万人,每年增长%25,请问按此增长速度,到那一年培训学员人数将达到20万人用for,while,dowhile,实现
- 用http_build_query()函数在curl处理post请求参数
- 开始前端——第一篇
- 如何从 MongoDB 迁移到 MySQL
- 毕业论文查重是一个怎样的过程?
- Ubuntu 16.04 Graylog2日志服务安装教程
- 常用排序方式总结
- 通知栏