When does one use git rebase vs git merge?
Does one still need to merge after a successful rebase?
+2
A:
Short version: - Merge says take all the changes in one branch and merge them into another branch in one big commit - Rebase says I want the point at which I branched to move to a new starting point
So when do you use either one. Let's say you have created a branch for the purpose of developing a single feature. When you want to bring those changes back to master, you probably want merge (you don't care about maintaining all of the interim commits). A second scenario would be if you started doing some development and then another developer made an unrelated change. You probably want to pull and then rebase to base your changes from the current version from the repo.
Rob Di Marco
2009-04-29 20:38:30
By the sound of your answer, it almost seems that one must still merge even after a rebase. If I have a master branch, and a master-feature branch. I will create a feature in master-feature, then want to have that feature available in master. If I rebase, it'll take all say, N commits I made in master-feature and show the history in master. What's the point of merging after a rebase?
Coocoo4Cocoa
2009-04-29 20:57:35
merge after rebase is a trivial fast forward without having to resolve conflicts.
obecalp
2009-04-30 19:32:37
@obelcap: Indeed, this is kind of the idea: you take all the problem-conflict in *your* environment (rebase master within your new-feature branch), and then co master, merge new-feature: 1 pico-second (fast-forward) if master had no evolutions
VonC
2009-04-30 21:29:14
Rebase is also nice because once you do eventually merge your stuff back into master (which is trivial as already described) you have it sitting at the "top" of your commit history. On bigger projects where features may be written but merged several weeks later, you don't want to just merge them into the master because they get "stuffed" into the master way back in the history. Personally I like being able to do git log and see that recent feature right at the "top." Note the commit dates are preserved - rebase doesn't change that information.
schof
2009-09-03 14:11:07
A:
I have a master branch and a spec-pass branch that are radically different. If I checkout master and go git status I am told I am ahead of origin/master by 2 commits, but that is due to an error a maligned git reset and git revert HEAD on master. All want to get, is that HEAD of master becomes HEAD of my specs-pass branch. How can I do that?
I guess I must first revert 2 steps on master so I am not ahead and then do a git rebase specs-pass followed by a merge?
Kristian Mandrup
2010-07-11 15:49:41