GIT之如何让合并分支后变得简单
从个人近期结合SHELL及带UI管理工具的使用情况,以及实际项目应用情况来看,还真那么一回事 香 啊
拿个案例来说说
老版本出现BUG了,新版本还是撸中 怎么办?
简单的工作流程如下
-
找到 版本标签 并建立Bug分支
-
在新的Bug分支进行修复开发,并发布版本
-
重点:如何将修复的提交 应用于 主线分支 与 各后续开发分支 呢
简单粗暴的方法就是复制代码,各分支粘贴,容易出错是必然的,伤大脑是持久的。
问题解决了,脑袋受不了,怎么办?
先明确下目标,我想达到Bug分支的提交链 都直接在目标分支中重新回放一遍,从而形成单条的提交链,简单明了
-
git rebase 方案
此命令可以将Bug分支上所有提交链应用到目标分支上,具体操作流程如下
# 进行合并操作
git checkout bug # 切换到Bug分支
git rebase master # 将当前分支的提交链应用到master
# 发生冲突时,修订再继续就行
git add * # 当碰到冲突,并修订后,加入临时区
git rebase --continue # 应用这个,则会解决冲突后,继续应用
# 发生冲突时,放弃回归原来
git rebase --abort # 应用这个,则回归到最初状态
git rebase 基本原理是寻找当前分支与目标分支共同的祖先提交节点,把此之后所有提交进行回放应用,此方案更适合一主一从情况,如果存在多线在开发中,则不适合。
-
git cherry-pick 方案
此命令同样可以实现git rebase,但个人感觉技高一筹,可以选择其中感兴趣的COMMIT节点进行重放
# 进行合并操作
git checkout master # 切换到目标分支
git cherry-pick [commitid] # 将[commitid]应用于当前分支
# 发生冲突时,修订在继续
git add * # 发生冲突时,则需要进行修订并加入临时区
git cherry-pick --continue # 应用这个,则会解决冲突后,继续应用
# 发生冲突时,放弃回归原来
git cherry-pick --abort # 应用这个,则回归到最初状态
这个方案就比较随性了,可以实现多线并行开发情况下进行重放操作
以上内容限于个人日常工作中一些应用总结
-
具体的命令应用请参考
网友评论