git 入门教程之分支策略
默认情况下合并分支常常直接使用 git merge
命令,是最方便快速的合并方法.其实这种情况下 git
采用的是 fast forward
模式,特点是删除分支后,会丢失分支信息,好像从来没存在该分支一样,而我们推荐的是recursive
模式,能够保留分支的版本记录.
递归模式(recursive
)
创建并切换 dev
分支,提交版本后切换回 master
分支,然后再合并 dev
分支,这不过这一次不再使用 git merge dev
命令:
# 创建并切换 dev 分支 $ git checkout -b dev Switched to a new branch 'dev' # 提交版本 $ echo "git checkout -b dev" >> test.txt $ git add test.txt $ git commit -m "git checkout -b dev" [dev 44d68f6] git checkout -b dev 1 file changed, 1 insertion(+) # 切换回 master 分支 $ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits. (use "git push" to publish your local commits) $
现在添加 --no-ff
参数禁用 fast forward
模式,即git merge --no-ff
:
$ git merge --no-ff -m "git merge --no-ff dev" dev Merge made by the 'recursive' strategy. test.txt | 1 + 1 file changed, 1 insertion(+) $
上述内容显示,这次使用的不再是 fast forward
模式,而是 recursive
模式,那让我们看一下提交历史有什么不同吧!
$ git log --pretty=oneline --graph * 22fbef7 (HEAD -> master) git merge --no-ff dev |\ | * 44d68f6(dev) git checkout -b dev |/ * 3b8f434 fix conflict |\ | * 0fe95f8 git commit c2 * | 0949cc3 git commit c3 |/ * 5c482cd git commit c1 * 413a4d1 see https://snowdreams1006.github.io/git/usage/branch-overview.html * 9c30e51 learn git branch * b3d8193 (origin/master, origin/HEAD) see https://snowdreams1006.github.io/git/usage/remote-repository.html * 8e62564 add test.txt * 9b196aa Initial commit $
这种递归模式(recursive
) 有一个明显的特点就是会产生一个新的 commit
,并不会像之前快速前进模式(fast forward
)那样单纯更改 HEAD
的指向.
秉承着阅后即焚的习惯,分支一旦合并后就立即删除,现在删除 dev
分支,看一下会发生什么:
# 删除 dev 分支 $ git branch -d dev Deleted branch dev (was 44d68f6). # 查看提交历史 $ git log --pretty=oneline --graph * 22fbef7 (HEAD -> master) git merge --no-ff dev |\ | * 44d68f6 git checkout -b dev |/ * 3b8f434 fix conflict |\ | * 0fe95f8 git commit c2 * | 0949cc3 git commit c3 |/ * 5c482cd git commit c1 * 413a4d1 see https://snowdreams1006.github.io/git/usage/branch-overview.html * 9c30e50 learn git branch * b3d8193 (origin/master, origin/HEAD) see https://snowdreams1006.github.io/git/usage/remote-repository.html * 8e62564 add test.txt * 9b196aa Initial commit $
由此可见,删除 dev
分支后仅仅少了 dev
的引用而已,原来 dev
分支所做的更改全部保留下来了!
快速前进模式(fast forward
)
创建并切换 dev
分支,提交版本后切换回 master
分支,然后再合并 dev
分支,使用 git merge dev
命令:
# 创建并切换 dev 分支 $ git checkout -b dev Switched to a new branch 'dev' # 提交版本 $ echo "fast forward" >> test.txt $ git add test.txt $ git commit -m "fast forward" [dev 3fe94c0] fast forward 1 file changed, 1 insertion(+) $
现在切换回 master
分支,采用默认的git merge
命令合并 dev
分支:
$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 8 commits. (use "git push" to publish your local commits) sunpodeMacBook-Pro:git-demo sunpo$ git merge dev Updating 22fbef7..3fe94c0 Fast-forward test.txt | 1 + 1 file changed, 1 insertion(+) $
上述内容显示这次合并采用的是快速前进模式(fast forward
),让我们看一下提交历史:
$ git log --pretty=oneline --graph * 3fe94c0 (HEAD -> master, dev) fast forward * 22fbef7 git merge --no-ff dev |\ | * 44d68f6 git checkout -b dev |/ * 3b8f434 fix conflict |\ | * 0fe95f8 git commit c2 * | 0949cc3 git commit c3 |/ * 5c482cd git commit c1 * 413a4d1 see https://snowdreams1006.github.io/git/usage/branch-overview.html * 9c30e50 learn git branch * b3d8193 (origin/master, origin/HEAD) see https://snowdreams1006.github.io/git/usage/remote-repository.html * 8e62564 add test.txt * 9b196aa Initial commit $
上述内容表明,此次合并并没有产生新的 commit
,只是更改下 HEAD
指向而已(HEAD -> master, dev
).
同样,现在删除 dev
分支,再看一下提交历史:
# 删除 dev 分支 $ git branch -d dev Deleted branch dev (was 3fe94c0). # 查看提交历史 $ git log --pretty=oneline --graph * 3fe94c0 (HEAD -> master) fast forward * 22fbef7 git merge --no-ff dev |\ | * 44d68f6 git checkout -b dev |/ * 3b8f434 fix conflict |\ | * 0fe95f8 git commit c2 * | 0949cc3 git commit c3 |/ * 5c482cd git commit c1 * 413a4d1 see https://snowdreams1006.github.io/git/usage/branch-overview.html * 9c30e50 learn git branch * b3d8193 (origin/master, origin/HEAD) see https://snowdreams1006.github.io/git/usage/remote-repository.html * 8e62564 add test.txt * 9b196aa Initial commit $
由此可见,快速前进模式一旦删除分支后就彻底丢失了分支的信息,即便是从提交历史中也找不到曾经存在的痕迹!
分支策略
git
是分布式版本控制系统,同时鼓励大量使用分支,如此一来大量的分支该如何管理? 实际开发中,建议准从以下原则进行分支管理:
master
分支作为主干分支,负责对外提供服务,要求稳定可靠,因为应该专人负责更新维护.dev
分支作为开发分支,取代master
分支的开发地位,积累到一定产出时再合并到master
分支.feature
分支作为新功能分支,根据实际情况动态创建,删除分支,并适时合并到dev
分支.bugFixed
分支作为修复特定 bug 分支,可能由master
分支衍生而来,也可能由dev
分支衍生等等,修复后及时合并到原分支.custom
自定义分支,项目成员私有分支,由上级领导分配任务后各开发人员自行选择创建自己的分支,并根据实际情况决定合并到dev
分支或feature
等分支.
小结
- 快速前进模式(
git merge <name>
)不保留分支合并历史,递归模式(git merge --no-ff -m <remark> <name>
)保留分支合并历史. - 制定大家都认同的分支管理原则,并严格准守规则.
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
从源码的角度解析Mybatis的会话机制
微信公众号「后端进阶」,专注后端技术分享:Java、Golang、WEB框架、分布式中间件、服务治理等等。 老司机倾囊相授,带你一路进阶,来不及解释了快上车! 坐在我旁边的钟同学听说我精通Mybatis源码(我就想不通,是谁透漏了风声),就顺带问了我一个问题:在同一个方法中,Mybatis多次请求数据库,是否要创建多个SqlSession会话? 可能最近撸多了,当时脑子里一片模糊,眼神迷离,虽然我当时回答他:如果多个请求同一个事务中,那么多个请求都在共用一个SqlSession,反之每个请求都会创建一个SqlSession。这是我们在平常开发中都习以为常的常识了,但我却没有从原理的角度给钟同学分析,导致钟同学茶饭不思,作为老司机的我,感到深深的自责,于是我暗自下定决心,要给钟同学一个交代。 不服跑个demo 测试在方法中不加事务时,每个请求是否会创建一个SqlSession: 从日志可以看出,在没有加事务的情况下,确实是Mapper的每次请求数据库,都会创建一个SqlSession与数据库交互,下面我们再看看加了事务的情况: 从日志可以看出,在方法中加了事务后,两次请求只创建了一个Sq...
- 下一篇
浅析web端的消息推送原理
转载本文需注明出处:EAWorld,违者必究。 引言: 在互联网高速发展的时代里,web应用大有取代桌面应用的趋势,不必再去繁琐的安装各种软件,只需一款主流浏览器即可完成大部分常规操作,这些原因都在吸引着软件厂商和消费者。而随着各大厂商浏览器版本的迭代,前端技术的不断革新,消息推送用到的场景也越来越多了。 收发邮件提醒,在线IM聊天,自动化办公提示等等,web系统里总是能见到消息推送的应用。消息推送用好了能增强用户体验,用不好则会起相反的效果。在司空见惯的使用过程中,有没有对其中的原理产生兴趣呢?实现消息推送有N种解决方案,本文针对其中的几种,进行原理性的讲解并附有简单的代码实现。 目录: 一、什么是消息推送 二、web端的消息推送 三、实现个性化的推送 一、什么是消息推送 经典场景1 当我在官网观望犹豫时,突然看到了上面消息,一位神秘的徐老板竟然爆出了麻痹戒指!!我的天,于是我果断开始了游戏!这消息很及时! 经典场景2 当我拿起手机不知干嘛时收到了这条招女婿的消息.......瞬间来了精神 上述两种场景,是生活中很常见的场景,通过图文描述,应该已经清楚了推送的场景,也引出了两大...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,CentOS8安装Elasticsearch6.8.6
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS关闭SELinux安全模块
- CentOS7设置SWAP分区,小内存服务器的救世主
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2全家桶,快速入门学习开发网站教程