When it comes to source control, us developers are an interesting bunch. I have seen a few different styles of committing and using source control. We pick whatever works for us without really giving it any thought.
It actually dawned on me the other day after a fellow developer commented on my workflow style with Git that perhaps some developers out there are making it not only difficult for themselves, but their team and organisation as well.
Commit early, commit often
As a rule of thumb, if your commit messages are any longer than one or two sentences maximum, you are not committing often enough or if they are shorter, then you are committing too soon.
Committing frequently gives you the advantage of troubleshooting commits that have broken something in the build process and being able to revert back without losing too much work. You also get the added advantage of seeing changes easier without wading through a file with 1000 line additions.
Feature branches and fallacies
If you are using Git (and you should be, SVN is old news) then if your feature is going to take an extended period of time, you should be working on a separate feature branch and merging in the master branch whenever there are changes. Doing this will mean the chances of running into a merge conflict are pretty slim.
The advantage of a feature branch separate from master is that you are not breaking anything, you can commit often, merge in the checked-in code of others and push your code to your branch thus keeping it safe and reducing the risk of losing your work.
The old excuse of I do not want to break the build does not work any more. You should never be working off your master branch unless it is a small fix that will literally take you a minute or two. Even then, it is good practice to use separate branches.
Another benefit of feature branches is you can work on multiple tickets/cards at once, each in their own separate branches independent of one another. So if priorities change, you do not need to worry about stashing or undoing your changes to make a quick fix elsewhere.
Just recently I ran into this scenario. I was working on a card for fixing an AngularJS service interfacing with an API, adding in a logout event and then the priorities changed. As frustrating as it was, I did not have to undo any code, because I was working on a separate branch and so, I just left it and created a new branch for the other card I was assigned.
I recommend using Atlasssian Sourcetree for working with Git, as it gives you the benefit of being able to stage specific chunks of code within a file, so you can commit multiple changes in a file by staging particular chunks per commit.
Never leave without pushing
The number one rule regardless of your source control workflow is pushing your code before you leave the office or wrap up for the day. If you do not push your code to the central repository, as far as anyone else is concerned, it does not exist.
Always assume the worse. Anything that can go wrong, will go wrong. So mitigate the risk by considering a push every time you make a commit or small block of commits.
My workflow is always hit CMD+S / CTRL + S whenever I make a file change. Whenever I have finished a line of code, even for a WIP feature, I commit and push. Because I am on a separate feature branch, I have no excuse to not push as often as possible.
Conclusion
How often should you commit?
All of the time. Push as frequently as possible as well. You never know when you could lose your code.
How do I prevent breaking a build or breaking code?
Use a separate branch independent on the main branch which should not be touched. Also ensure that you are merging in changes as they come from the upstream branch to prevent merge conflicts.
