合并分散的几个commit

今天终于完善好了一个补丁,但是很久以前的补丁和最新的这个是实现同样的功能,要把两个相隔甚远的commit合并在一起。以前有过经验,但只是相邻的两个补丁,使用rebase命令。于是上网搜寻一番,发现没什么人写出方便的方法或者说是合适我的方法。有一个是开一条branch,然后reset到以前的那个commit,再两个branch merge。的确是可以这样,但我觉得太间接了。。而且,这样好像只可以把那个commit之前的所有commit合并。

于是想了一会,想出了自认为比较好的方法:)

首先,保存好你所有的修改,使用git add/commit自不必说,但不想commit时可以试试git stash(很好用--),否则rebase前会提示你保存。

然后,执行git log,查看你想修改哪个commit前的全部commit。git rebase -i 加上此commit的ssh。比如,我想合并第一个和第三个commit,就执行git rebase -i c65b7be68f (就是第四个commit的ssh)

以我为例,执行命令后会出现

下面蓝色的就是各个命令的介绍。我们需要的是合并commit,看squash的介绍 =..., meld into previous commit与之前的commit融合。

我们想合并第一个和第三个补丁,所以把第三个commit提到第二个位置来(就是把第三行挪到第二行),此时如果没有冲突,保存并退出后会执行rebase并提示success。

但这只是改变了commit的顺序,还没有合并。别急,马上就要完成了。再执行一次rebase命令,把第一个commit的pick改成squash,保存退出就会把此commit跟你原来想合并的第三个(现在是第二个)合并起来,并让你修改commit message:-)

大功告成~若是合并第2、5、8的commit也一样操作,挪到一起,比如2,3,4,再把2、3的pick改成squash(其实直接挪动和改就行,不过上面特意分开来说清楚而已),就可以啦~

合并分散的几个commit,布布扣,bubuko.com

时间: 2024-10-25 21:33:41

合并分散的几个commit的相关文章

git合并分支上指定的commit

merge 能够胜任平常大部分的合并需求.但也会遇到某些特殊的情况,例如正在开发一个新的功能,线上说有一个紧急的bug要修复.bug修好了但并不像把仍在开发的新功能代码也提交到线上去.这时候也许想要一个只合并指定某些 commit 的功能. 假设分支结构如下: dd2e86 - 946992 - 9143a9 - a6fd86 - 5a6057 [master] 76cada-62ecb3-b886a0[feature] 再假设 62ecb3 的提交修复了bug,这时候可以用cherry pic

Git管理修正(取消跟踪、合并commit)

本文总结了最近使用Git时候遇到的两个问题: 1. 当将不必要跟踪的文件加入到仓库后如何处理? 2. 提交了多个功能相同的commit后如何处理? 总结经验 在创建仓库的一开始,就要设置号.gitignore文件,用于过滤掉不需要跟踪的文件和文件夹 谨慎提交commit,确保每个commit中所有的改动都是跟同一个任务相关的. 我是怎么解决上述两个问题的 1. 移除对文件/文件夹的跟踪,但不删除 使用命令git rm --cached ignore_target_file 删除对某个文件的跟踪

Git合并多个Commit

当前有四个commit,现在要将四个commit合并为一个,可以使用git rebase -i HEAD~{这里是要合并的commit数量} 如 git rebase -i HEAD~4 ,即为合并最新的四个Commit,运行git reabse -i HEAD~4后,会出现如下界面 按照图中Commands中的提示操作,将commit b,c,d前面的pick改为s,这里我们将commit a前面的pick改为r,代表使用这个commit,并修改commit message 修改完后保存修改,

Git合并已经push的commit

1. 查看commit历史 $ git log 2.选择要合并的commit,3代表要合并最新的3条commit $ git rebase -i HEAD~3 3.修改要保留的commit和要合并的commit pick代表选择这个commit,squash代表合并这个commit 4.修改commit的文字描述 不需要的commit文字描述可以注释掉 5.push到远程仓库 $ git push origin xxxx -f 原文地址:https://www.cnblogs.com/Coufu

svn branch and merge(svn切换分支和合并)详解

下文的实践主要是参考了TortoiseSVN的帮助文档和Subversion的在线文档,Subversion的在线文档:http://svnbook.red-bean.com/en/1.5/svn-book.html 先说说什么是branch.按照Subversion的说法,一个branch是某个development line(通常是主线也即trunk)的一个拷贝,见下图: branch存在的意义在于,在不干扰trunk的情况下,和trunk并行开发,待开发结束后合并回trunk中,在bran

SVN分支的合并和同步

使用svn几年了,一直对分支和合并敬而远之,一来是因为分支的管理不该我操心,二来即使涉及到分支的管理,也不敢贸然使用合并功能,生怕合并出了问题对团队造成不良影响,最主要的原因是,自己对分支的目的和合并的方法不甚了解,这才是硬伤. 最近由于适配机型的需要(本人从事手机客户端的开发),需要经常接触分支和合并两项工作,突然发现这玩意整不明白很难开展工作,遂这两天着重研究了一下,有点收获,怕以后忘了,故趁着余温尚在赶紧写下来,好记性不如烂笔头嘛.下文的实践主要是参考了TortoiseSVN的帮助文档和S

【原创】Git 分支的合并【Learn Git Branching】

merge   git merge是我们要学习的合并工作的第一个方法.合并产生一个特殊的提交记录,它包含两个唯一父提交.有两个父提交的提交记录本质上是:“我想把这两个父提交本身及它们的父提交集合都包含进来.” 1. 有共同祖先,但非直接上下游关系的分支 根据C1.C2.C3这三个提交对象(C1是C2.C3的共同祖先),合并之后,生成了一个新的提交对象,包含了两个父提交.假如从合并后的master出发,开始沿着箭头向上游走,在到达起点的路上会经过所有的提交记录,这说明master包含了所有代码库的

TortoiseSVN中分支和合并实践【转】

使用svn几年了,一直对分支和合并敬而远之,一来是因为分支的管理不该我操心,二来即使涉及到分支的管理,也不敢贸然使用合并功能,生怕合并出了问题对团队造成不良影响,最主要的原因是,自己对分支的目的和合并的方法不甚了解,这才是硬伤. 最近由于适配机型的需要(本人从事手机客户端的开发),需要经常接触分支和合并两项工作,突然发现这玩意整不明白很难开展工作,遂这两天着重研究了 一下,有点收获,怕以后忘了,故趁着余温尚在赶紧写下来,好记性不如烂笔头嘛.下文的实践主要是参考了TortoiseSVN的帮助文档和

11_Eclipse中演示Git版本的创建,历史版本的修改,创建分支,合并历史版本和当前版本

?? 1 执行以下案例: 某研发团队2011年初开发了一款名为Apollo的信息系统,目前已发布v1.0版本.此项目初期已有部分基础代码, 研发团队再此基础代码上经过3个月的努力发布了一个功能相对完备的Apollo 1.0版本进行销售. 由于销售业绩良好,因此研发团队正在着手v2.0版本的开发工作. 但就在这个时候,有客户发现v1.0软件系统一严重bug,如不及时修复将造成严重后果. 研发团队收到bug报告后立刻安排部分研发人员对v1.0版本进行修复,但其他研发人员则继续开发v2.0版本的新功能