93

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?

Anto
  • 11,157
  • 13
  • 67
  • 103
  • 62
    No, I use git and hg for personal projects. Having local revision control is a godsend. – wkl Apr 18 '11 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 Apr 18 '11 at 18:25
  • @Artefact2: Space doesn't matter that much, I have TBs of space and use a few GB ;) Otherwise, good points, though Subversion backups ain't that hard anyway (Git is easier, actually, when you say it) – Anto Apr 18 '11 at 18:27
  • 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 Apr 18 '11 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 Apr 18 '11 at 19:43
  • @Mahmoud Hossam: +1 for mentioning github -- that's the main reason I use Git for personal projects. And I figure in the future, when interviewing, I'll be able to point to my github repositories when asked what I've programmed in my spare time. – rtperson Apr 18 '11 at 20:01
  • 1
    @rtperson yeah, you can do that, but I actually like mercurial more, even though I like github more than bitbucket. – Mahmoud Hossam Apr 18 '11 at 20:04
  • I use git for version controlling *my homework* in Coursera classes. – Mark E. Haase Jan 27 '13 at 23:05
  • possible duplicate of [Version control for independent developers?](http://programmers.stackexchange.com/questions/27147/version-control-for-independent-developers) – gnat Jan 03 '14 at 16:57
  • @Yar, Nope, `undo` is a no-brainer even back in the 1970s. Who said that they didn't need `undo`? – Pacerier Feb 24 '15 at 08:16
  • 1
    @Yar, [Undo has a long history](http://en.wikipedia.org/wiki/Eraser#History). It's a no-brainer even back in the 1970s. Who said that they didn't need undo? Which user will ever say that? The only people who say that undo is not needed are the coders who want to cut some slack. – Pacerier Mar 02 '15 at 03:49
  • somewhat related: [Behavioral effects of using version control for solo recreational coding](https://reconvolution.blogspot.com/2017/12/behavioral-effects-of-version-control-on-solo-recreational-coding.html) – Nick Alexeev Dec 11 '18 at 21:16

11 Answers11

161

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!

Spoike
  • 14,765
  • 4
  • 43
  • 58
  • 26
    Accepted. I couldn't have been proven more wrong about git being overkill than this ;) – Anto Apr 18 '11 at 19:10
  • 1
    If you start a new repository at the drop of a hat, don't you risk losing track of your repositories? How is this better than losing track of your unversioned files? Personally, I prefer to keep a few home projects repositories for most things (one for source code, one for non-programming documents, ...), and just create a new folder for each new project. –  Apr 18 '11 at 20:02
  • 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 Apr 18 '11 at 20:13
  • 1
    @Spoike - what do you use to keep track of all your keeping-track-of-things systems? –  Apr 18 '11 at 21:07
  • 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 Apr 18 '11 at 22:53
  • @mathepic - my point was that you suggest using Ivy or Maven rather than just keep most projects (with the only connection between them being that they're small home projects) in one versioned folder. Having multiple keeping-track-of-things systems seems excessive for a few at-home projects. And multiple projects in one repository is pretty convenient when you want to keep all of them synchronised, e.g. between your laptop and desktop - one update to sync all projects in one go. No good for "real" projects, but for most home projects... –  Apr 19 '11 at 03:12
  • @Steve314 I never had the need of synching all projects in one go since I like to focus at one project at a time. The first thing I do is to update my project before working on it; and that is a good version control practice even in professional environments to update often. – Spoike Apr 19 '11 at 04:46
  • 2
    @Steve314: `echo 'for dir in projects/*; do cd "$dir"; git push; cd ..; done' > update_all; chmod +x update_all` – André Paramés Apr 19 '11 at 11:19
  • 1
    Also if you want to keep a repository of repositories, there is `git submodule` or the Android project's `repo`. – Spoike Apr 19 '11 at 13:38
  • @André - that's not what I call convenient, and it's only obvious if you're more familiar than I am with the Linux command line. And it won't work at all when (like me) you dual boot with Windows and Linux. Of course you can write something equivalent as e.g. a Python script, but that's still a bit of develop effort. Even a bash script, and install CygWin on Windows. But notice how this is all, well, a bit overkill. –  Apr 19 '11 at 18:44
  • @Spoike - you always know which project you'll be interested in in, lets say, 6 hours time? I quite often find I want to refer to something in another project (how I used some API or whatever) to solve a problem in the project I'm working on. Hard, if you don't have that reference project with you. Even if it's on the same machine, but on an Ext4 partition while you're currently working in Windows, that's some hassle to access it. –  Apr 19 '11 at 18:47
  • 3
    `git init` and bam! Oh yeah and then `cp ../the-other-project/.gitignore .` before the initial commit. Bam! – Dan Rosenstark Apr 19 '11 at 20:57
  • It must be karma or something. Today, I hit a "little problem" in Mercurial, caused by trying to convert a subversion repository that holds multiple projects. So... it seems it may be OK to have multiple home projects in a *subversion* repo, *if* you know you'll never want to convert to a distributed system. And that's a big if. –  Apr 20 '11 at 02:29
  • @Steve314: In the context of number of repositories it may seem excessive from the viewpoint of a Subversion user. For a subversion user all projects and branches are virtual directories in a singular subversion file repository. So it would make sense to put everything in one lone subversion repo. In Git and Mercurial it wouldn't make any sense to do the same since both concepts are instead treated as first class citizens; projects are their own repositories and branches are paths in a revision graph. Also, in Windows you don't need to use scripting because there are GUI's available. – Spoike Apr 20 '11 at 05:06
  • @Steve314: If I have to query how to use some API I'd use the api docs or google it up. If it's a proprietary API that's badly documented and then accidentally not having any other project with you is more of an *organizational* problem than a tooling problem. I usually keep such projects as remote repositories in a network share (btw; very simple backup solution in a workplace if the network share itself is regularly backed up); so whenever I want to refer to an old project I'd just `clone` it. – Spoike Apr 20 '11 at 05:17
  • @Spoike - actually, the problem I hit was because a branch *isn't* (in some ways) as flexible a tool in a DVCS. You normally branch by cloning a repo/WC, meaning the whole repo is branched at once - you can't clone a single folder. In Subversion, branching (or rather merging) is a disaster zone anyway, so I didn't think about this issue until I realised I really didn't want a whole bunch of subversion managed projects (single repo) converted to a single DVCS repository. –  Apr 21 '11 at 21:43
  • @Spoike - on APIs, though, I think you miss my point. No matter how good the docs, there are likely non-trivial how-to-apply-the-API-to-your-problem issues you've had to resolve. If that same issue recurs 6 months later, it's better to copy your previous solution than to redesign a solution from scratch. On being an "organisational problem" - the whole point of a VCS is to solve a particular kind of organisational problem, so clearly an organisational problem very often *is* a tooling problem. And is your work network share clonable from home? Or while on the train? –  Apr 21 '11 at 21:49
  • Oops - second to last message, I meant "meaning you can't branch a single folder". That may be wrong anyway - but you can't do it by the standard clone-the-whole-repository method. –  Apr 21 '11 at 21:51
  • @Steve314: Network shares from work can be accessed via VPN (fairly standard practice these days), in case I need to do updates from home. I commute to work on train, so if I do hack or plan something on the train (which I've done mostly with javascript stuff) then I can work offline (with regular `commit`) until I get back to my home or work network so I can sync my changes (with `pull`/`push`). – Spoike Apr 22 '11 at 06:31
  • Not only is setting up a repository easy, but *destroying* it is also easy. No, I mean that in a good way. I remember the bad old days of trying to create a SourceSafe repository the right way, and the hassles of trying to fix it when I'd done it wrong. With Git, if you mess up when creating the repository, you just delete the .git directory and try again. – Kyralessa Jul 29 '11 at 15:53
  • For tiny projects there may be an even simpler way to share it than `git push` : put the whole thing in a zip file and email it to someone. When they unpack the zip they will be able to use git to view the history of the project. – bdsl Nov 14 '17 at 22:18
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.

greyfade
  • 11,103
  • 2
  • 40
  • 43
  • I guess I should have used "powerful" instead of "complex" – Anto Apr 18 '11 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 Apr 18 '11 at 18:27
  • 3
    Nor will Git "pollute" your source tree with tracking files in every subdirectory. – WarrenT Sep 02 '12 at 15:22
  • 4
    @WarrenT the source tree "pollution" doesn't happen in svn versions 1.7 and later. – pllee Sep 02 '12 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 Feb 01 '13 at 13:29
  • @JoshKelley: My experience with subversion is setting up a new server, issuing an `svnadmin create` followed by an attempted checkin, some swearing, then double- and triple-checking the repository directory's mode and ownership, adding users to a new group, and spending a full day trying to get checkins working over SSH before I can begin on my project. It's a lot of unproductive fooling around that I've gotten frustrated with. By constrast, I can issue a trivial `git init` and be done with the whole mess, and setting up a git server is easier and requires little setup if SSH already works. – greyfade Feb 01 '13 at 17:38
  • @JoshKelley: I stand by my answer. – greyfade Feb 01 '13 at 17:38
  • @grayfade - You don't need a server or SSH or any of that stuff if all you care about is a _local filesystem_ repository for a one-man project. – Josh Kelley Feb 01 '13 at 17:56
  • @JoshKelley: And when I *do* need a server? I find git simpler and preferable. – greyfade Feb 01 '13 at 17:58
36

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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Berin Loritsch
  • 45,784
  • 7
  • 87
  • 160
  • 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 Apr 18 '11 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. –  Apr 18 '11 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 Apr 18 '11 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?

stonemetal
  • 3,371
  • 16
  • 17
  • 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 Apr 18 '11 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. –  Apr 18 '11 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.

dsimcha
  • 17,224
  • 9
  • 64
  • 81
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.
Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
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.

Chris Moschini
  • 262
  • 2
  • 8
  • 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 Apr 19 '11 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 Apr 19 '11 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 Apr 21 '11 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 Apr 21 '11 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. https://git.wiki.kernel.org/index.php/GitSvnComparsion – Chris Moschini Apr 21 '11 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.

Christian Seifert
  • 2,096
  • 12
  • 19
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!

wlangstroth
  • 111
  • 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 Apr 19 '11 at 09:48
  • 1
    If you've already mastered the insane ui of git, darcs would be a cakewalk. – wlangstroth Apr 20 '11 at 01:02
  • 1
    can you, please, explain why darcs is better for small projects then git? – shabunc Aug 24 '12 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.

WarrenT
  • 601
  • 1
  • 4
  • 7
  • For the designer's views on this, watch [Linus on Git](http://www.google.com/url?sa=t&rct=j&q=youtube%20linus%20on%20git&source=web&cd=1&ved=0CCUQtwIwAA&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D4XpnKHJAok8&ei=THpDUK_bLpOK9gSFmYBY&usg=AFQjCNF8GNcy2zhwHV35oFLX3xWjqhuIgg&sig2=iKUzFEOnY-HTQwwUIvoFpA) on YouTube (~70 mins) – WarrenT Sep 02 '12 at 16:13