原文地址：http://platinhom.github.io/2016/01/02/git-combine_commit/
有时commit多了看着会不爽.所以想合并掉一些commit. 这里是最简单的情况, 一条线下来N个commit, 合并掉末端的(没有branch出去的).
假设有a,b,c,d四个commit, 从新到旧是a, b, c, d (也就是先d->c->b->a). 四个commit的SHA-1分别是a1,b1,c1,d1.
合并commit只能倒退, 就是说把a合到b(老的),顺序是abc可以合并起来成k, 最后成k, d这样.
# git log |head
git rebase -i d1
# if fail, use git rebase --abort
git push --force
-
git log
可以查看commit的情况, 配着head命令可以查看前几个.
git log --pretty=oneline
一行一个commit更好了
-
rebase前需要把状态push掉. 就是说不能有unstaged的修改.
-
-i
是选择不动的commit, 比他新的commit都有被修改的可能.
-
执行rebase后如果出错或者merge冲突什么退出来, rebase会被锁定, 再次执行时, 提示有三个选项:
-
git rebase --abort
来忽略之前的rebase尝试,并恢复HEAD到开始的分支.
-
git rebase --continue
就继续上次修改, 一般是rebase中间处理merge冲突后使用.
-
git rebase --skip
是重新开始rebase并跳过现在所进行的处理.
-
执行rebase后会像commit一样进入编辑状态, 在开始会是几个commit的SHA值, 从上到下是越来越新的commit. 如果没有比-i指定的心的话会出现noop.
-
开始状态所有出现的commit前面都是pick. 这个pick是对该commit进行的操作, 有:
-
pick
就是说保留该commit, 也可以用缩写
p
. (黄色)
-
squash
, 使用该commit但合并到前一个老的commit去(常用). 可以用缩写
s
代替 (绿色).
-
reword
, 和pick类似, 但可以修改commit时的提交信息(中间会弹出来让你修改commit).可以用缩写
r
代替 (紫红色).
-
edit
, 使用commit, 但停下来进行修改, 可能用于merge冲突.可以用缩写
e
代替.
-
fixup
, 和squash类似, 但会舍弃commit信息. 可以用缩写
f
(红色)
-
exec
, 执行shell命令.可以用缩写
x
-
如果该commit是空commit, 前面会被注释掉
#
. 会被自动删除.
-
执行完修改后,
:wq
退出vi, 这时开始进行rebase操作(1/10 这样倒数). 中间会再次弹出修改文件, 此时是修改commit信息, 可以修改每次commit的信息(如果是fixup会忽略掉commit提交信息). 最后这个合并后的新commit显示的信息可能是多个commit的集合(多行).不想修改或改完后直接
:wq
退出vi即可.
-
所以都完成后需要一次强制的push, 要加入
--force
覆盖掉github上的commit.
git push --force
例如我上面
-i d1
会修改3个commit, 保留最老最上最靠近d1的c (用reword或者pick都可以),其余a1和b1合并掉(squash或者fixup).最后生成一个新commit叫c2(就是3个合在一起了).所以从新到旧有c2, d1.
原文地址：http://platinhom.
git
hub.io/2016/01/02/
git
-combine_
commit
/
有时
commit
多了看着会不爽.所以想
合并
掉一些
commit
. 这里是最简单的情况, 一条线下来N个
commit
,
合并
掉末端的(没有branch出去的).
假设有a,b,c,d四个
commit
, 从新到旧是a, b, c, d (也就是先d->c-&g...
在我们平时开发中，我们提交代码免不了要和
git
打交道，那么我们肯定是先从预发分支上（公司一般都用pre命名，这里为了方便演示用master）上拉去最新的代码，然后自己在上面在切一个自己的功能分支(gongeng)进行开发。
但是如果我们一个功能模块开发完了之后，肯定提交了许多次，如果我们想把这么多提交记录都merge到我们的master分支上，肯定是不友好和不雅观的。所以我们需要将我们许多次的提交记录合成一次的提交记录，在
合并
到我们的pre分支上。（多说一句：一般自己的功能......
今天同事突然问我，由于在给老大的开源项目提 pr 的时候，自己比较长时间没有
rebase
的老大的项目 master 分支了，而自己提交的
commit
又很多，有些
commit
又是实验性质的，乱七八糟的（其实就是没有用熟
git
…），还有不少和老大的代码冲突了。提交代码的时候，老大要求精简一下
commit
否则其他人在看项目的演进的时候会一头雾水的。
我认为老大说的是对的，当然也存在一个...
在
git
进行项目版本管理时，经常会遇到如下的场景， 开发者针对feature/bugfix/ hotfix/refactoring进行开发时，在本地repo中进行了很多次
commit
s,然而当当前开发结束时，开发者并不需要把所有的
commit
s 都push 到远程
git
server 中，开发者可以选择需要的
commit
s
压缩成
一个
commit
, 然后push 这一个
commit
到远程
git
server 即可。具体的步骤如下：
使用
git
log 列出当前的
commit
history, 比如说
这里使用到一个命令：
git
rebase
-i，
我们
合并
21和22提交记录，那么
git
rebase
-i 后面跟的参数应该是想要
合并
的最前面
commit
id的上一个，就是7690fbee9fb9df0a6d4226e81523acc5d421a3da这个
git
rebase
-i 7690fbee9fb9df0a6d4226e81523acc5d421a3da
这是弹出编辑框
这里除了第一个外，其他的pick改成s，意思就是把第二条往下的记录全部
合并
到第一条
`
git
merge --squash`
合并分支
并将
多个
`
commit
`记录
合并
已有`dev`分支，往`master`分支
合并
，并且不希望展示`dev`分支的提交记录
原文——Squash
commit
s into one with
Git
本篇介绍一个很棒的能将多次修改
合并
起来的方法，尤其是在将他们共享出去之前在
Git
中，你可以使用强大的 interactive
rebase
（交互式
rebase
）将多次提交
合并
成一次。这是我常用的一个很方便的工具；我经常通过将
多个
临时的小的提交
合并
成一次提交，然后将整理好的代码 push 给远端。步骤 1: 选择你的起始提交第一步就是让
git
开始一次交互式
rebase
会话：1
git
rebase
--interactive
第一种：通过编辑器IDE(亲测)
我使用的是idea，通过idea进行
commit
压缩。
第一步： 选择当前分支，然后查看版本控制(Version Control)，展示出提交记录，比如，我在图中标注的七条提交记录，通过
commit
-message 可以清晰的看出来，1-2、3-4是同一类或者相同的提交。
第二步： 想压缩1-2的提交，可以右击1 提交，弹出功能框，如图二展示。
选择红框的选项(从当前位置开始进行
Rebase
)。
第三步： 点击该功能，弹出可进行压缩的com
我使用 `
git
` 有一段时间了，但老实说，我很少关注凌乱的提交历史。最近在学习 `
git
rebase
` ，想分享一下如何使用这个命令来压缩整理提交(
Commit
s)
简而言之，总共有五个步骤。
1. 运行`
git
rebase
-i head~x`→ `x` 是需要从头开始压缩的数目，`-i` 表示交互模式
2. 按 `i` 进入`vim`的`INSERT`的输入模式
3. 将`pick`更改为 `fixup` 或 `f`
4. 按 `ESC` 退出 `INSERT` 模
