HN Explorer

Ask HN: Is version control worth learning early on?

70 points by colbyolson ↗ HN
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.

82 comments

[ 3.2 ms ] story [ 123 ms ] thread
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

[deleted]
(comment deleted)
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.

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.
caseysoftware
100% yes.

I've never found myself thinking "I wish I didn't have that version from before that big last change" but I have thought the opposite.

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.

yummyfajitas
Quite right. Here is a tutorial covering some of the basic tools.

http://software-carpentry.org/

I'd go so far as to say that every developer should know everything on this page, or at least some substitute (e.g. mercurial instead of svn, ruby or c instead of python).

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.

timwiseman
Interesting thought, and you have good points. A 25 line script probably isn't worth the hassle of version control.

The thing is that learning version control is well worth the hassle of version control for someone trying to become a programmer.

gaius
Definitely.

One of my favourite interview questions to ask is, what version control systems have you used. I don't really care if it's not what we use. But someone who can't talk fluently about whatever system probably hasn't worked on a large project, probably hasn't worked as part of a team, and probably hasn't had experience dealing with regressions. That's a red flag.

asjo
One of my favourite interview questions to ask is, what version control systems have you used.

I always ask what the applicants favourite editor is. Not because they have to use The One True Editor, but because they definitely should have one they prefer (which implies "know"). Craftsmanship warrants knowing your tools.

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.

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.

lsc
learn a version control. If get/svn is to complex, use rcs. Really, if I was learning today I would start with git.

But what you choose does not really matter. Learn a revision control system.

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!

mechanical_fish
Completely true, of course, but the original poster's use of irony wins more style points than yours. ;)

Irony is judged by how artfully it approaches the line of apparent total sincerity without going over. Your response is clearly ironic. But it's possible to imagine, for a few seconds during the first reading, that the OP is being serious. Only after you think about what he just said do you start laughing.

sho
Man, are you californian? I have noticed that what californians call irony and my own definition are completely different. What you're talking about I'd maybe call deadpanning - sorry, not really up on the various types of comedy. Irony would be more like a guy who had long publicly scorned version control, mocking all who used it, losing all of his code because of some problem which would have been easily avoided by the use of version control.

Guh, reminds me of what my friend used to do. He'd be acting all excited and say "Did you hear? Nine Inch Nails is having a concert here next month!" and I'd be like "Wow, cool, I want to go!" and then he'd crack up laughing and say "I can't believe you thought I was serious".

edit: he didn't deserve to be downvoted .. wtf. Maybe downvoting should cost the downvoter a point too, like on Stack Overflow. Would be an interesting experiment.

jmtame
if it matters, i doubt many early start-ups worried about or even used version control. we used dropbox when starting out because we never worked on the same code, and we had to hit deadlines quickly. as it turns out, we got funded, and we took the time to polish the code (and implement version control) when we had the opportunity. a vast majority of founders of yc funded start-ups i've asked have told me they did not use version control early on (ie justin.tv and airbnb didn't, although i think reddit always did).

i know for a fact that youtube for example did not touch version control early on. you should definitely appreciate speed when you're starting because your ideas could change (and your code).

it's a trade off, and eventually you'll start doing stuff like unit testing. at some point, the more time you spend perfecting your code, the less time you can spend prototyping and changing the idea if it needs to be changed. i don't think it's comparable to a "wear your seatbelt, you should ALWAYS be using version control in EVERY situation" thing, you should really think about whether you need it. you should worry about hard disk failures, so do a back up every once in a while with a flash drive or dropbox at the very least. but version control has its own learning curve.

gojomo
A benefit of learning version control early is that once you're good at it, it doesn't slow you down, even in early rapid/solo/investigational work. (The few tiny extra steps it requires quickly pay themselves back by providing de facto backups, reversing wrong turns, helping to debug or reconstruct prior reasoning, etc.)

I would guess most people on their second startups enable version-control from the beginning.

flashingpumpkin
I don't see how version control has an impact on speed...
ahpeeyem
I think if anything a VCS could make you faster because it frees you from worrying about whether you're going to make a change or delete something you can never undo.

With version control you're always safe in the knowledge that whatever you do, you can always 'revert' to the last version that worked.

etal
As a historical note -- git and hg didn't become popular and trivial to use until the past couple of years. When YouTube was written, free DVCSes were tricky to use, documentation was shakier and the best alternative, SVN, is a pain to set up for sharing over the internet. We're living in enlightened times now.
axod
svn update

svn add newFiles

svn commit -m "I did something"

There's not really all that more to learn, just check the docs or "svn help" but it'll certainly be well worth your time to get into the habit.

jasonkester
That's way more than I've ever learned about SVN, and I use it every day. Download a copy of TortoiseSVN and right-click your way to happiness.
axod
True, although depends on if you're naturally a mousey person or a keyboard/shell person.

For some reason I have an instant distrust of anything mousey - seems like a barrier between me and what is really going on. But as you say good option for those who prefer working that way :)

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.
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 !
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.
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.

bbsabelli
Yes. But don't just learn the tool, learn what problem it solves. Tools have changed significantly over the years, but the principles are the same.
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.

sh1mmer
I have to recommend the http://progit.org book, because Scott did an amazing job of explaining it step by step in a clear and concise way. It's also free online, which is an obvious bonus.
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.
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!

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.
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.

Jim_Neath
Learn git.

It's easy to do and will save you a whole load of ballache down the line.

Our front end designers picked it up pretty easily so it can't be that hard :P

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.

Confusion
I see a lot of people suggesting git, but I understand the interface is still rather, ehmmm, user hostile, with lots of obscure options, which makes it a lot harder to understand. Perhaps it would be easier to start with svn, using http://svnbook.red-bean.com/.

Concerning the question itself: yes. Yes. YES!

davidw
I'm using git because that's what I ran into first, but mercurial seems to be nicer from that point of view.
[deleted]
(comment deleted)
arethuza
I would suggest doing it sooner rather than later - there isn't that much to pick up and if you use a hosting service very little to install (I use the free service from Unfuddle - which is more than enough for my personal projects).
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.
bajsejohannes
I have not tried github, but I find bitbucket (Mercurial hosting) to address your issues properly. Everything else with that site is also right :)
scharan
Learn some version control and use it. Period. It saved my MTech thesis a couple of times. And that is something. Even if it is for just this one time, blindly take this advice. Will thank HN community later.