git rebase basics

Solution 1:

Let's start from the beginning. Here's a diagram of your original state:

A-B-C  (master, origin/master)
 \
  D-E-F-G-H-I  (next, origin/next)

When you checked out next and rebased next onto origin/master, it created 6 new commits after the two that are already on origin/master. These new commits have "master commit #2" (C in my diagram) as their ancestor, not their original ancestor where origin/master and origin/next diverged (A in my diagram), so their hashes will be different. I believe this is why you'll see that next has 8 different commits from origin/next: the 2 from origin/master and the 6 "rehashed" commits that were on origin/next.

After git checkout next ; git rebase -i origin/master, you should have this:

A-B-C  (master, origin/master)
 \   \
  \   D'-E'-F'-G'-H'-I' (next)
   \
    D-E-F-G-H-I  (origin/next)

You can see that next does have 8 commits that aren't on origin/next, and origin/next does have 6 commits that aren't on next. Granted this is just according to the SHA-1 hashes of the commits. The actual content should match very closely if you git diff origin/next next -- the diff should just show the changes from B and C (as labeled in the diagram).

When you do git pull --rebase while still on next, it fetches changes from the source (the remote origin/next) and rebases the current branch (next) onto that remote. This causes the changes that were in the next but not in origin/next to appear after origin/next on the new next branch. It should look like this:

A-B-C  (master, origin/master)
 \
  D-E-F-G-H-I  (origin/next)
             \
              B'-C' (next)

If this is what you wanted the history graph to look like, then you've succeeded.

However, I suspect you really wanted things to look like the middle diagram, especially if next is a feature branch where you're working on the next piece of the project and master is for stable code and small bug fixes. If so, then you should have done git push instead of git pull --rebase to make the remote reflect your version of history instead of the other way around.

Solution 2:

Start with the very simple steps for rebasing your branch with the master; Name;

git-rebase

Synopsis;

git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]
        [<upstream>] [<branch>]
git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]
        --root [<branch>]
git rebase --continue | --skip | --abort | --edit-todo

Description; Assume the following history exists and the current branch is "sample":

 A---B---C sample
         /
    D---E---F---G master

From this point, the result of either of the following commands:

git rebase master
git rebase master sample

would be:

A'--B'--C' sample
                 /
    D---E---F---G master

NOTE: The latter form is just a short-hand of git checkout sample followed by git rebase master. When rebase exits sample will remain the checked-out branch.

If the upstream branch already contains a change you have made (e.g., because you mailed a patch which was applied upstream), then that commit will be skipped. For example, running ‘git rebase master` on the following history (in which A’ and A introduce the same set of changes, but have different committer information):

A---B---C sample
         /
    D---E---A'---F master

will result in:

 B'---C' sample
              /
D---E---A'---F master

All these were the diagramatic understanding of the rebase process. Once you resolve the conflicts being found after typing git rebase master resolve the conflicts and type git add -u to add the changed codes to the repository. after that perform the command git rebase --continue and continue resolving the conflicts and and repeating the command ;

git add -u 

and

git rebase --continue 

until no conflicts being found. At last the final command will be ,

git push --force origin sample(your branch name)