3

If I am working on a program alone, I just zip entire program folder once in a while. I keep only latest 2-3 files so my disk isn't cluttered.

So for example I would have 2 files: test-project-2015-02-03.zip test-project-2015-01-31.zip

Obviously it's not worth ziping files every 5 minutes, when some feature is done I zip it. Also I am not branching. That way I don't waste too much time on backup. I need backup very rarely and when I need it I don't have a clutter of 1000s of options, I just have 2 to restore from.

I am just learning github and I am amazed at complexity and clutter that it produces in recommended workflow. I can imagine it has to be like that for projects where many developers are working on same time, but why are single programmers having such complicated workflow?

1) Why do you commit every 5 minutes? Why not commiting when something is worthy of commit, like once every 2-3 days?

2) Why do you "add to stage" and commit? (To be sarcastic why not make 4 more stages in between)

3) Why do you create branches? You are going to restore latest best version anyway. Why not just stop commiting every 5 minutes if you are doing something risky? Commit when "branch" is done.

I need to learn git one day, but I can't put it on list of priorities when I don't see any benefits. I hope answers to this question will change that.

  • 3
    see also: Git for a solo developer and How to properly approach a GitHub workflow as a solo developer? (side note lack of research effort in this question feels pretty appalling) – gnat Feb 3 '15 at 11:48
  • I disagree. "Commit early, commit often". That's exactly what I asked WHY. I know that people commit every 5 minutes, I don't understand why. – lukatoni Feb 3 '15 at 11:52
  • 1
    Every five minutes: Well, I don't do it that often, but basically it's a backup, so if my local machine crashes I get the work back. Why branches: because then I can work on something new and still fix bugs on master. A branch may take days or even weeks. – thorsten müller Feb 3 '15 at 12:07
  • 1
    Zipping your folder contents doesn't really give you an easy way to look up what changes were done... – Konrad Morawski Feb 3 '15 at 12:48
  • 2
    I have to side with gnat on this: the OP is confusing git with github, not bothering to look into source control in general and its rationale, displaying unwarranted sarcasm in the question... this sounds like a rant in disguise, and it shows very poor research. – Andres F. Feb 3 '15 at 13:02
7

You're making some incorrect assumptions.

Here are a few:

  1. Having a granular version history (thousands of options, as you put it) is not clutter. For example, when you're looking to revert small changes made a long time ago, going over 1000 properly commented commits is a breeze. You can't do that with only 2 revisions in your history.

  2. Commit early/often does not mean every 5 minutes. It simply means don't be afraid of committing. It's a cheap operation that is almost without drawbacks. Every commit is a point in time you can unambiguously revert to. Having to revert mistakes or experiments by hand is a recipe for disaster.

  3. You seem annoyed at having to commit in stages. And as gnat pointed it, it looks like you haven't even tried to research its use on your own. Granted, this feature probably makes more sense when working in teams or offline, but it's still useful for solo development. For example, when I work on a feature I make several commits throughout development. Typically, I only commit when my code builds, but that doesn't mean the application actually runs correctly or that all the automated tests pass. Once I've finished the feature and done my testing and I can guarantee the application is operational, then, and only then, do I push my changes. This triggers my Continuous Integration server and plops out a new builds for my adoring fans :). So, staged commits are a way of getting the benefit of source control locally without negatively influencing other developers on the same repo. Ie, they don't have to put up with versions of the application that build, but fail half of the tests and crash immediately at runtime.

| improve this answer | |

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