Ask HN: Is version control worth learning early on?

[colbyolson]

Just spent two hours writing a 25line Python script. First real script, totally happy and pleased with myself. But what do I do with it?

I am planning on storing it in my personal Dropbox so I can edit it or create more on which-ever computer I own, but my question is: would it be worth it to learn Git/SVN now, in the early stages of programmer-hood, or later down the road. Would I benefit from learning/using Git/SVN now? Or would I benefit more from ignoring Git/SVN and just focus on writing code. Thanks.

[alanthonyc]

Do it.

A night or two spent on learning how to use git (and maybe setting up a remote repo) will save you tons of headaches later and produce lots of benefits almost immediately.

[tdavis]

In fact, a few months spent learning best-practices for programming in general (including version control, proper testing, automated deployment, isolated environments, etc.) will pay dividends later. Learn these things now (and apply them even where they aren't necessary, in order to build experience and comfort level) and within a year or two I can practically guarantee you'll be better than at least 90% of working programmers.

There are so many life-altering tools available for developers now; far more than were available when I started programming. Unfortunately, the longer you build up bad (or simply inferior-to-current) programming practices, the harder it is to apply new, better techniques. Integrate them into your life now and you'll have a sturdy, solid foundation to build on.

[pvg]

At the level of 25 line scripts, something like drop box provides about all the headache-prevention and benefits needed. Programming in the large involves a great deal of bookkeeping tasks, which, while important and valuable are about -3.7 on the fun scale. The tools for such tasks also tend to have impressively poor usability.

If you've written a 25 line script, write a 100 line or 5000 line one. And have fun. You already understand the importance of versioning and having reliable backups. Assuming your goal is to become a programmer rather than a book-keeper, stick to the programming for now.

[apotheon]

You beat me to it. I agree 100%. Learn to use version control as early as is reasonable. Hell, learn to use it for your personal document directory on your computer at home -- it's great for that, too. It's useful for more than just source code, especially if you want to work on the same stuff on multiple computers.

[SwellJoe]

Learn revision control concepts as soon as possible. This is one of the ancillary things you need to know to become useful to other programmers...those that can teach you.

When you work with teams, in particular, being competent with your revision control system is mandatory. You'll be surprised by how easy it is to pick up the basics, if you just make yourself do it. The Subversion book is quite good both from a conceptual, as well as specific technical perspective; we've just started moving our projects to git (and I've been using VCS of one form or another for more than a decade), so I don't have a good notion of what the git docs are like for complete VCS newbies.

Anyway, create an account at github, follow the tutorials and docs they provide, and you'll be able to do most everything you need. I don't think Subversion will be going away any time soon, but DVCS is definitely rising quickly, and most new OSS projects are starting on git or another DVCS.

[ivanstojic]

I could never figure out Git until I read this:

http://www.eecs.harvard.edu/~cduan/technical/git/

[cake]

When I first learned how to use SVN I found the Subversion book (this one : http://svnbook.red-bean.com/) very confusing. I think it goes in too many details early on.

If I had to do it all over again I would try to find the very basic functions that I have to use and a few graphics explaining how it's structured.

[Xixi]

Lot's of people here are suggesting git. I admit that I never tried it and personally use mercurial hg.

I definitely recommend learning version control as soon as possible. It's a life saver, and it's incredibly easy. With mercurial you're up and running by typing 'hg init'. That's it.

And then you get to experience the satisfaction of 'hg commit'. Maybe I feel like this because I've been burned by not using control version system a long time ago. But really, as soon as I've done a commit, I just feel at peace: I can throw myself in large refactoring (unit test helps too), try something that will probably not work and break everything. It doesn't matter because it's so easy to backtrack.

You can do the same with copy paste. But it takes much much more time. It's just too much of a hassle. And it doesn't scale with teams of more than 1 person...

[RossM]

In basic usage I found hg and git remarkably similar (although I haven't had to do anything further than a clone/co/comit). I'd rather use git just for github (which I find to be the best "social" repository hub) - github has always provided much more than Google Code or Launchpad in that the emphasis is on finding someones repo, forking it and making it better.

[tolmasky]

Learning how to use version control is not such a hard enough task that it will honestly "prevent" you from making progress on programming. This is kind of like asking whether you should figure out how to get car insurance, or not get distracted by that and focus "on the driving" instead. Its not that difficult, and you will regret it. On the other hand, I suppose learning to use version control the hard way is arguably one of the most important milestones in a programmer's career.

Don't get me wrong, you can become a master at certain VC systems and do all sorts of neato stuff with them, but you should focus on getting the bare minimum down (enough to just replicate what you are already doing on dropbox, which should take you a few hours max), and then get back to programming. You will learn the rest along the way. At some point you will say "oh man, I can't believe x happened", or "I really wish I could look at my code this way", you'll ask someone for help, and since you were using a version control system all along, you will be able to do it.

Think of it more like getting a proper text editor to replace notepad rather than "learning" something brand new.

[discojesus]

Sweet jumping jesus YES.

And don't start withi git - start with subversion, and move on to git or mercurial later. Subversion is much easier to start out with.

[gcv]

Subversion is much easier to start out with.

False.

1. Subversion requires you to use tools which are Subversion-aware. If happen to delete or rename a file from the Finder, Windows Explorer without Tortoise, or the command line without using "svn rm", Subversion will muck things up, and you won't even notice until you try to commit. And heaven help you if you try to use a non-Subversion-aware IDE. If you're just starting out, you might not know that you must install Subclipse in Eclipse. If you don't, a simple class rename will leave your working copy in a state from which it'll take a lot of painful work to recover.

2. Subversion requires a separate repository to be set up. Often, this means either setting up a whole server for Subversion itself or a web server to serve up the repository over the WebDAV front end. Yes, I know you can just use a local directory, except you still have to read the documentation about how to do it right. Either way, typing "git init" or "hg init" right in the directory where you started hacking takes a lot less effort.

Look, I kind of understand that some people think that Git's index takes some getting used to. I disagree, and consider the index an important feature, but de gustibus pravis non disputandum est, and all that. In that case, try Mercurial. It's a perfectly fine VCS. It probably is a bit more intuitive than Git for the first fifteen minutes. Don't worry about either system's more advanced features yet. As a beginner, just get used to saving incremental changes to your code and the ability to experiment safely, and look at what has changed. Eventually, you'll find yourself saying "hey, I wish I could track my code in such-and-such a way," and when you do, Git and Mercurial both have solid documentation.

Setting up a Subversion server won't help you become a better programmer. Wondering what went wrong when Subversion thoughtfully breaks your working copy won't make you feel happy about using version control. Even worse, looking at the behaviors of some programmers I've worked with, Subversion teaches people really bad source control habits --- making commits with tons of random unrelated changes jumbled together.

[calambrac]

Why do you think subversion is easier to start with? You have to understand the difference between the local copy and the repository, you have to manage the server, you might have to deal with the incredibly painful corruption issues that pop up every now and then.

And I personally don't think the day-to-day use is any easier, either, unless you're only working with one branch, and even then, the only 'savings' is you don't have to stage first.

[moe]

Even as a git user I'd second that (blasphemy).

Git is the "real deal" but it also has a ridiculous learning curve when it comes to using it right (i.e. never commit to the master branch directly) and many sharp edges to frustrate you.

Start with svn or mercurial to get a feel for what it's all about. You can always step up to git when they don't cut it anymore.

[Tichy]

Why not learn enough basics to at least keep versions of your code around. You never know, perhaps one day you'll find it amusing to track your progress.

You don't have to learn all the ins and outs. I don't know git very well yet. Basically to start use

git init

git add -A

git commit -m "yay, another submit"

Also a .gitignore file might be useful

[Bjoern]

Absolutely as soon as you start working with other people you will need this knowledge. I wouldn't learn SVN because you can interact with SVN via Git. (git-svn). To get startet:

Git on Windows, how to install and use it (or see below for Tortoise git)

http://www.gitcasts.com/posts/git-on-windows

Mov: http://media.gitcasts.com/c10-windows-git.mov.zip

If you use the Git GUI from Msysgit to clone a repo please use the following credentials: ...

Tortoise Git is a easy solution which is thought to integrate into e.g. Explorer etc. Please see here for details:

http://code.google.com/p/tortoisegit/ (first install msysgit then this..)

Linus Torvalds on Git (a more detailed introduction) http://www.youtube.com/watch?v=4XpnKHJAok8

Git usage: ----------

Most interesting is for git is that "Branching" is very cheap. This means that if you want to implement feature X you just "branch" the repository (e.g. local or remote) and don't affect the main branch until you want to merge your code back into main.

Cloning: ---------

1.) Open e.g. Git Bash

2.) Go to the folder where you want to store the repository

3.) git clone ssh://IP:PORT/REPONAME.git TARGETDIR

4.) It will ask you for your ssh key. (please see the above video (.mov) for details).

