Git 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-todo
Parameters
| 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 |
Remarks
Please keep in mind that rebase effectively 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.
