Small commits offer more safety than big ones in development.
We should be teaching teams to work in small slices. As part of that they should also be doing lots of their work in small quantities. This provides lots of benefits. Big is not always beautiful, or helpful.
You should be doing lots, and lots, and lots of small, or microcommits too. Each task should have many small, intentional commits. Pick a small goal, and then make a commit. The goal should be small: add the new component, update some libraries, add another test. Whatever. If you’re worried about losing your work, then you can also push your code to the remote server each time too.
All of your small commits build up into the bigger application. You just create more fine-grained opportunities to back up if necessary.
Easily roll-back to safety
Each of these provides a simple roll-back position for you. If you get stuck, just toss the uncommitted work, and you’re back where you started. No biggie. No reverts to worry about. Just back where you were 5, 10 or 15 minutes ago.
Small commits might feel like cheating because it is not a ‘whole’ thing that is being committed. It is just a step in the right direction. This is hard to overcome, but it does get easier.
I find the harder part is holding off on making a commit when you’re doing more taxing work such as updating libraries in javascript app. There are so many moving parts and points where it might feel ‘right’ to make a commit. Here I find holding off until you can rebuild the app successfully with all of the updated libraries is a must. A few times now I’ve found that having the goal kept me on track, and saved my work with a ‘git restore .’ command when it all went wrong. I was back where I needed to be and could try a different approach.
Guide your people in using small commits
Find a kata or use an exercise of your own where they can apply this idea in a small session. Then encourage them to apply it to their regular team work too.
As they are doing small commits remind them that they should also be regularly refactoring their work too. As they notice little things: repeated code, unhelpful variable names, and the like, they should fix these issues. They should not save them up for a ‘refactoring session’. That path just leads to pain, and agony as the work seems overwhelming. That is if it ever happens. Too many other deadlines, emergencies, etc tend to push them further away.
This post is part of a project pulling together my materials and ideas about Teaching Team Collaboration: the Human-Side of Software Development for software development to students.
If you’d like to be notified of future posts, then please sign up for more using the adjacent form. When you sign up, then I’ll send you a free copy of the collaboration rules as a PDF from the book. You can also follow me on LinkedIn
The ideas above are from my book 101+ Ideas to Improve Team Collaboration, which covers all of these little things that students can do to improve their collaboration. Also available via Kindle.