Ask HN: Is version control worth learning early on?

https://news.ycombinator.com/item?id=801824

by colbyolson • 17 years ago

70 80 17 years ago

news.ycombinator.com

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.

Tichy• 17 years ago

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

alanthonyc• 17 years ago

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• 17 years ago

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• 17 years ago

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• 17 years ago

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• 17 years ago

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• 17 years ago

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• 17 years ago

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.

zackattack• 17 years ago

ohmygod, learn version control from the get-go.

http://www-cs-students.stanford.edu/~blynn/gitmagic/

matthew-wegner• 17 years ago

from the git-go?

SwellJoe• 17 years ago

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• 17 years ago

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.

ivanstojic• 17 years ago

I could never figure out Git until I read this:

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

lsc• 17 years ago

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• 17 years ago

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.

sho2• 17 years ago

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• 17 years ago

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.

jmtame• 17 years ago

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.

axod2• 17 years ago

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• 17 years ago

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.

axod2• 17 years ago

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• 17 years ago

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• 17 years ago

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

Bjoern• 17 years ago

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• 17 years ago

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• 17 years ago

+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• 17 years ago

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• 17 years ago

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• 17 years ago

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• 17 years ago

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• 17 years ago

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

csytan• 17 years ago

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• 17 years ago

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• 17 years ago

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• 17 years ago

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• 17 years ago

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• 17 years ago

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• 17 years ago

I'm using git because that's what I ran into first, but mercurial seems to be nicer from that point of view.

arethuza• 17 years ago

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• 17 years ago

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• 17 years ago

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• 17 years ago

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• 17 years ago

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.

discojesus6• 17 years ago

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.

moe• 17 years ago

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.

JshWright• 17 years ago

I'm not sure moving from hg -> git would be a "step up". It would be a lateral move at best.

discojesus6• 17 years ago

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.

exactly - if he starts out with something like git, he's probably going to burn out and have a bad impression of source control, which doesn't help anybody.

gcv2• 17 years ago

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.

discojesus6• 17 years ago

shrug Eric Sink said it himself: "DVCS's and git are conceptually much harder than tools like Subversion"

personally, I agree with him, and given that the issue at hand is "what should this guy start out with to gain the habit of using version control" and not "what is the most awesome version control system ever where you could just imagine a merge and it does it for you while you're on an airplane using a hand-cranked One Laptop Per Child", I think conceptual ease is what we're really going for here.

idlewords• 17 years ago

de gustibus pravis? What is pravis?

calambrac5• 17 years ago

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.

discojesus6• 17 years ago

Why do you think subversion is easier to start with?

the program model of a system like subversion pretty much == the user model for source control for someone who is new to source control. Hence, easy to start with.

You have to understand the difference between the local copy and the repository

Which is about as hard as understanding the difference between "your wallet" and "the bank."

And I personally don't think the day-to-day use is any easier, either, unless you're only working with one branch

Which he would be almost all of the time, and when he comes to grok version control pretty well (as stated) he could certainly move on to something like git.

iamelgringo• 17 years ago

If you're doing python development, I'd suggest learning Mercurial (HG). I actually find it simpler to use than SVN. And Python itself is moving to HG for version control.

Also, if you're on Windows and you want to do SVN, feel free to pick up Tortise SVN. It adds SVN extensions to explorer, and the tutorials are really rather good.

silentbicycle• 17 years ago

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.

lo_fye• 17 years ago

Absolutely learn it now. I suggest reading "Pragmatic Version Control Using Git" (Subversion & CVS editions also available), from The Pragmatic Programmers. Excellent book. Short & straightforward.

acg• 17 years ago

You could view SCM systems as dropboxes for code. When you write code you want to go back and make edits like you said. These tools allow you to do this and keep track of the life of your program and to learn the basics you would only really need to learn how to get the version you want, put back your changes and how to add/remove artifacts from your project.

Git or SVN would be ideal for what you want, a dropbox is less than ideal.

pinneycolton• 17 years ago

Yes.

tiffani• 17 years ago

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

bitwize• 17 years ago

HELL TO THE YES.

I'm not l33t enough yet to check /etc into VC, but everything textual that I work intensively on -- code, writing -- gets its own git repo. It will save your bacon later on down the line: trust me.

mattdennewitz• 17 years ago

learn svn, because it's like the english language of version control. then, move on.

lallysingh• 17 years ago

Learn both SVN and a test framework now. Do it right from the start.

If it seems like too much at first, think of all those programmers who complained about people learning OO or structured programming from the start.

kellishaver• 17 years ago

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.

tmikew• 17 years ago

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.

Ixiaus• 17 years ago

VCS all the way, make that your priority. Matter of fact, I use VCS for more than just my program source code; I use it personal documents, files, etc...

Subversion is my preferred tool, others seem to like the GIT/Bazaar/Mercurial bandwagon too though.

elai• 17 years ago

Put your mercurial/git repo in your dropbox! Remote backups + versioning.

What I've never understood is why version control systems cannot just detect if a file has been deleted automatically and remove it from the repo automatically. And link back up to it if it reappears?

billclerico• 17 years ago

i'd just write code. in fact, we used dropbox as our version control system for a month or so in the early days. you'll need to figure it out eventually, but get your bearings first.

Ask HN: Is version control worth learning early on?

Related Stories