Git – Can you do something with rebase that you can't do with merge?

Every time I’ve tried a rebase, I’ve been involved in an infinite loop of unsolvable conflicts. Before resolving x conflict, y conflict appeared, and then x conflict again, and so on.

The point is that (apparently) merge, or even cherry-pick, provide the same functionality you could expect from rebase, don’t they? If not, which is the usefulness of rebase?

  • How do you rebase the current branch's changes on top of changes being merged in?
  • Reorder git commit history by date
  • git rebase - what's the difference between 'edit' and 'reword'
  • How git-merge and git-rebase behave with a topic branch forked off of another topic branch?
  • How can I rebase part of a branch to the master branch?
  • Recommended git workflow for test and production instances
  • Forgotten rebase interactive - git
  • Rename a merged commit without losing that commit's parents
  • 2 Solutions collect form web for “Git – Can you do something with rebase that you can't do with merge?”

    rebase rewrites history. It does way more than merge or cherry-pick — a very advanced tool that takes practice (and can be dangerous, since it rewrites history…be careful with git push -f). When rebase is used similarly to merge, the process is quite distinctively different.

    git fetch origin && git merge origin/master:

    • download changes from origin
    • merge changes on top of local branch
    • resolve conflicts and commit

    git fetch origin && git rebase origin/master:

    • download changes from origin
    • reset local branch to a common point in history (a commit that both local/remote repos share)
    • fast forward to origin
    • apply your commits on top of new commits one by one
    • resolve conflicts and commit for each local change

    The big advantage of rebase in this situation is that you’re just updating your local repo and applying your commits on top and there won’t be any “gross” merge commit saying “hey, I just merged this stuff in.” The downside is that if you have a ton of commits that modify the same files, you will have to resolve the conflict over and over again since there is no “gross” merge commit.

    But again, rebase is a really advanced tool meant for rewriting history. You can amend previous commit titles, delete commits in the past, squash many commits together, etc. Read up on it!

    I use rebase in only one case. The case:

    1. I have master branch with current version of an app.
    2. I create feature-branch for a new feature
    3. I make a few commits in feature-branch
    4. I make a few hot commits in the master branch
    5. Now I want to have that commits in the feature-branch and I do rebase in this case.
    6. I done with the feature-branch and I just merge it into master.

      git checkout master
      git checkout feature-branch
      git commit -am "feature commit #1"
      git commit -am "feature commit #2"
      git commit -am "feature commit #3"
      git checkout master
      git commit -am "hot fix"
      git checkout feature-branch
      git rebase master
      git commit -am "i'm done"
      git checkout master
      git merge feature-branch

    This allows me to be on the top of master branch and have a clean git history.

    Git Baby is a git and github fan, let's start git clone.