git rebase basics

by

Let’s start from the beginning. Here’s a diagram of your original state:

A-B-C  (master, origin/master)
 \
  D-E-F-G-H-I  (next, origin/next)

When you checked out next and rebased next onto origin/master, it created 6 new commits after the two that are already on origin/master. These new commits have “master commit #2” (C in my diagram) as their ancestor, not their original ancestor where origin/master and origin/next diverged (A in my diagram), so their hashes will be different. I believe this is why you’ll see that next has 8 different commits from origin/next: the 2 from origin/master and the 6 “rehashed” commits that were on origin/next.

After git checkout next ; git rebase -i origin/master, you should have this:

A-B-C  (master, origin/master)
 \   \
  \   D'-E'-F'-G'-H'-I' (next)
   \
    D-E-F-G-H-I  (origin/next)

You can see that next does have 8 commits that aren’t on origin/next, and origin/next does have 6 commits that aren’t on next. Granted this is just according to the SHA-1 hashes of the commits. The actual content should match very closely if you git diff origin/next next — the diff should just show the changes from B and C (as labeled in the diagram).

When you do git pull --rebase while still on next, it fetches changes from the source (the remote origin/next) and rebases the current branch (next) onto that remote. This causes the changes that were in the next but not in origin/next to appear after origin/next on the new next branch. It should look like this:

A-B-C  (master, origin/master)
 \
  D-E-F-G-H-I  (origin/next)
             \
              B'-C' (next)

If this is what you wanted the history graph to look like, then you’ve succeeded.

However, I suspect you really wanted things to look like the middle diagram, especially if next is a feature branch where you’re working on the next piece of the project and master is for stable code and small bug fixes. If so, then you should have done git push instead of git pull --rebase to make the remote reflect your version of history instead of the other way around.

More Related Contents:

  1. Delete commits from a branch in Git
  2. When do you use Git rebase instead of Git merge?
  3. What exactly does git’s “rebase –preserve-merges” do (and why?)
  4. Git workflow and rebase vs merge questions
  5. What is the difference between merge –squash and rebase?
  6. How to squash all git commits into one?
  7. Edit the root commit in Git?
  8. Insert a commit before the root commit in Git?
  9. How to remove/delete a large file from commit history in the Git repository?
  10. How to git rebase a branch with the onto command?
  11. How to inject a commit between some two arbitrary commits in the past?
  12. How to rebase many branches (with the same base commit) at once?
  13. Rebasing a Git merge commit
  14. Squash the first two commits in Git? [duplicate]
  15. How to rebase local branch onto remote master
  16. When git rebasing two branches with some shared history, is there an easy way to have the common history remain common?
  17. Choose Git merge strategy for specific files (“ours”, “mine”, “theirs”)
  18. Git rebase fails, ‘Your local changes to the following files would be overwritten by merge’. No local changes?
  19. How do I squash two non-consecutive commits?
  20. How do I select a merge strategy for a git rebase?
  21. How do I git rebase the first commit?
  22. Git interactive rebase without opening the editor
  23. Remove commit for good
  24. git rebase: “error: cannot stat ‘file’: Permission denied”
  25. Git: How to rebase to a specific commit?
  26. git rebase merge conflict
  27. Git rebase branch with all parent branches (or dependent sub-branches)
  28. How to retain commit gpg-signature after interactive rebase squashing?
  29. Git rebase –preserve-merges fails
  30. Can tags be automatically moved after a git filter-branch and rebase?

Leave a Comment