Git is a Communication Tool
Historically there has been a number of complaints on the way git allows people to change history. There are continued discussions on using rebase, merge, and/or squash. I want to bring focus to the point of all these choices, communicating. I'm not looking at providing new suggestions, someone has already written about why you should do one thing or another.
Who might you want to be communicating with?
- Future self
- Other Developers
- QA member
- Project Management
What is it you might want to communicate?
- That a feature is complete (to the best of your ability at this time)
- This code change is needed to fix bug X
- I have this important documentation update
- I was doing some work and my editor decided to change these files and I don't know why.
- I don't like the formatting of this document, here is my recommendation
- I completed X, Y, or Z and think it is important to get these upstream for everyone to benefit.
- Can we please upgrade our visual studio project files to the latest version of .net?
Now as a developer, wouldn't it be great if this is actually how you developed your work? Nice clear goals, good discipline in only doing one thing, ignoring that bug you found because it isn't the task at hand? Well, no it wouldn't be good you'll forget about that bug, or you will be so busy documenting that it needs fixed you forgot where you were in your task, it's just much better to get those changes into the code base and move on. And this is why Git's history rewrite is so valuable.
When you're in the flow so much is being processed and so many exploration changes in that session that it may not be a good idea to backup and organize what you're doing. However all those things your are doing come back to create an overall collection of changes which need to be communicated. Your QA, Project Manager, and Client are going to want to know about that bug/edge case that you fixed and if you have an upstream you're dealing with, they will want that too.
Git allows you to keep working in the "programmer's flow" and clean up communication of the results after the fact, review what you changed, organize your changes, break up unrelated changes. I'm not great at this myself, but would like to strive to meeting these goals, and that is where it would be nice to have others to hold me accountable.
And I do completely understand that a change can be so ridiculously basic that it doesn't make sense to have a completely new commit for that single character change in documentation comments; well it is ridiculous until that point in time that you realize it would have been nice to have them separate (which doesn't always happen).