rebase vs merge

merge

It will have an extraneous merge commit every time you need to incorporate upstream changes. If master is very active, this can pollute your feature branch’s history.

rebase

The major benefit of rebasing is that you get a much cleaner project history. First, it eliminates the unnecessary merge commits required by git merge. Second, as you can see in the above diagram, rebasing also results in a perfectly linear project history.

(warning but less important: re-writing project history can be potentially catastrophic for your collaboration workflow. And, less importantly, rebasing loses the context provided by a merge commit—you can’t see when upstream changes were incorporated into the feature.)

happy path, “fast-forward”

git pull
is shorthand for git fetch followed by git merge FETCH_HEAD. If any of the remote changes overlap with local uncommitted changes, the merge will be automatically cancelled and the work tree untouched

merge conflicts, “not fast-forward”

git pull --rebase
it runs git rebase instead of git merge. Rebasing Deletes Merge Commits!

If you want the changes to be added along with the changes from remote, commit the changes git ci and do git pull --rebase. This will pull all changes from remote and then add you local commit, sometime this method will introduce some merge conflicts, which can be resolved easily if the chages are really small.

git pull --rebase is to record all of your committed changes back to the point at which your local repository diverged from origin, and then re-play your changes on top of what you pulled from origin. You may get merge conflicts, which you will have to resolve before the rebase can continue, but when you’re all done you will have your changes in a form that’s ready to push without getting a “not fast-forward” error.

best practice

(1). go back to master

• git fetch

downloads the latest from remote without trying to merge or rebase anything.

• git fetch --all

only fetches remote changes from all branches to local repository and it does not affect working directory.

(2). go back to your branch git checkout feature

• do git rebase master

note: do not do git merge master here, because this will create extra commit. (you can condense git checkout feature and git merge master to a one-liner git merge master feature)

(3). go back to master

• git merge -
  note: "-" means previous branch, i.e.,feature branch.

this should be fast-forward

(4). still in master

• git ci
• git push origin master

note: "origin" is remote, "master" is branch.

In case it fails, then

• git push --force