Git版本控制(5) —— 分支管理策略

在我们的日常工作中,当我们提pr merge到staging(测试)分支的时候,会发生冲突,我们需要在本地解决冲突。gitlab网页会提示我们使用merge指令的时候使用–no–ff参数。这里需要稍微解释一下,no–ff参数是什么意思。默认情况下,Git执行”快进式合并”(fast-farward merge),会直接将stagng分支指向Develop分支。
这里写图片描述
使用–no–ff参数后,会执行正常合并,在Master分支上生成一个新节点。但是为了保证版本演进的清晰,我们还是希望采用这个用法。merge完成之后,我们检查git log,我们会看到多了一条meger Develop branch into staging的日志。
这里写图片描述

接下来来介绍两个骚操作:

有时候当我们要切换分支,但是两个分支之间有冲突,这在feature分支版本控制的时候,是经常发生的。比如说,当我从一个分支切回master分支时,如果你的修改还保留在工作区和暂存区(只add,但是没有commit),冲突时常会发生。以前我经常就是直接放弃某个分支的修改(commit + git reset -hard commit-id), 这是十分愚蠢的做法。git stash 可以很好地帮我们解决这个问题。

git stash: 保存当前的工作进度, 会分别对暂存区和工作区的状态进行保存

git stash save “message…” 这条命令实际上是第一条 git stash 命令的完整版

git stash list : 显示进度列表。此命令显然暗示了git stash 可以多次保存工作进度,并用在恢复时候进行选择。 每个分支的git stash 状态都会保存在这个list里面

git stash pop : 如果不使用任何参数,会恢复最新保存的工作进度,并将恢复的工作进度从存储的工作进度列表中清除。

git stash clear : 删除所有存储的进度

猜你喜欢

转载自blog.csdn.net/zyhmz/article/details/80300282