git rebase and
git merge allow you to merge
Git branches. While
git merge is always a moving forward change approach,
git rebase has powerful history rewrite functions.
Here we take a look at its configuration, use cases and pitfalls.
In doing so,
git rebase moves a sequence of commits to a new base commit and
can be useful for Feature branch workflows workflows. Internally, Git
achieves this by creating new commits and applying them to the specified base;
so the same-looking commits from branches are entirely new commits.
The main reason for
git rebase is to maintain a linear project progression.
If the main branch has evolved since you started working on a feature branch,
you might want to keep the latest updates to the main branch in your feature
branch, but keep the history of your branch clean. This would have the advantage
that you could later do a clean
git merge of your functional branch into the
main branch. This clean history also makes it easier for you to find a
regression with regressions using Find regressions with git bisect. A more realistic scenario would
be the following:
An error is found in the main branch in a function that once worked without errors.
With the clean history of the main branch, Git log should allow for quick conclusions.
The published history should only be changed in very rare exceptional cases, as the old commits would be replaced by new ones and it would look as if this part of the project history had suddenly disappeared.
git rebase is also covered briefly in advanced/jupyter-config
and Feature branch workflows.
Rebasing dependent branches with
When you are working on a large feature, it is often helpful to spread the work over several branches that build on each other.
However, these branches can be cumbersome to manage if you need to overwrite the history in an earlier branch. Since each branch depends on the previous branches, rewriting commits in one branch will result in subsequent branches no longer being connected to the history.
Git 2.38 ships with a new
--update-refs option for
git rebase that will
perform such updates for you without you having to manually update each branch
and without subsequent branches losing their history.
If you want to use this option on every rebase, you can run
--global rebase.updateRefs true to make Git behave as if the
option is always specified.
Delete commits with rebase#
$ git rebase -i SHA origin/main
Interactive mode, in which your standard editor is opened and a list of all commits after the commit with the hash value
SHAto be removed is displayed, for example
pick d82199e Update readme pick 410266e Change import for the interface …
If you now remove a line, this commit will be deleted after saving and closing the editor. Then the remote repository can be updated with:
$ git push origin HEAD:main -f
Modify a commit message with rebase#
This can also be easily with
rebase by not deleting the line in your
editor but replace