There are a lot of different approaches here. Some of it stylistic. If you've ever played an Elderscrolls game: do you repeatedly mash quicksave save every m

There are a lot of different approaches here. Some of it stylistic. If you've ever played an Elderscrolls game: do you repeatedly mash quicksave save every milestone save every x minutes of play I'm sure amongst the people who code and play RPGs this will surface the different attitudes to this. From a workflow perspective there are commits per feature/story, or commits per working unit of code (maybe TDD influenced), commit per decision, commit per unit time (commit at lunch or end of day) Interestingly, with git you can kind of have your cake and eat it and achieve a mixture of all of those through rebasing. From a professional point of view your git history is a valuable artifact of your development so having a clear and well documented history is a good working practice as some teams like git being a source of truth for a project. Small and tasteful commits can be valuable in taking a newcomer through a codebase as some people like to read a codebase from its git history as it can be quite a useful contextual annotation of the evolution of the codebase - HEAD is only a projection of the final state of that and loses a lot of the journey. So there are git commits for the reader and there are git commits for the writer. The workflows may not always be the same but they also don't necessarily need to extremely tightly coupled. Of course if you can find a happy medium of the two then you're winning. EDIT In the case of a hiring code test, the projects are (hopefully) small so sometimes the commits may feel a little contrived, but so is the whole exercise of a coding test. That said if you personally value clean git history as something in your own ideals of code quality, it is worth communicating that through smaller commits in your code test for your candidate employer. Much like unit testing or documentation are signals of quality outside of the code itself. These are part of the day job as much as slinging code or churning out features are (depending on the role)