When do you use git rebase instead of git merge?

 

When is it recommended to use git rebase vs. git merge ?

Do I still need to merge after a successful rebase?

Short Version

  • Merge takes all the changes in one branch and merges them into another branch in one 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?

    Merge

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

    • Rebase

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

    • It's simple, with rebase you say to use another branch as the new base for your work.

    If you have for example a branch master and you create a branch to implement a new feature, say you name it cool-feature , of course the master branch is the base for your new feature.

    Now at a certain point you want to add the new feature you implemented in the master branch. You could just switch to master and merge the cool-feature branch: 

    $git checkout master
$git merge cool-feature

    but this way a new dummy commit is added, if you want to avoid spaghetti-history you can rebase : 

    $git checkout cool-feature
$git rebase master

    and then merge it in master : 

    $git checkout master
$git merge cool-feature

    This time, since the topic branch has the same commits of master plus the commits with the new feature, the merge will be just a fast-forward.

    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 (ie: "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

    rebase1

    we get by rebasing:

    rebase3

    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.
    • 链接地址: http://www.djcxy.com/p/1360.html

    上一篇: 如何删除一个git远程标签？

    下一篇: 你什么时候使用git rebase而不是git merge？