Later then you can test things by just changing something slightly and recommiting it, e.g.

1.) cd TARGET

2.) vi README

    # ---> .... changed something

3.) git add *

4.) git commit

    # --> vi will pop up and you type e.g. one line "- 

Added some more

    # details to the README file how to do XYZ."
  
    # This can also be done on the commandline by:

    git commit -m "<YOUR MESSAGE HERE>"

5.) git push

    This will push back your changes to the master repository.

Have fun !

[mattj]

I hate to go against the grain, but I would say don't learn version control until you know you have to. The first time you get burned, like just lost a week of work burned, you'll know exactly why version control exists and why you need it.

That being said, I did use vc (cvs, uggh) from pretty early on, but I still got burnt a few times when I forgot to check in or damaged my repos.

[sho]

Should I wear a seatbelt in my car?

No. That way, when you have a crash and are severely injured, you'll realise that you should have been wearing a seatbelt!

[donw]

Yes. The first time you accidentally blow away a bit of code that you spent two days debugging, and can get it back because you check in every night, you will be thankful.

[dpcan]

Or if you change a massive chunk of code only to find out your customers HATE it and you must roll-back.

[silentbicycle]

It sounds like you're already getting an overwhelming yes, so I'll just add:

1. It's not a bad idea to keep some of your home directory under VC, especially config / preference files and any writing. (This is more useful on Unix, which typically uses text files for nearly everything.) They're also useful for backup.

