聊下 git rebase -i

简介: 在使用git作为源代码管理工具的时候,开发的时经常会面临一个常见的问题,多个commit 需要合并为一个完整的commit提交。 在一个基本的迭代周期里,你会有很多次commit,有跟配置文件相关的,有跟代码相关的,甚至有跟下次发布fixbug相关的。

在使用git作为源代码管理工具的时候,开发的时经常会面临一个常见的问题,多个commit 需要合并为一个完整的commit提交。

在一个基本的迭代周期里,你会有很多次commit,有跟配置文件相关的,有跟代码相关的,甚至有跟下次发布fixbug相关的。这些都是你在完成本地开发的时候一个变化记录而已。但是当你需要将你的迭代项目作为一次发布提交时就需要整合所有之前提交的那些很零碎的commit。

根据基本规范,你的commit应该类似"release:20161023_imageprint",在此commit里应该是完整的提交。

合并多个commit为一个完整的commit

我先基于develop主分支拉出一个功能分支(每个人和每个公司对分支的管理都不太一样,这里不需要太纠结。)。这里的develop是开发主分支,所有的开发功能代码都需要回归到这个develop分支中去。

git branch -a –vv

1

develop_fixbug_imageprint 分支是我基于远程develop分支拉出来的开发分支,我会基于这个分支来fix一些bug。我们分别看下develop、develop_fixbug_imageprint  commit log。

git checkout develop

git  log

2

git checkout develop_fixbug_imageprint

git log

3

develop_fixbug_imageprint的commit log是和devleop commit log 一模一样。我们现在切换到develop_fixbug_imageprint进行一些操作。

添加一个1.txt文件,然后git add . ,git commit –m’add 1.txt’。

再添加一个2.txt 文件,然后git add . ,git commit –m’add 2.txt’。
4

现在develop_fixbug_imageprint分支里有两个commit。这两个commit都是为了fix当前这个bug而做的两个提交。现在我们要合并代码上主develop分支。总不能把这两个commit直接提交上去,这里还好只有两个commit,但是一般项目开发周期两个星期的话,你起码有十几个commit。那这样提交上去之后就很难管理和跟踪。(我以前都是这样干的,现在发现这样不好跟踪管理。)

那么我们如何完成这个合并commit尼,就需要用到git rebase 命令。

先来解释下git rebase 。你其实可以把它理解成是“重新设置基线”,将你的当前分支重新设置开始点。这个时候才能知道你当前分支于你需要比较的分支之间的差异。

比如,develop_fixbug_imageprint分支是来自develop分支,那么从test commit开始后面我们基本上都是各自发展,现在在develop_fixbug_imageprint分支上有两个commit,我们需要找一个基准,这个基准就是git需要找到哪些是你后来提交的commmit,总的有个参照。

git reabse –i develop

5

git rebase 立马知道develop与develop_fixbug_imageprint之间的差异。因为我们是基于develop设置rebase的。git rebase –i ,这里的”-i“是指交互模式。就是说你可以干预rebase这个事务的过程,包括设置commit message,暂停commit等等。

这里我们要求很简单就是合并之前的commit且重新设置commit message。

我们设置第二个”pick 657a291 add 2.txt” 为” s 657a291 add 2.txt”这里的s就是squash命令的简写。

6

跳出来了一个临时文件,最上面是两行commit message。我们修改下这个总体的commit message。

7

删除之前的两条message(ESC dd),设置一总的message 然后保存退出。(ESC wq)

8

我们查看下log。git log

9

是不是没有了之前的两个commit。

原理很简单:rebase需要基于一个分支来设置你当前的分支的基线,这基线就是当前分支的开始时间轴向后移动到最新的跟踪分支的最后面,这样你的当前分支就是最新的跟踪分支。这里的操作是基于文件事务处理的,所以你不用怕中间失败会影响文件的一致性。在中间的过程中你可以随时取消rebase 事务。git rebase –abort

在进入git rebase –i 交互模式,你可以做的事情就很多了,可以设置edit 编辑commit 内容,可以让他暂停commit操作。等等。

目录
相关文章
|
7月前
|
开发工具 git
git merge和git rebase异同
git merge和git rebase异同
172 0
|
9天前
|
前端开发 持续交付 开发工具
理解前端开发中的 Git - Rebase
Git Rebase 是前端开发中常用的一种版本控制操作,用于将一个分支的更改整合到另一个分支。与合并(Merge)不同,Rebase 可以使提交历史更加线性整洁,有助于保持代码库的清晰和可维护性。通过 Rebase,开发者可以将特性分支的改动应用到主分支上,同时保留或重写提交记录。
|
7月前
|
JSON 开发工具 git
git rebase 合并当前分支的多个commit记录
git rebase 合并当前分支的多个commit记录
144 1
|
6月前
|
开发工具 git 开发者
【git merge/rebase】详解合并代码、解决冲突
【git merge/rebase】详解合并代码、解决冲突
620 0
|
4月前
|
开发工具 git 开发者
|
3月前
|
网络性能优化 开发工具 git
使用git rebase --onto一例
使用git rebase --onto一例
|
6月前
|
安全 开发工具 git
蓝易云 - git rebase和merge区别
在选择使用Merge还是Rebase时,需要根据具体的工作流程和团队的规定来决定。一般来说,如果你想保持完整的历史记录并且避免可能的冲突,你应该使用Merge。如果你想要一个干净的、线性的历史记录,你可以使用Rebase。
54 4
|
5月前
|
开发工具 git 开发者
git IDEA的分支合并时的冲突问题总结,merge和rebase的区别
冲突的处理需要开发者之间的充分沟通以及对项目历史的细致理解。选择Merge或Rebase取决于具体的工作流程和团队偏好,但最重要的是保持代码库的整洁与一致性。使用IDEA等工具可以提高处理合并冲突的效率,但手动解析冲突和理解操作背后的逻辑仍然是不可或缺的。最终目标是通过有效的版本控制实践,促进项目的顺利进行和团队协作的高效。
330 0
|
7月前
|
开发工具 git
git pull之后出现REBASE(1/1)
git pull之后出现REBASE(1/1)
425 3
|
7月前
|
开发工具 git 开发者
【专栏】探讨了 Git 中的 `git rebase` 操作,它用于重新应用提交到另一分支,改变历史顺序
【4月更文挑战第29天】本文探讨了 Git 中的 `git rebase` 操作,它用于重新应用提交到另一分支,改变历史顺序。与 `git merge` 不同,rebase 重写提交历史,提供简洁线性的历史记录。文章介绍了 rebase 的基本操作、应用场景,如整理提交历史、解决冲突和整合分支,并强调了使用注意事项,如避免在公共分支上操作。尽管 rebase 可以带来整洁的历史和冲突解决便利,但其潜在的风险和可能导致的历史混乱需谨慎对待。理解并恰当使用 `git rebase` 可以提升开发效率和代码质量。
200 1