Rebase is quite complex and it alters/rewrites the history of a repository. Please make sure you understood its principles before using it (for general hints where to find more information about Git and rebasing see the section called “Reading Guide” and especially the section called “git-rebase(1)”).
The Rebase dialog will be shown.
Rebasing commits takes places from the bottom of the list to the top (in ascending order of the ID column). For example,
squash means that the commit gets squashed/combined with the previous commit(s) which are located below in the list (with a lower ID).
Instead of setting
squash by using the context-menu, you can also use the following keys: space: shifts the state, s:
There is a button that swaps branch and upstream. Assume you are currently working on
master branch, and wish to rebase
feature branch onto
master. Instead of switching to
feature in advance, select the commit of
feature in log list, → and click this swap button. TortoiseGit's rebase moves
master directly, then cherry-picks the commits. This approach touches fewer files and runs faster.
When preserving merge commits, re-ordering commits cannot be handled properly in all cases, see in known bugs of vanilla git rebase: the section called “git-rebase(1)”.
Although major merge work is done by git automatically while rebasing, a conflict may happen during rebase (i.e., a file was modified in both branches, the one you are rebasing one and the on which you are rebasing), please see the section called “Resolving Conflicts” on how to resolve conflicts.
Please note, that "REMOTE"/"theirs" in the conflict editor refers to the changes of the branch you rebase onto and "LOCAL"/"mine" to your version on the branch which you are rebasing.