Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

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.

share|improve this question

marked as duplicate by gnat, GlenH7, Bart van Ingen Schenau, Kilian Foth, Yusubov Aug 26 '13 at 17:52

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
possible duplicate of How big should a single commit be? and of When is a version control commit too large? –  gnat Aug 25 '13 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 '13 at 8:15

3 Answers 3

up vote 10 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

My idea is when your changes have a name, you should commit it. Doesn't matter one line or more..

share|improve this answer
1  
Your answer would be stronger if you expounded upon it. Please consider editing your answer and explaining more of your thoughts behind this answer. –  GlenH7 Aug 25 '13 at 12:15
    
without an explanation, this answer may become useless in case if someone else posts an opposite opinion. For example, if someone posts a claim like "even when your changes have a name, you should not commit it yet", how would this answer help reader to pick of two opposing opinions? Consider editing it into a better shape –  gnat Aug 25 '13 at 12:16
    
So in the spirit of this answer I committed "Newline" into one of my project repositories. –  Thomas Sep 25 '13 at 12:19

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