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

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

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

------
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 :)

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

~~~
discojesus
_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.

~~~
calambrac
Eric Sink, author of a competing non-distributed version control system?

~~~
discojesus
_Eric Sink, author of a competing non-distributed version control system?_

yeah he's only interested in promoting Vault. Except he didn't mention Vault
at all during that exchange on DVCS - he only mentioned Subversion as an
alternative non-distributed version control system, and he said that DVCS
systems were definitely going to be the norm in the future. So, uh, no. :)

~~~
calambrac
I didn't say he was only interested in promoting Vault, or that he was being
dishonest. Conflict of interest doesn't have to be some evil shadowy plot.
Given that he's spent years working on his system and convincing himself it's
The Right Way, DVCS probably is more difficult conceptually to him. That
doesn't make him bad or a shill, it just means you shouldn't necessarily take
his word as the authority for vcs newcomers.

[http://www.nizkor.org/features/fallacies/appeal-to-
authority...](http://www.nizkor.org/features/fallacies/appeal-to-
authority.html)

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

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

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

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

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

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

------
elai
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?

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

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

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

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

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

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

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

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

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

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

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

------
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 :)

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

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

------
pinneycolton
Yes.

Yes.

Yes.

------
zackattack
ohmygod, learn version control from the get-go.

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

~~~
matthew-wegner
from the git-go?

