Git is a free and open supply distributed model management system designed to deal with every little thing from small to very giant initiatives with velocity and effectivity. It is an important instrument in an open supply developer’s toolkit.
This article covers why and learn how to use the git rebase --interactive
(-i
for brief) command. This is taken into account an intermediate Git command, however it may be very helpful when you begin working with giant groups.
This command is without doubt one of the strongest in Git. The git rebase
command helps you handle a number of commits, together with:
- Flatten (or squash in Git terminology) a number of commits in order that they appear like they have been all executed without delay
- Delete one of many commits
- Split one commit into two
- Reorder the commits
Yes, the git rebase
command can rewrite your repository’s commit historical past by rearranging, modifying, and even deleting commits. So let’s get began!
Helpful directions within the rebase message
The git rebase -i
interface is, as its lengthy kind --interactive
flag implies, an interactive interface. It supplies an inventory of commits, and then you definitely select what actions you need Git to tackle every of them. Taking no motion is a sound selection, however no less than one commit should be marked because the one to squash, or the rebase is functionally meaningless.
- p, decide — Pick this commit to maintain.
- e, edit — Edit this decide to amend the commit message.
- r, reword — Use this commit, but in addition edit it.
- s, squash — Squash this commit right into a earlier commit. When performing a
git rebase -i
, you should have no less than one commit marked as squash. - d, drop — Delete this commit.
Squashing commits
Suppose you’ve two commits, and also you wish to squash them into one. This is achieved by utilizing git rebase -i HEAD~2
(that is two commits out of your present place) command and by placing the phrase squash earlier than the commit.
$ git rebase --interactive HEAD~2
Running this command offers you an inventory of commits in your textual content editor that appears one thing like this:
decide 718710d Commit1.
decide d66e267 Commit2.
If you wish to make a single commit from two commits, then you need to modify the script to look this:
decide 718710d Commit1.
squash d66e267 Commit2.
Finally, save and exit the editor. After that, Git applies all of the adjustments and opens an editor to merge the 2 commits:
# This is a mixture of two commits.
# This is the first commit message:Fuse smoke take a look at versioning.
# This is the commit message #2:
Updated the code.
# Please enter the commit message to your adjustments.
Saving this outcomes a single commit that introduces the adjustments of two earlier commits.
Reordering commits
Suppose you’ve three commits, and also you wish to change their order such that Commit3 is first, Commit2 is second, after which third is Commit1. Run git rebase -i HEAD~3
to make this occur:
$ git rebase --interactive HEAD~3
This script is opened in your editor:
decide 8cfd1c4 Commit1
decide 718710d Commit2
decide d77e267 Commit3
Modify the script like this:
decide d77e267 Commit3
decide 718710d Commit2
decide 8cfd1c4 Commit1
When you save and exit the editor, Git rewinds your department to the mother or father of those commits, and applies d77e267, then 718710d, after which 8cfd1c4 because the commit numbers aren’t matching.
Delete a commit
Suppose you’ve two commits and wish to do away with the second. You can delete it utilizing the git rebase -i
script.
$ git rebase -i HEAD~2
This script is opened in your editor:
decide 8cfd1c4 Commit1
decide 718710d Commit2
Place the phrase drop earlier than the commit you wish to delete, or you may simply delete that line from the rebase script.
decide 8cfd1c4 Commit1
drop 718710d Commit2
Then save and exit the editor. Git applies the adjustments and deletes that commit.
This may cause merge conflicts in case you have many commits later within the sequence that rely upon the one you simply deleted, so use it rigorously. But you’ve an choice to revert the adjustments.
Rebase with warning
If you get partway via a rebase and determine it is not a good suggestion, use the git rebase --abort
command to revert all of the adjustments you probably did. If you’ve completed a rebase and determine it is flawed or not what you need, you should use git reflog
to recuperate an earlier model of your department.
Rebasing is highly effective and may be helpful to maintain your repo organized and your historical past clear. Some builders prefer to rebase the principle department in order that the commits inform a transparent story of improvement, whereas others favor for all commits to be preserved precisely as they have been proposed for merging from different branches. As lengthy as you suppose via what your repo wants and the way a rebase may have an effect on it, the git rebase
command and the git rebase -i
interface are helpful instructions.