At first glance, it might not seem like there are many reasons to care about your git history. I first had to care about it because someone made me to. Ask yourself: Are your GIT commits readable?
Git commits are your code's fingerprints. Any code you contribute today, a year from now, you'll be glad for a clear, meaningful commit statement, and it will make your other developers' life simpler.
When development takes place over a prolonged period of time (weeks or months), commits will build up. Even developers' Git repositories may become disorganized and unwieldy after a while.
There comes a point where a Git cleanup must happen. What's the big deal about making your git history as legible as possible?
- For the sake of clarity in understanding the chronological sequence of your repository's commits.
- Simply put, you need to know exactly when and what was altered.
- Finding changes that may have created issues is easier, and they may be reverted if required.
- To use your CI/CD system to roll out any change made to your development branch.
The final commit history will look like this.
For the sake of tidiness, the two commits from before (2e75f95)—(840a8f0 and de96d75)—should be merged into a single one.
To begin, we run git rebase -i HEAD3 to revert to the most recent three commits.
Doing this will open an editor on your sonole, which looks like
All subsequent commits should be squashed when the initial rewording of the first commit is complete.
If there are any changes in a commit that you do not want to skip, keep them as they are.
So, after the changes the commit history in editor will look something lke this.
Notice how the 2e75f95 is reword (r) and the other two (840a8f0 and de96d75) are squashed (s) .
Save and exit the editor and finally do the git force push - git push --force
This is how the final commit history will looks