2. Git and Mercurial (AKA "hg") are both really good, and probably simpler to use than svn. (I suspect the people who say svn are simpler probably learned it first, and then had to learn all the ways that git/hg's designs differ - but those differences make them simpler to set up.) They havea few different features, but have probably 90%+ in common, and you're not going to really know which one would be a better fit for you until you pick one and learn the basics. You can change your mind later.

[KevinMS]

Truthfully version control has never really helped me out on anything other than backing up and restoring. I still have to google svn command just to figure out how to go back to previous revisions.

I would recommend you just learn how to set it up and learn a few basic commands like checking in and updating and then see if using them in your workflow helps at all.

If you work on any collaborative projects you'll probably have to use it, but just the basics.

As far as all this talk about good habits, etc. Its all bullshit. Its a tool. If it solves a problem use it, if it doesn't don't sweat it. And when you are eventually forced to use it, just learn a few commands or ask for help. Its really no big deal.

[pchristensen]

Life insurance is a tool too and I have no idea how to redeem a policy.

[fookyong]

There's really nothing to learn. I only know a few commands

svn up svn st svn rename svn add svn remove svn ci

that's all I need to know and I've got by with just that for years.

version control is so essential to the way I work now that I can't even fathom working without it. it's not just about version control for me (I very rarely need to "roll back" code etc), it's more about security, having access anywhere I want (my repositories are remote) and being able to deploy sites with just one line of code instead of faffing over what has changed and what hasn't on the live server.

[wildjim]

Yes, yes, yes, yes, yes, yes!!!

I work as a release engineer, and the sheer number of f*-ups that could be avoided by dev's understanding version control better is truly astonishing.

It doesn't matter very much which version control system you use (though there are a few which will give you a pounding headache) it's more important you understand a few useful processes, like merging and conflict resolution, branch strategies (e.g. feature branches, release branches, does HEAD == all source-code?, etc, and why you'd use one or the other) check-in style (e.g. larger chunk(s) with peer code-review?, frequent updates that allow you to follow your thinking at a later date?, pre-submit unit-tests?) among a few other things.

Even though not all of these things will be needed by your project(s), knowing those things in-advance are what will allow you to use a VCS effectively, even if you work alone.

[tiffani]

Definitely learn to use version control of some sort (I'm still stuck on Subversion) as early as you possibly can. Indeed, it'll be great to track your progress as you build up code on more complex stuff. Also, you'll definitely be great in a team environment and it'll foster a somewhat safer team environment, too. Teaching a developer now at my job (who was in place before I was) how to use SVN because now we're officially a team and I stay nervous about accidentally hosing anything he does or vice versa.

And yes, being able to rollback bugs or things your users don't like in a systematic, traceable way is absolutely the best. Undo only works up to a point lol.

Check out The Pragmatic Programmer for more nice ideas about being a developer. http://www.pragprog.com/the-pragmatic-programmer

[tmikew]

When I first read the question I almost fell off my chair. The answer is YES. I have used source safe, star team (briefly), cvs, svn and now mercurial. I haven't used Git but I understand that it is conceptually similar to mercurial. I keep most everything in mercurial repositories, not just my projects.

I much prefer the distributed stuff. Just make a repository anywhere now it is an awesome concept. Soooo much easier than fiddling with an svn server for example. (I am talking about the set up of the server.)

I personally think it is completely worth it to get your head wrapped around the idea of distributed revision control. Aka mercurial or git.

Rolling eyes and shaking head at all of the other folks on this post who recommended avoiding learning revision control as soon as possible. That would be a mistake.

[csytan]

I'd suggest waiting until you want to start collaborating on a project. My first few scripts used folders for version control, and it was perfectly adequate.

Why wait? Here's a few reasons: 1. If you've only written one script, then your time is better spent learning and working on interesting programming problems.

2. Dropbox includes basic version control. It's more than adequate for a few scripts, with the advantage of being automatic and dead simple.

3. Version control is a pain in the ass. Installing software, setting up ssh keys (if working with a remote repository), and learning the commands was exceptionally boring for me.

There's no need to experience this tediousness right now -- just dig into whatever is the most interesting to you!

[rykov]

+1 for version control.

1) Do it because it will give you a huge piece of mind (backup & history)

2) Do it because you can code review (git diff) the whole feature before committing it, rather than doing it one line at a time and hoping you'll achieve stability in the future.

[Kaizyn]

If you don't take the time to start working with version control from the very beginning, you'll just give yourself bad habits that you will have to break later. Also, you run the risk of losing your code in the event of some catastrophe. I would recommend you use one of the distributed version control systems so that everything for a project (including the entire project history) is self-contained in a single folder. That way, when you upload the data to your dropbox account, the entire project history is archived/backed up. With SVN, you'll have to setup a separate server, which you'd also want to install in your dropbox account.

[wlievens]

Absolutely. I'm more of an SVN guy than Git, but you should probably try both to get a feel for what suits you best. Version control is an absolute must for any project above 25 lines.

[kellishaver]

Learn it early and use it often. It will literally only take a couple of hours to pick up the basics, and then it's jsut practice. Learn more from there as you need to. Even if you're a solo developer, version control is an invaluable tool.

As for which VCS to use, I personally prefer Git. I don't find it difficult to use or awkward at all. I've used SVN in the past and didn't care for it much, though that's probably just a personal preference.