Commit and push something every day
One of the significant changes that I've found and that's benefitted me whilst developing is to commit and push something every day.
It doesn't need to be a whole feature. It could be a new class with its passing tests, but it isn't used anywhere yet, so it won't affect the existing functionality, or it could be a new test for some existing functionality that was missing previously.
It could be a small refactor - renaming a variable or class name that makes some code easier to read or removing some commented-out code that isn't doing anything other than adding visual clutter.
It could be updating some documentation or writing a technical document; if you keep those in your version control repository, that would help you implement the following change or to make the documentation clearer for the next reader - whether that's you or someone else.
Committing something at least once a day creates a different mindset to "I'll write everything and push it when it's done".
It makes you break up large tasks into multiple smaller ones and set mini-deadlines for yourself. I used to do the same when I commuted to work on a train and had a task for a freelance project to complete before I arrived. I used to think, "What can I start, finish and commit before I get there?" instead of leaving something incomplete.
You don't need to push your change to mainline. If you use the "Ship, Show, Ask" approach then you could commit to a temporary branch that you either merge yourself once you know it passes the checks, or to show or get feedback from other team members.
Practicing this becomes a habit, and if you're doing test-driven development and committing after every passing test or refactor, you'll find yourself pushing numerous changes a day.
This became my normal approach instead of having long-lived feature branches or lots of unpushed local commits.
I much prefer making as small charges as possible and pushing them as often as I can.
- Oliver
