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.
Keep Your Commits Small. 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.
Frequent Pushes. 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. Whether you’re just using something with a source control viewer like GitHub, or a feed in a tool like Worklytics, putting your work out early and often makes sense. It 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!
Image: Worklytics activity feed promotes transparency on work completed across all of your tools
A cloud tool such as Worklytics that shows your work to the rest of your team can only see what you push to a remote repo!
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.]]>
