2

I've used $ git pull origin master (which is a combination of fetch and merge) and $ git push origin master so far. Now I'm hearing about rebase. I've read the documentation about it but sadly I couldn't understand how it works exactly.

Two questions:

One: What does ' (which is in the top of D and E) mean?

before rebase:

A <- B <- C
^         ^
 \         \
  D <- E <- F

after git rebase master:

A <- B <- C <- D' <- E'

two: When should not I use $ git rebase? (also is it the same as git pull --rebase?)

Community
  • 1
  • 1
stack
  • 10,280
  • 19
  • 65
  • 117
  • 2
    Possible duplicate of [What's the difference between 'git merge' and 'git rebase'?](https://stackoverflow.com/questions/16666089/whats-the-difference-between-git-merge-and-git-rebase) – Chris Hawkes Aug 16 '17 at 21:11
  • Read the linked questions (and others), but note that in short, `git rebase` means *copy* some commit(s) and then try to forget the originals in favor of the copies. The `D'` and `E'` indicate that these are *copies* of the originals `D` and `E`, with—of course—some things changed. The things changed are the *parent linkages* (`D'` goes back to `C`, not to `A`) and the associated source tree (`D'` compared to `C` makes the same *changes* as `D` compared to `A`, but starts from whatever is in `C`). – torek Aug 16 '17 at 21:21
  • @torek Isn't what you said the concept of `merge`? – stack Aug 16 '17 at 21:41
  • No: `git merge` (usually) makes a new commit whose content is the result of combining two diffs. The two diffs are from the *merge base* to each tip commit. Git combines the diffs, applies the combined result to the merge base, and makes a new commit with the result, with *two* parent IDs, one for each of the two input commits (the merge-base commit is implied by those two). – torek Aug 16 '17 at 21:45

1 Answers1

4

One: What does ' (which is in the top of D and E) mean?

The ' mean that the commits D' and E' have been altered from the original D and E by git's rebase functionality. So although they may end up with equivalent code changes (unless there are conflicts), they are not literally the same commits, precisely because they will at least have different history from D and E. In git, commits with different history are different by design, and they will have different hashes.

two: When should not I use $ git rebase? (also is it the same as git pull --rebase?)

When the result will be pushed to a branch that is already a shared remote, "shared" here meaning essentially that others have checked it out and have made at least local changes to it (or you are not sure whether others have done so).

From the git docs:

Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history.

Philippe
  • 28,207
  • 6
  • 54
  • 78
Will
  • 6,601
  • 3
  • 31
  • 42