git rebase vs git merge

When does one use git rebase vs git merge?

Does one still need to merge after a successful rebase?

From stackoverflow

• See: http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions

• 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.

• To complement my own answer mentioned by TSamper,

  • a rebase is quite often a good idea to do before a merge, because the idea is that you integrate in your branch Y the work of the branch B upon which you will merge. But again, before merging, you resolve any conflict in your branch (i.e.: "rebase", as in "replay my work in my branch starting from a recent point from the branch B)
    If done correctly, the subsequent merge from your branch to branch B can be fast-forward.

  • a merge impact directly the destination branch B, which means the merges better be trivial, otherwise that branch B can be long to get back to a stable state (time for you solve all the conflicts)

  ---

  the point of merging after a rebase?

  In the case that I describe, I rebase B onto my branch, just to have the opportunity to replay my work from a more recent point from B, but while staying into my branch.
  In this case, a merge is still needed to bring my "replayed" work onto B.

  The other scenario (described in Git Ready for instance), is to bring your work directly in B through a rebase (which does conserve all your nice commits, or even give you the opportunity to re-order them through an interactive rebase).
  In that case (where you rebase while being in the B branch), you are right: no further merge is needed:

  A git tree at default when we have not merged nor rebased

  

  we get by rebasing:

  

  That second scenario is all about: how do I get new-feature back into master.

  My point, by describing the first rebase scenario, is to remind everyone that a rebase can also be used as a preliminary step to that (that being "get new-feature back into master").
  You can use rebase to first bring master "in" the new-feature branch: the rebase will replay new-feature commits from the HEAD master, but still in the new-feature branch, effectively moving your branch starting point from an old master commit to HEAD-master.
  That allows you to resolve any conflicts in your branch (meaning, in isolation, while allowing master to continue to evolve in parallel if your conflict resolution stage takes too long).
  Then you can switch to master and merge new-feature (or rebase new-feature onto master if you want to preserve commits done in your new-feature branch).

  So:

  • "rebase vs. merge" can be viewed as two ways to import a work on, say, master.
  • But "rebase then merge" can be a valid workflow to first resolve conflict in isolation, then bring back your work.
  Coocoo4Cocoa : 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?

  obecalp : merge after rebase is a trivial fast forward without having to resolve conflicts.

  VonC : @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

  schof : 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.

• 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?