94

I know, and use, two version control systems: Subversion and git. Subversion, as of now, gets used for personal projects where I am the only developer and git gets used for open source projects and projects where I believe others will also work on the project. This is mostly because of git's amazing forking and merging capabilities, where everyone may work on their own branch; very handy.

Now, I use Subversion for personal projects, as I think git makes little sense there. It seems to be a little bit of overkill. It is OK for me if it is centralized (on my home server, usually) when I am the only developer; I take regular backups anyway. I don't need the ability to make my own branch, the main branch is my branch. Yes, SVN has simple support for branching, but much more powerful support for it makes no sense, I think. Merging can be a pain with it, or at least from my little experience.

Is there any good reason for me to use git on personal projects, or is it just simply overkill?

12
  • 63
    No, I use git and hg for personal projects. Having local revision control is a godsend.
    – wkl
    Commented Apr 18, 2011 at 18:17
  • 7
    Git is in many ways better for all projects, whether they have a large numbers of contributors or not : git compresses stuff much, much more efficiently than svn (and is order of magnitudes faster!), git makes backups trivial, and git will not be an obstacle if someone else wants to contribute.
    – Artefact2
    Commented Apr 18, 2011 at 18:25
  • 4
    I use version control to push my code to either github or bitbucket, it servers as backup for me, and maybe someday I'll actually write something people will be genuinely interested in.
    – Mahmoud Hossam
    Commented Apr 18, 2011 at 18:33
  • 8
    " I don't need the ability to make my own branch, the main branch is my branch." A lot of people said the same thing about undo when it was a relatively new feature in applications. Now everyone realizes that they needed it all along. You need to branch, you just don't know it.
    – Dan Rosenstark
    Commented Apr 18, 2011 at 19:43
  • 1
    @rtperson yeah, you can do that, but I actually like mercurial more, even though I like github more than bitbucket.
    – Mahmoud Hossam
    Commented Apr 18, 2011 at 20:04

11 Answers 11

Reset to default
159

It's not overkill. The main reason why I started using Git and Mercurial over Subversion for personal projects is that initiating a repository is so much more easier.

Wanna start a new project?

> git init

BAM! No need to set up a repository server nor check in a folder structure to support branching and tags into a subversion repository.

Sharing your project later is just a matter of: git push (other than having a remote repository). Try to do that quickly with subversion!

21
  • 26
    Accepted. I couldn't have been proven more wrong about git being overkill than this ;)
    – Anto
    Commented Apr 18, 2011 at 19:10
  • 7
    Steve341: I usually keep all source code projects in a folder named "projects". That's where I keep all repositories, one for each source code project. I never had a need to keep track of several projects together in one and same VCS repository; that's what dependency management systems such as Ivy or Maven is for.
    – Spoike
    Commented Apr 18, 2011 at 20:13
  • 3
    @Steve341 How is it hard to keep track of this stuff? You just have one folder that contains all your repos. Its no different than your system, aside from the fact that your system is an extremely bad practice when using git...
    – alternative
    Commented Apr 18, 2011 at 22:53
  • 2
    @Steve314: echo 'for dir in projects/*; do cd "$dir"; git push; cd ..; done' > update_all; chmod +x update_all
    – André Paramés
    Commented Apr 19, 2011 at 11:19
  • 3
    git init and bam! Oh yeah and then cp ../the-other-project/.gitignore . before the initial commit. Bam!
    – Dan Rosenstark
    Commented Apr 19, 2011 at 20:57
50

