4

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.

lukatoni
  • 57
  • 3
  • 3
    see also: [Git for a solo developer](http://programmers.stackexchange.com/questions/209401/git-for-a-solo-developer) and [How to properly approach a GitHub workflow as a solo developer?](http://programmers.stackexchange.com/questions/133782/how-to-properly-approach-a-github-workflow-as-a-solo-developer) (side note [lack of research effort](http://meta.programmers.stackexchange.com/questions/6559/why-is-research-important "see: 'Why is research important?'") in this question feels pretty appalling) – gnat Feb 03 '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 03 '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 03 '15 at 12:07
  • @gnat, your first comment links to a closed too broad question, your second comment links to a 2 closed: duplicate questions. Why would you say this question is invalid and then provide links to other invalid questions? – Pieter B Feb 03 '15 at 12:41
  • 1
    Zipping your folder contents doesn't really give you an easy way to look up what changes were done... – Konrad Morawski Feb 03 '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 03 '15 at 13:02
  • The name is "Git", it's not an acronym. "GIT" are the GNU Interactive Tools, which is something completely different. – Jörg W Mittag Feb 03 '15 at 13:23
  • I think I followed all of the "already been answered" links, most of the links in those links, and even some 3rd level links, and didn't really see anything that struck me as a good answer, just a bunch of opinions. So is there an existing link that explains how to set up & use git for a single user? That is, the code-in-development will never be shared, will probably never leave my main machine, and certainly never my personal network. – jamesqf Feb 03 '15 at 21:19

1 Answers1

8

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.

MetaFight
  • 11,549
  • 3
  • 44
  • 75