166

My Git history looks like that :

Git history

I would like to squash the purple commits into a single one. I don't want to see them ever again in my commit log.

I've tried to do a git rebase -i 1, but even though 1 is on the blue branch (cf. picture), I still see every commit on my purple branch.

How can I completely remove the purple branch (from commit log) ?

Benjamin Toueg
  • 10,511
  • 7
  • 48
  • 79

5 Answers5

152

Do git rebase -i <sha before the branches diverged> this will allow you to remove the merge commit and the log will be one single line as you wanted. You can also delete any commits that you do not want any more. The reason that your rebase wasn't working was that you weren't going back far enough.

WARNING: You are rewriting history doing this. Doing this with changes that have been pushed to a remote repo will cause issues. I recommend only doing this with commits that are local.

Schleis
  • 41,516
  • 7
  • 68
  • 87
  • 7
    Even if I choose a sha before the branches have diverged, I see all the commits of the purple branch -_- – Benjamin Toueg Jul 10 '13 at 18:15
  • 1
    Yeah, then you delete them in the editor that comes up with `git rebase` and they will be removed. – Schleis Jul 10 '13 at 18:17
  • 6
    Deleting the commits resulted in losing all the modification of the merge. But I did a soft reset and I've been able to have something quite like I wanted (order do not match initial expectations). – Benjamin Toueg Jul 10 '13 at 18:35
  • 3
    this answer is incomplete in detail, which branch do yu initiate the rebase from? – grgry Feb 17 '16 at 09:18
  • 1
    @gregorynich You are dealing with only one branch, it just has another branch merged in. Which results in all the commits showing up in the history, the OP's question doesn't talk about other branches. – Schleis Feb 17 '16 at 18:41
  • 4
    Fairly sure you do not want to 'remove' the commits. 'remove' is not an option in rebase, but delete is. if you delete a commit, you will loose the changes it introduced. You want to squash the commits. – thecoshman Oct 02 '17 at 09:55
  • Why does this rebase need to be interactive? I noticed it won't work otherwise, or I'm missing something. – Cosmin Lehene Nov 15 '17 at 21:29
  • @CosminLehene if it isn't interactive, you won't be able to edit the list of commits – Schleis Nov 28 '17 at 14:55
  • It worked for me. After rebase was complete; I had to do a `git push -f origin develop` – Awi Mar 23 '19 at 15:07
  • It worked before. Modern git versions LEAVE such commits on rebase. – socketpair Jan 17 '23 at 18:54
135

Starting with the repo in the original state

Original repo history

To remove the merge commit and squash the branch into a single commit in the mainline

Squashed commits, no merge commit

Use these commands (replacing 5 and 1 with the SHAs of the corresponding commits):

git checkout 5
git reset --soft 1
git commit --amend -m '1 2 3 4 5'
git rebase HEAD master

To retain a merge commit but squash the branch commits into one:

Squashed commits, retained merge commit

Use these commands (replacing 5, 1 and C with the SHAs of the corresponding commits):

git checkout -b tempbranch 5
git reset --soft 1
git commit --amend -m '1 2 3 4 5'
git checkout C
git merge --no-ff tempbranch
git rebase HEAD master

To remove the merge commit and replace it with individual commits from the branch

Branch moved into mainline, no merge commit

Just do (replacing 5 with the SHA of the corresponding commit):

git rebase 5 master

And finally, to remove the branch entirely

Branch removed entirely

Use this command (replacing C and D with the SHAs of the corresponding commits):

git rebase --onto C D~ master
sandstrom
  • 14,554
  • 7
  • 65
  • 62
Allen Luce
  • 7,859
  • 3
  • 40
  • 53
  • 1
    in `git rebase 5 master` case, why it is not "A B C 1 2 3 4 5 D ..." order? – Roy Jun 04 '18 at 15:28
  • 3
    That command takes the commits that `master` doesn't have in common with `5` and plops them on top of `5`. The commit at `C` isn't part of the lineage of `5`, it's the first to be moved on top of `5`. – Allen Luce Jun 04 '18 at 19:55
  • 3
    If you want to end up with "A B C 1 2 3 4 5 D ..." you can do: `git rebase C 5; git rebase 5 master` – Allen Luce Jun 04 '18 at 19:56
  • Did exactly like this and worked even a thousand commits back! – Michael-O Dec 20 '22 at 14:57
48

To Just Remove a Merge Commit

If all you want to do is to remove a merge commit (2) so that it is like it never happened, the command is simply as follows

git rebase --onto <sha of 1> <sha of 2> <blue branch>

And now the purple branch isn't in the commit log of blue at all and you have two separate branches again. You can then squash the purple independently and do whatever other manipulations you want without the merge commit in the way.

Warren
  • 1,903
  • 1
  • 21
  • 30
  • 2
    Of all the answers, I find this both the most straightforward and the easiest to do. Thank you. – Roshambo Jul 22 '20 at 22:34
  • This is the first step to the question, and I agree the easiest that does exactly what was requested. The second step would be `git merge --squash ` – Tony Dec 09 '20 at 16:19
  • best answer, definitely. Thanks. ps: add --rebase-merges if you want to preserve some other merge commits along your blue branch (otherwise rebase will flatten those by default) – chris Jan 31 '23 at 09:49
25

There are two ways to tackle this based on what you want:

Solution 1: Remove purple commits, preserving history (incase you want to roll back)

git revert -m 1 <SHA of merge>

-m 1 specifies which parent line to choose

Purple commits will still be there in history but since you have reverted, you will not see code from those commits.

Solution 2: Completely remove purple commits (disruptive change if repo is shared)

git rebase -i <SHA before branching out>

and delete (remove lines) corresponding to purple commits.

This would be less tricky if commits were not made after merge. Additional commits increase the chance of conflicts during revert/rebase.

prem
  • 386
  • 2
  • 5
  • This does not sound right. Leaving aside the fact that it's hard to tell what the original poster wanted to do with the purple commits in the first place, if you revert the merge, that's fine, that will do a reverse patch of the changes from that commit and add it as another commit, canceling the purple commits out. It's like `1 - 1 = 0`. But if you then rebase out the purple commits, you leave behind the reverted patch, unless you rebase that out too. If you don't, it's like applying `-1` to your history, not `0`, so you'll leave behind changes you don't want. –  Jul 14 '13 at 07:04
  • @Cupcake, provided were two separate answers. I have revised answer to be less confusing :P – prem Jul 21 '13 at 19:41
  • AFAIK this is not what the OP is asking for. He wants to keep the changes, but remove the noise from his log. For that, he needs to squash the commits down, deleting will remove the changes. – thecoshman Oct 02 '17 at 09:57
  • True, looks like the original question has been rephrased. This answer is not for OPs problem. – prem Oct 29 '19 at 23:48
10

For full control over the operation and to preserve any merge commits you want to keep along the way, the modern approach is to use

git rebase -i -r

squall3d
  • 1,737
  • 14
  • 12
  • good to know .. but this is the option I'd never use ... because personally I prefer minimum to no merge commits in my git history :) – vivekmore Sep 10 '22 at 13:55
  • I started to do this, but then I had no idea what I was doing, could you elaborate on this answer? – acolchagoff Jul 17 '23 at 15:59
  • The command is still a `git rebase -i` at it's heart, so make sure you're comfortable with that first. Suggest you pick a simple merge commit to try this out first. Read what's in the todo textfile, try to trace and follow what git is going to do. Once you have a good idea, you can start experimenting by introducing new commits in the merge, move commits to before the merge, etc. If you need more specific help you'll need to provide more details :) – squall3d Jul 19 '23 at 13:25