I would contend that using Subversion for local personal projects is overkill, whereas Git is decidedly not. Git will take up less space (because of SVN's inefficient "revisions" concept versus Git's object snapshots), requires less setup (git init versus a dozen svnadmin commands and setting up permissions and so on), is easier to back up (git clone --bare [or git push origin if you use Github or similar] and you're done), and has better tools for managing your code (branching is free, and merging is easier and cleaner). Just because no one else has a clone of your repository doesn't mean that the benefits of any DVCS are "overkill."

Further, I'd say Git's branching support is less complex than SVN's, with greater rewards.

9
  • I guess I should have used "powerful" instead of "complex"
    – Anto
    Commented Apr 18, 2011 at 18:24
  • 3
    @Anto: Doesn't matter. I'd still say basically the same thing: Git's superior branching simply has no downsides, compared to SVN.
    – greyfade
    Commented Apr 18, 2011 at 18:27
  • 3
    Nor will Git "pollute" your source tree with tracking files in every subdirectory.
    – WarrenT
    Commented Sep 2, 2012 at 15:22
  • 4
    @WarrenT the source tree "pollution" doesn't happen in svn versions 1.7 and later.
    – pllee
    Commented Sep 2, 2012 at 19:40
  • 4
    Creating a filesystem repository in Subversion is one command (svnadmin create, plus one to do the initial checkout or import), no need to set up permissions and so on. I don't deny that Git's often a better tool, but inaccuracies about Subversion aren't helpful.
    – Josh Kelley
    Commented Feb 1, 2013 at 13:29
37

To think you will never branch your own code is a little short-sighted. I've branched my own code several times, particularly when I was experimenting with a new approach I wasn't entirely convinced about yet. You'll eventually want the feature.

This is coming from a long time Subversion user. Consolidating on one tool can really help make your life easier.

3
  • 2
    Yes I believe this is the point of branches, experimentation. That was my first reservation when reading Op's question. If you are not branching in your repository you are "branching" in your head and this is just senseless when you have version control in place.
    – Chris
    Commented Apr 18, 2011 at 19:00
  • 4
    You can branch with subversion. And merge. Sort of. Actually, the only time I tried I ended up with a corrupt repository that I couldn't work with any more, and recovering from a backup (with the branch already applied) didn't help, so I ended up losing all my history and starting a new repository... but I blamed that on the transition from 1.4.? to 1.5 (I think - it was a few years ago now). Probably branching and merging works, really. If you're brave enough to try it. If I'd known about svn dump back then, I could have fixed the problem with some effort, of course.
    – user8709
    Commented Apr 18, 2011 at 19:26
  • @Chris, I like to have a working version I can fall back to at any time. Sure you can accomplish that with tags, but there are times when a branch makes perfect sense. Don't forget the other benefits of git/mercurial either.
    – Berin Loritsch
    Commented Apr 18, 2011 at 19:51
9

Overkill is reserved for when there is collateral damage caused by the "solution". Using a gun to kill a fly means there is damage caused by the bullet going else where. It is overkill. Using something more powerful than necessary that doesn't cause an issue isn't overkill and can be a good thing if it helps you streamline your development process. It causes no harm and allows you to only have to update one set of software instead of two. So why bother with two systems instead of one?

2
  • It could be overkill (yes, with that definition) if the system got into your way. I'm wondering whether it is a good idea to use git for personal projects. Could you please tell me what are specific advantages? This answer doesn't address that. I see git as a more powerful system, and too powerful for personal projects. There mustn't necessarily be any harm in that though, as long as it doesn't get into your way. Could you perhaps expand on your answer?
    – Anto
    Commented Apr 18, 2011 at 18:43
  • 1
    Overkill is also used when the effort used to apply the solution is out of proportion. Arguably, if you're already using subversion for local projects, the effort needed to learn Git or whatever is overkill. Or possibly a useful lesson developing transferable skills, of course. Personally, I still use subversion - it's bit me a few times, but only left minor scars. I'm interested in learning Git, but every time I went looking, the tutorials I found were cryptic or I couldn't get stable tools for Windows or there was some other roadblock that made it all seem like, well, overkill.
    – user8709
    Commented Apr 18, 2011 at 19:32
8

I use Git for my one-man projects and I love it. I was previously using Subversion and I've yet to see a downside to using Git. It's more powerful but not in a way that makes simple things more complicated. Making simple things unnecessarily complicated/expensive/slow/etc. is IMHO a necessary condition for calling something overkill. Also, on Github I've forked other people's previously one-man projects to add a feature I wanted and then sent them pull requests. I'd find it quite cool if someone interested in my projects did the same thing.

8

I never used source control on personal projects before DVCS, so it's a little weird to imagine someone taking the opposite view. Some of my reasons are:

  • Easy to set up and tear down. For example, a colleague gave me a programming puzzle last week that I solved in several small steps. I made a git repo that lasted all of 45 minutes to hold my work, and then it was gone. I don't know how easy something like that is in subversion, but I've never heard of anyone doing it.
  • Disconnected. For me, being able to work offline is much more of a benefit to a hobby project than one for work. I don't need to poke a hole in my home firewall or host a project publicly. I can temporarily put a repo on a thumb drive or a laptop, and still keep everything in sync.
  • Everything colocated. Having the repo and working tree together makes small projects easier to keep track of during things like OS upgrades.
  • Powerful features. Sure, I don't need the power all the time, but it's there when I need it, and doesn't consume any resources when I don't.
6

I've been told that git-bisect is really nice for finding the exact commit that introduced a given behaviour, by navigating back and forth in commits depending on your input.

You will have to do that some day for things you simply cannot figure out what has happened.

EDIT: Also, the ability to branch is very important when you have to do bugfixes in old versions which customers use. You must be able to manage "just fix this tiny thing but I do not want the newest version because I do not want to test it all over again now".

2

It depends on how serious you want to get about versioning your own code. If what you're building is for example a simple library that will only ever have the current version (or for as long as that's true), I'd personally just use a basic backup option like Dropbox. If you lose all your code you can recover it from the web, and Dropbox has a 30 day version backup if you really do something stupid.

