Rebasing

Syntax

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-tod

Parameter	Details
–continue	Restart the rebasing process after having resolved a merge conflict.
–abort	Abort the rebase operation and reset HEAD to the original branch. If branch was provided when the rebase operation was started, then HEAD will be reset to branch. Otherwise HEAD will be reset to where it was when the rebase operation was started.
–keep-empty	Keep the commits that do not change anything from its parents in the result.
–skip	Restart the rebasing process by skipping the current patch.
-m, --merge	Use merging strategies to rebase. When the recursive (default) merge strategy is used, this allows rebase to be aware of renames on the upstream side. Note that a rebase merge works by replaying each commit from the working branch on top of the upstream branch. Because of this, when a merge conflict happens, the side reported as ours is the so-far rebased series, starting with upstream, and theirs is the working branch. In other words, the sides are swapped.
–stat	Show a diffstat of what changed upstream since the last rebase. The diffstat is also controlled by the configuration option rebase.stat.
-x, --exec command	Perform interactive rebase, stopping between each commit and executing command

Keep in mind that rebase rewrites the repository history.

Rebasing commits that exists in the remote repository could rewrite repository nodes used by other developers as base node for their developments. Unless you really know what you are doing, it is a best practice to rebase before pushing your changes.

Found a mistake? Have a question or improvement idea? Let me know.

Table Of Contents