The most significant new feature in the latest Git release, Git 2.22, enables rebasing non-trivial branch topologies, e.g., those including merges, without flattening them while also allowing to use interactive rebase features.
Rebasing a commit is a great way to keep your Git history linear when merging a feature branch after its base branch, e.g. master, has changed. In such cases, Git's standard approach to make sure no changes in the two diverging branches go lost is to merge master on to the feature branch before trying to merge it back to master. This gives you the opportunity to resolve any merging conflicts Git is not able to resolve on its own, and additionally will create a commit topology of your master branch that explicitly represents the merge operation if a 3-way merge is required.
Contrary to merging, rebasing a commit on top of a diverged master branch will just pretend you started working on the branch leading to that commit from the current tip of master -- provided no conflicts are found. In such cases, your master branch history will show no traces of the fact you created a branch and then merged it back to master. Your whole history will appear just linear.
The latter approach falls short in cases where the feature branch you want to rebase itself generated a complex topology including sub-branches and merges. To fix that, the new --rebase-merges option will now replay a set of commits on top of a new base and preserve the rebased branch topology. In addition, it also includes interactive rebasing features such as renaming, squashing, reordering, etc. Conceptually, doing a rebase-merges using interactive features is (almost) equivalent to doing a preserve-merges rebase followed by rebase -i. In fact, the preserve-merges options has been deprecated in Git 2.22 in favour of rebase-merges. You can find a thorough discussion of the algorithm behind rebase-merges on Stack Overflow.
Support for rebase-merges is not the only change in Git 2.22, which contains many new features and bug fixes. Among those we highlight:
-
You can define new configuration variables for name and email of
authorandcommitterwhere more granularity is required than what allowed byuser. -
You can get the name of the current branch by executing
git branch --show-current. -
If you checkout a directory from a branch and your current tree includes new tracked files, Git by default will not touch the latter, so you will end up with a mix of files from the checked-out branch and your current branch. You can now give the
--no-overlayoption togit checkoutto make sure tracked files are deleted, and re-created, as necessary.
Git 2.22 includes many more changes than what can be covered here, so make sure you read the official release notes for the full detail.
