As I work more and more with git and GitHub I have become really interested in the version control processes of individuals and teams for developing software.
Today, I am wondering about how much change is too much change for a single commit? What do you use to decide when to commit? When is it the right time for you to commit changes?
In developing software we are tasked with a variety of changes or fixes to make to an application. Sometimes it is just a typo or changing the color of a button. Sometimes we are tasked with hunting down a really ugly, difficult to reproduce bug that will take a few days to figure out and solve.
The ability to make commits with git allows us to pull the changes we make out of our application when needed. But, if the change is so drastic it can have serious consequences if the code is removed, especially when other code has come to depend on our changes.
How do you decide you have done enough change to a codebase that you should commit those changes? Is there a point for you when there is too much change for a single commit? How do you make that decision? Do you ever think about what would happen if this commit was rolled back and how the codebase would handle that when you make this decision?
Oldest comments (13)
I tend to do a lot of commits. I try to keep each commit focused on a single task. So, for instance, if I need to add error handling to something and improve the output formatting, that's two commits. I would work on one, commit it when it is working, and then work on the next thing. I feel like a commit should be a single, descriptive line and should describe a single code addition or modification. Just my personal approach.
I bet this works nicely too if you need to roll back to when things were working right if you start to see errors happening.
I do exactly this with an extra constraint which is that I try to leave tests green. It is not always possible, but when it is I feel it helps a lot with code review and with auto-review too.
Oh, and then I sqash it all together just before I merge my topic branch because I commit A LOT.
Committing and pushing acts partly as a form of backup for me, but when merging to something like a sprint branch I try to squash those commits so that the history is more about features than tiny changes.
That's usually what ends up happening to me, when my task is really big and there really aren't good intermediate steps that could warrant an actual commit.
If there are good steps in between, I think there are great benefits to be had from concise and short commits, that explain the reasoning of themselves in their long message. I don't know how many times I've done a git blame to find the commit of some piece of code, and then it was made as a side-task of something completely different, and nobody can explain, why the change was made.
The first line of my commits describes what the change will be once it's applied, and I try to keep these pretty well defined and under 100 chars or so.
That means there's a nice semantic limit on how much a commit can do, so while a single commit might add 100 media files or even reprettify the whole codebase, I'd split it up if it was doing two things that I couldn't fully describe in two short sentences.
This is a good delineation for when a change is ready for commit. If you describe it simply it is probably too much of a change to the codebase for one commit.
I commit every time I made a change and the application is still working properly, that way I can go back to a previous version that is working well if something go wrong.
This pretty much what I do. If I start a task and it breaks everything, then my next commit is when I get it functioning again. Then I push when I have a complete feature. I guess.
I like the idea of creating a safety net in case changes go wrong. Very cool.
I like to treat commits as the end of a task. I split a feature or bugfix into very small, actionable tasks, like creating a new entity,creating or refactoring a function,implementing or updating a new dependency, etc. Each one of those tasks will be a single commit, as it allows me to roll back to any point in time, and this atomicity also helps keep concise and clear commit messages, as only a few lines change, so it's easy to describe what the commit does in a few characters.
Once the feature is done or the bug is fixed, I squash rebase onto dev/master, keeping the feature/hotfix branch for the commits history for faster searching.
I like this. Treating commits like checking off a todo list is an interesting way to look at it. Do you actually list out the things to do somewhere?