However if you for example need to maintain Production and Dev branches, then git is absolutely a great tool - and a heck of a lot faster than svn. Mind the risk of hard drive failure if you only store the data locally, though.

5
  • 1
    Yeah I use DropBox for personal projects. The versioning is nowhere near as sophisticated as a true VCS but it's fine for smaller projects I do in my free time, and it requires no attention at all (eg. no commits, files just update as you work on them.)
    – jhocking
    Commented Apr 19, 2011 at 16:48
  • oh and incidentally because I develop games my projects tend to have lots of binary files (image files, audio clips, etc.) and most version control systems are really only intended for source code.
    – jhocking
    Commented Apr 19, 2011 at 19:33
  • Git works just fine with binary files, the diffs are just less interesting. Fortunately diffing in git isn't exactly locked-down - if you can find a binary diff tool you love, you can use it with git pretty easily (from the command line)
    – Chris Moschini
    Commented Apr 21, 2011 at 20:54
  • I was told that Git wastes a lot of space versioning binary files, but what I was told may be incorrect. Basically, I was told that most binary assets (I suppose not all binary files, but the images and sounds that go into a game) have to be resaved entirely every version and so Git fills up your hard drive with the local repository.
    – jhocking
    Commented Apr 21, 2011 at 21:04
  • It's only wasteful if you didn't mean to version the binary files. If you do need to version them, then the version history isn't waste. I think they're accidentally implying git bloats its version history when tracking binaries - that's incorrect. git.wiki.kernel.org/index.php/GitSvnComparsion
    – Chris Moschini
    Commented Apr 21, 2011 at 21:36
2

I'd always, always, always use a version control system for any kind of development project. Large, or small really doesn't matter. Whether I'm playing at home with some kind of new technology, writing a little helper to ease up my life or developing professionally in a large and distributed team - I'd always want a version control system to back me up.

Sure, most of the time for small personal projects you won't use most of the features, but setting up a git repository (or even a local Subversion repository) is no big deal, so go for it! And before you know it you'll want know "damn it, what was the content of file X last friday?". Without version control - good luck ;-)

So, it really doesn't matter if you use git or SVN - personally I'm starting to migrate more and more stuff from SVN to git but the main thing is to use version control at all - even for the little things.

1

Only because nobody has mentioned it: for personal projects, darcs is really good, and less involved than git for doing straightforward version control. It's not as fast for larger projects, but then, neither is Subversion!

3
  • 1
    That sounds kind of related to how well you know darcs. I have never used it but have used git a lot. To me git is very straight forward, but I bet I would be scratching my head if I was to use darcs.
    – Sam
    Commented Apr 19, 2011 at 9:48
  • 1
    If you've already mastered the insane ui of git, darcs would be a cakewalk.
    – wlangstroth
    Commented Apr 20, 2011 at 1:02
  • 1
    can you, please, explain why darcs is better for small projects then git?
    – shabunc
    Commented Aug 24, 2012 at 10:42
0

It can be a powerful mental paradigm shift to understand that what we do is experimentation. Having a cheap / easy tool to support this, enhances your ability to move forward, in part because it enhances your ability to back out of any experiment when it turns out poorly.

Many developers say, Well I just make copies of my code. But these copies become difficult to manage and end up as clutter. You have multiple copies and can't remember which copy for what, and then try to figure out when it is safe to delete them.

All this becomes even more valuable when the experiment entails coordinated changes across multiple files. And when it is a solo pfoject using Git becomes even simpler.

Instead of wondering whether I should use it on a solo project, I now think what a shame I hadn't discovered this sooner.

1
  • For the designer's views on this, watch Linus on Git on YouTube (~70 mins)
    – WarrenT
    Commented Sep 2, 2012 at 16:13

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