Git for a solo developer [duplicate]

Question

This question already has answers here:

When is a version control commit too large? [closed] (19 answers)

How big should a single commit be? [duplicate] (6 answers)

Closed 7 years ago.

I'm a developer working on a Wordpress project. I work on this alone and I want to improve the way I use Git but I don't know where to start.

Currently, I'm using git to commit all of the work that I've done for the day as long as that specific work is done. Here are some instances where I commit a specific work:

• A specific feature whose code can be written within a day
• A bugfix

For bigger features that can take weeks to finish I create a branch for it, then commit the sub-features once they're done.

But often times I feel like I'm committing way too much; for example, when I'm trying to solve lots of bugs I do not commit each and every bug that I resolve.

Sometimes I also end up working with 2 or more things that should be in there own commits. Then I'll find it hard to just target the specific files within a specific change so I end up putting them all in one commit and end up with a commit message like add search feature and add caching feature.

What I want to know are the best practices for solo developers working with Git. For solo developers out there you're welcome to answer with your own workflow as well.

Answer 1

Solo or multiple is the same. Commit early, commit often. As soon as you go from non-broken to non-broken and changed, commit. If you feel that you're committing a lot, it is only because you're not used to it.

Here is a benchmark for you. When I was at Google, the average commit was under 20 lines. That will feel crazy when you first do it, but really, it is not too much.

Answer 2

Commit early, commit often

You will find that if your code is based on good design principles (KISS, DRY, SOLID, design patterns etc) that most of the time you will be making a small change here and an adjustment there. Each time you do this (and support it with a matching unit test to verify the change) then you should commit. Once those commits cover a user story or complete a task then you should push to share your work with others.

You may find that the "master-develop" branching strategy to be helpful. I've seen this in use in many open source projects and I have yet to find a significant flaw with it.