Commit early, commit often, and push often. In practice that means a commit every 30 to 60 minutes of focused work (never more than about 4 hours of uncommitted changes) and a push to a shared remote at least daily, in line with DORA's trunk-based development research.
Don't try to be a hero. It’s a best practice in modern software development to break up your work into small pieces and frequently integrate it with the rest of your team's work.
Good software development is playing small ball: go for singles and doubles, not home runs. Whatever your methodology, whatever the granularity of tasks in your project management tools, keep your commits small and your pushes frequent.
Plan ahead to break your work up into small unitary commits. You should always divide a task into subtasks that can be handled in uninterrupted stretches of work. That means probably 30-60 minutes on average, and no more than 4 hours. Avoid ever leaving uncommitted work. If you’re trying an approach that you think you might want to change in the future, do this on specific branch that you can throw away later; don’t just keep a big pile of uncommitted changes locally; or even keep a bunch of commits around on a local branch.
By unitary, I mean that each commit should try to represent one single step forward of work, that keeps the code base consistent: all tests pass, everything builds properly, code is compatible with all versions of data expected in any current environments. Whether you include the test with the functionality in a single commit is more of a judgment call. I generally recommend that you do, as this approach is compatible with the most extreme approaches of continuous deployment, and usually is not too much overhead.
Writing a big commit is taking a big risk. You might work for three hours, refactoring a bunch of stuff, to realize that you’ve taken a bad approach. There might be some useful work mixed together with that bad approach, but it’s very hard to unwind the two. If you split them up, you’d be able to cherry pick the good commits into a fresh branch.
Big commits are harder for others to review. While I often review pull requests as a single diff, it’s sometimes useful to view it in smaller pieces. If you have only a few big commits, you’re depriving your reviewers of this view.
Smaller commits result in a more interesting and readable commit log, providing more of the story of how you tackled the problem. With a big commit, the commit message is likely to end up vague and a lot of information about your sequence of work will be lost.
Splitting your work into small units fights procrastination. The smaller a task seems, the less daunting it is to start. And it will also help you get work done even in those 30 or 60 minute time slots between meetings, that otherwise get consumed by email or Slack.
You should push frequently to some non-local repo. The primary reason of this is that you should never have a single copy of your work. Why lose even half a day of work to theft or hard drive failure?
Another reason for this is to provide transparency about your ongoing work to your team. Putting your work out early and often, where teammates can see it in a tool like GitHub, promotes transparency, and occasionally someone on your team might notice something important even before you’re ready for a pull request. Maybe you’re spending time duplicating work, taking a bad approach, etc. Transparency lets others help you!
Analytics tools can only see what you push, too. Worklytics, for example, reports GitHub metrics such as pull requests merged, commits per pull request and review comments for teams, never for individuals, from pushed work only.
Ultimately, this goes for pull requests as well. Keep your pull requests small, so the discussion is more focused and reviewers can hold the whole things in their head. Reviewing a pull request should take minutes, not hours.
Commit every time you finish one small, working step, usually every 30 to 60 minutes of focused work. Avoid going more than about 4 hours without a commit. Each commit should leave the code building and the tests passing.
It means saving your work to version control in many small commits instead of one large one at the end. Small commits are easier to review, to revert, and to cherry-pick into a new branch if part of your approach turns out to be wrong.
A commit records a snapshot of your changes in your local repository. A push sends your commits to a remote repository, such as GitHub, so they are backed up and visible to your team. Until you push, your commits exist only on your machine.
Push at least once a day, and more often when you finish meaningful work. Pushing often means you never have a single copy of your work, and it lets teammates spot problems early. DORA's research on trunk-based development recommends merging into trunk at least once a day.
Small enough that a reviewer can hold the whole change in their head and review it in minutes, not hours. If a pull request covers several unrelated changes, split it into separate pull requests.
