11

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.

Improve this question
3
  • possible duplicate of How big should a single commit be? and of When is a version control commit too large?
    – gnat
    Aug 25, 2013 at 8:10
  • It takes discipline and practice. Just try and think about how you'll commit a feature as you are working on it. A bit of planning makes the practice part a lot easier. Discipline can be created by repetition so lots of small successes with git will be important.
    – ChaosPandion
    Aug 25, 2013 at 8:15
  • My idea is when your changes have a name, you should commit it. Doesn't matter one line or more..
    – Can Aydoğan
    Aug 25, 2013 at 11:47

2 Answers 2

Reset to default
13

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.

Improve this answer
2
  • does committing more takes more disk space?
    – Ooker
    May 27, 2022 at 8:54
  • @Ooker Not materially. Unless you're automated bot or you have a team of thousands, you simply can't take enough space with commits to matter.
    – btilly
    May 27, 2022 at 20:39
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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.