3

Suppose I am not using branch (I am working on a local master branch, with origin to be master branch on remote server). Wondering what is the function of the command? My confusion is sometimes I see people using this command to merge local changes (with changes on master remote server branch) successfully without using branch, but I could be wrong but I think rebase only works when you are working on a branch (master) and merge with some other branch?

git rebase -i origin/master
Lin Ma
  • 9,739
  • 32
  • 105
  • 175
  • 1
    Your question begins with an assertion that's not true: With Git, you're pretty much always using a branch. In this case you're using branch `master`. There is almost nothing special about `master`: it's just another branch. The main reason `master` *seems* special is that it's the branch Git first creates when you create a new, empty repository. This means almost every repository has a `master` (because, to *not* have one, you must do extra work). – torek Oct 04 '16 at 08:11
  • @torek, nice comments and vote up. Do you know if `git rebase` automatically pull remote master most recent changes to local origin/master before merging the changes? Or I need to manually pull by myself before using rebase, if I want to rebase with most recent changes on remote master branch? Thanks. – Lin Ma Oct 04 '16 at 22:23
  • 2
    The `git rebase` command *does not* first fetch. The `git pull` convenience command does two things: first, it runs `git fetch`. Then once the fetch finishes successfully, `git pull` runs either `git merge` or `git rebase`. The problem here is that you must choose in advance which to run (merge or rebase) and it's not until after you've fetched that you can tell for certain which action is best. For most people, most of the time, rebase is better; but `git pull` defaults to doing `git merge`. I therefore recommend avoiding `git pull` entirely: just stick with `git fetch`. However, (continued) – torek Oct 04 '16 at 22:38
  • 2
    ... if you find using `git pull` more convenient than running two commands, remember that `git pull --rebase` means "first fetch, then rebase". You can also set up your configuration so that `git pull` defaults to doing `git rebase` (but I still prefer to just do separate fetch-then-rebase, myself). – torek Oct 04 '16 at 22:39
  • @torek, thanks for all the comments, do you think using `git fetch` then `git rebase` is good combination? – Lin Ma Oct 04 '16 at 23:47
  • 2
    yes, I usually rebase after fetch brings in new commits. – torek Oct 04 '16 at 23:51
  • @torek, thanks, and what is the benefit of fetch + rebase, comparing to pull (including merge operation as 2nd step)? – Lin Ma Oct 04 '16 at 23:56
  • 1
    If you want to compare merge vs rebase, see any of many existing SO questions (e.g., http://stackoverflow.com/q/804115/1256452 and http://stackoverflow.com/q/16666089/1256452). – torek Oct 05 '16 at 00:01
  • @torek, why not add a reply? I will mark it as answer to benefit other people. – Lin Ma Oct 05 '16 at 00:43
  • @torek, take time studied the post and really informative, if I just need to integrate my change with other changes, and I do not quite care about commit history, I think `merge` and `rebase` serve the same purpose? – Lin Ma Oct 05 '16 at 04:22
  • 1
    That, as rethab noted, is a separate question. (Again, you should browse through existing questions and answers to see if they tell you enough, before asking your own.) – torek Oct 05 '16 at 05:08
  • @torek, sure thumb up. :) – Lin Ma Oct 05 '16 at 05:08

1 Answers1

3

origin/master is a branch just like master. It is basically tracks whatever contents are on the remote master.

When you run git fetch from master it will fetch all commits from your remote master and put it onto origin/master. If you then run git rebase -i origin/master, this happens:

  • all your commits that were not on origin/master are temporarily put away
  • your master is updated with whatever is on origin/master
  • your commits are replayed on top of your updated master

So, if you first manually fetch and then rebase, thats basically manually doing what git pull --rebase would do.

As an aside, you can also rebase onto your own branch, for example: git rebase HEAD~2. This will let you re-order (or otherwise edit) the commits on your current branch.

rethab
  • 7,170
  • 29
  • 46
  • Thanks rethab for the excellent explanation, and vote up. For your comments, "your commits are replayed on top of your updated master", do you mean my commits on local branch origin/master are replayed on local branch master? – Lin Ma Oct 04 '16 at 05:52
  • 1
    I have explained rebase here in my answer: http://stackoverflow.com/questions/39794674/how-to-bring-a-pull-request-to-a-state-of-can-be-merged-automatically/39794996#39794996 – prabodhprakash Oct 04 '16 at 08:11
  • 1
    you're commits won't be on `origin/master`. After the three steps I described above, the state of your `master` is: `origin/master` + your local commits that you made on master. – rethab Oct 04 '16 at 09:13
  • Thanks rethab, studied the other post you did and it is really clear and awesome description! Vote up. One more question on the 2nd step, when I execute `git rebase -i origin/master`, will git pull most recent change from remote master to my local origin/master branch -- and then based on the most recent remote master changes, apply them on my local master? Or `git rebase -i origin/master` just fetch commits from my local origin/master branch (without pull remote master for most recent changes) on my local master change? Thanks. – Lin Ma Oct 04 '16 at 22:21
  • (cont'd) from your description, it seems git rebase never automatically pull remote master most recent changes to local origin/master? – Lin Ma Oct 04 '16 at 22:22
  • 1
    indeed. rebase is purely local. Fetch fetches. – rethab Oct 05 '16 at 04:18
  • Thanks rethab, if I just need to integrate my change with other changes, and I do not quite care about commit history, I think `merge` and `rebase` serve the same purpose? – Lin Ma Oct 05 '16 at 04:23