Given the following commits on a feature/something-cool branch:
The git command git rebase -i A will let you squash B, C and D into a new commit E like this:
(Observe how the commit hash B, C and D are gone, replaced with E., This will be important for the next section)
This is especially useful to tidy up local commits with crude messages like fixed typo, whitespaces or unit test failures.
Remember that your colleagues (or anyone on the internet if your project is open source) often refer to git history to get more context of particular implementation.
Popular IDE comes with some sort of git blame feature so reader can understand when / where / why a particular implementation is done a certain way.
Alternatively, you can set your repo to do squash-on-merge strategy
But don't overdo it during active code review
Say your colleague leaves bunch of code review comments on your PR at commit E, and you push more changes to address them, they would want to know "what's changed since E", so avoid doing any rebase that rewrites E.
Bad example: E is replaced by F
Top comments (0)