CODEWITHSUNDEEP
gitgit-rebase
artfulrobot
artfulrobot

Reputation: 21397

How can I make my commit history work with git rebase?

I have a history that looks like this

H o updated ctools, ds
G M─┐ merged module file
F │ o find page 
E o │ work on download restriction
D o─┘ Report downloading/emailing WIP
C o migration: find and replace URLs throughout notes
B o various local things
A o initial commit

Further behind, A comes off of a remote master. Now the remote has moved on and I'd like to use git rebase to update my history to be on top of the latest remote changes.

All of these commits are on code that is not in the remote master, but git rebase will fail me because it seems to not understand how to process D:G: the side branch that was merged at G. Git rebase attempts to apply them in order, without the merge, i.e. A B C D E F H... but F will not apply on E. I plan on needing to rebase several times to keep my code on top of the latest origin's development, so I want a lasting solution.

How can I tell git that the answer to the conflict is to be found at G? Or how can I do something else such that git rebase will be able to reply commits? I'd happily squash D:G into D' if that made things easier.

Upvotes: 3

Views: 130

Answers (1)

prusswan
prusswan

Reputation: 7091

Git merge with master is the best option in your scenario, as rebase isn't designed for merge commits (G is your problem here). But if you really want to and git rebase -p didn't produce the desired result, you can:

  1. rebase A-E (which is then A'-E')
  2. reapply F separately (by cherrypick or otherwise) on top of D' to become F'
  3. merge E' and F' to become G'
  4. cherrypick H on top of G'

Other reasons why merge is preferred here:

  1. Those commits you are trying to rebase probably already belong to some feature branch on the remote, rebasing a lot of them onto another remote branch will simply result in a whole lot of duplicate commits, which can be confusing to others.

  2. If those commits are only in your local branch, by rebasing (but not necessarily pushing) them you are effectively "withholding" them until the time they finally get pushed or merged. This can be disruptive to others as it will look like a huge number of commits suddenly appeared out of nowhere within a short period of time; merging should be a regular activity in the workflow.

That said, if you plan to do regular rebase for any reason whatsoever (such as working with git-svn), the best way is to maintain a linear history for the commits that you wish to rebase and/or limit them to a small number. For a series of commits involving merges, those merges need to be collapsed from front to back (like mini rebases).

Upvotes: 2

Related Questions