Git Rebase Command

1. Using Rebase to Merge

Rebasing is the process of moving a branch to a new base commit.
Rebasing really is just moving a branch from one commit to another.

git rebase <base>

 Rebase the current branch onto <base>, which can be any kind of commit reference (a branch name, a tag). You have two options for integrating your feature into the master branch:
Merging directly or rebasing and then merging.
The former option results in a 3-way merge and a merge commit, while the latter results in a fast-forward merge and a perfectly linear history.

 Rebasing is like saying, “I want to base my changes on what everybody has already done.”

 git checkout dev

 git pull

 git checkout new-featuregit rebase dev

This moves new-feature to the tip of master, which lets us do a standard fast-forward merge from master. Rebasing re-writes the project history by creating brand new commits for each commit in the original branch.

2. Comparing with Using Merge

git merge master feature

or

git checkout feature git merge master

This creates a new “merge commit” in the feature branch that ties together the histories of both branches.

If master is very active, this can pollute your feature branch’s history quite a bit, it can make it hard for other developers to understand the history of the project.
3. Using Rebase to Squash Commits

git rebase -i HEAD~N

The ~N means rebase the last N commits.

git rebase -i <after-this-commit> 

must be launched with as argument the last commit you want to retain as-is.
Normally, use r(Edit the commit message) or f(Fixup, squash and discard the commit message) in the edit window.

Then, to push the new squashed commit.

git push --force

Since the changes are already there, we have to use "--force" here.
Check git log to see some commits are gone, and a new squash commit created.

https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase
https://www.atlassian.com/git/tutorials/merging-vs-rebasing