By a very simple example and practice
Real programmer life
Imagine you are working on the branch
feature-X and you have 2 commits:
And then, you realize that in the first commit, you have a typo mistake. Then you create a new commit to fix the typo, but the problem is you don’t want to have a dedicated commit to fix a mistake from another commit and the added commit does not intend to add any value to your current feature.
You can easily to fix it by using
git commit --fixup and
git rebase --autosquash . Let’s me show you what are they and how to use them:
git commit — fixup
git commit — help
Basically, the commit that you are going to create to fix the typo, instead of you use
git commit -m "fix type" ,
You should mark it as the fixup for the first commit.
git commit --fixup=first-commit-id
You can check the result by:
git log --oneline
You can see the indicator
fixup! and the following message of the first commit.
git rebase — autosquash?
git rebase — help
And now is the time to squash commits with the command:
git rebase -i upstream-branch --autosquash
*upstream-branch* is the target branch that you want to merge your feature.
Git will show you in an editor the result like this:
Notice that the fixup commit is placed right after the first commit
You save the editor and complete. You can check the result by
git log --oneline
You can see IDs of your commits may be changed because basically, you have modified the content of the commits.
Is that all?
Of course, no. There are some more applications of fixup commits. Especially when you ask for review you code. After the first reviews, reviewers would happy if you use fixup commits to modify your pull requests, and they won’t need to review from the start but focus on the adding fixup ones. It saves time for people and then saves money for companies. For example:
And after the reviewing process done, you can rebase with autosquash before merging your PRs.
If you like the post, you can buy me a Coffee at https://ko-fi.com/tlcong