分享 Git - rebase

hiveer · 2014年10月28日 · 最后由 hiveer 回复于 2014年10月29日 · 5715 次阅读

这是一篇翻译文档(SL:https://help.github.com/articles/about-git-rebase/),同时参杂了部分自己的见解

说在开讲前 😄 这应该算是 Git 的高级功能了,为什么这么讲?大家回忆下自己日常使用 Git 的时候最常用的是哪些命令(branch, checkout, pull, add, push ... ...)。是的,我们可以就用这些常用命令就能完成我们想要做的事情,但是当你想要把你已经做了的事情做得更漂亮的时候,你不得不寻找新的出路。那么对于 Git 来讲,rebase就是这样一个工具。

Command: git rebase 允许你对历史提交进行一系列的操作,排序、编辑、整合等。这是个很有必要的功能,为什么? 在你的工作目录下轻轻的敲下git log,仔细看看你的提交记录,你应该会明白。 注意: 有一点要注意,如果你已经把修改提交到了远程目录,并且不确定是不是你的 partner 已经在使用你的提交的时候,请不要轻易对这些提交进行rebase的操作,这会带来不必要的麻烦,为什么?(试试便知道)

如上述,git rebase允许你对历史提交进行操作,但是究竟是哪些历史提交呢?我们需要找到一个历史时间点,两种方式可以帮我们找到这个时间点。 一、相对于一个分支 我们知道除了 master 分支,其余的分支必然都会有一个源分支,也就是说当前分支必然存在一个 Birth Time。

二、相对于一次提交 这个应该更好理解了,任何一次提交也必然会存在一个 Birth Time。

在 Rebasing 的时候可用命令 pick 意思是这次提交会保留,对于多行 pick,你可以对他们进行各种排序 as you like,也可以删除某一行。那么这些操作都会最终体现到你的提交历史记录中。 reword 在 pick 的基础上,多给了你一次重新编辑 commit msg 的机会。 edit 将会把这次提交重新放到你面前,然后任你宰割。客官你想干什么? squash 将会把本次提交和上一次提交整合,同时你将有机会重新编辑 commit msg。 fixup 跟 squash 唯一的区别是剥夺了你重新编辑 commit msg 的机会(当小妾不是滋味)。 exec 允许你对这次提交执行任何的 shell command(尼玛,太强大了,没用过)。

PS: 欢迎各路大神指点!

每贴必自顶!

rebase 是 git 的一个重要功能,用它确实有趣得多,但处理的好反而容易在解决冲突的时候造成不必要的麻烦,我有时候宁肯 pull 也不敢随便就 rebase 也是因为这个原因。要讲 rebase 的话,不可避免地要阐述一下和 merge 之间的差别以及适用的场合。

妥妥的精华。

如果每次 rebase 都要解决一大堆冲突,倒不如用 merge 来的方便。对于频繁的 commit,rebase 可以避免大量无意义的 merge commit。还有,merge 是很危险的,尤其在没有 develop 和 release 分支的时候。

详见 http://ihower.tw/blog/archives/3843

#2 楼 @lilonglongRoR 确实需要明确应用的场合,下一篇文章就对比下 merge 和 rebase 吧!

@liwei78 很多时候确实有多种可用方案

需要 登录 后方可回复, 如果你还没有账号请 注册新账号