Why should I use version control?

Question

I was reading a blog where the writer said this

"Code doesn’t exist unless it’s checked into a version control system. Use version control for everything you do. Any version control, SVN, Git, even CVS, master it and use it."

I have never used any sort of version control and I do not find it that great. I have googled it and looked at it before, but I just need it put into children's terms if you will please.

As I understand it right now, things like SVN are for storing your code online for a group of users or other developers to have access to the same code. Once you update some code, you can submit the new version and the SVN will keep copies of old code as well as the new ones you update.

Is this the basic idea of it or am I getting it completely wrong?

If I am right, then it might not be much use if I:

• Do not have other people working on the code.
• Do not plan on letting others have the code.

Solution 1

Have you ever:

• Made a change to code, realised it was a mistake and wanted to revert back?
• Lost code or had a backup that was too old?
• Had to maintain multiple versions of a product?
• Wanted to see the difference between two (or more) versions of your code?
• Wanted to prove that a particular change broke or fixed a piece of code?
• Wanted to review the history of some code?
• Wanted to submit a change to someone else's code?
• Wanted to share your code, or let other people work on your code?
• Wanted to see how much work is being done, and where, when and by whom?
• Wanted to experiment with a new feature without interfering with working code?

In these cases, and no doubt others, a version control system should make your life easier.

To misquote a friend: A civilised tool for a civilised age.

Solution 2

Even if you work alone you can benefit from source control. Among others, for these reasons:

• You don't lose anything. I never again commented out code. I simply delete it. It doesn't clutter my screen, and it isn't lost. I can recover it by checking out an old commit.

• You can experiment at will. If it doesn't solve the problem, revert it.

• You can look at previous versions of the code to find out when and where bugs were introduced. git bisect is great in that regard.

• More "advanced" features like branching and merging let you have multiple parallel lines of development. You can work in two simultaneous features without interference and switch back and forth without much hassle.

• You can see "what changed". This may sound basic, but that's something I find myself checking a lot. I very often begin my one-man workflow with: what did I do yesterday?

Just go ahead and try it. Start slowly with basic features and learn others as you go. You will soon find that you won't ever want to go back to "the dark ages" of no VCS.

If you want a local VCS you can setup your own subversion server (what I did in the past), but today I would recommend using git. Much simpler. Simply cd to your code directory and run:

git init

Welcome to the club.

Solution 3

Version control is a rare tool that I would say is absolutely required, even if you are only using it as a solo developer. Some people say that it's a tool that you live and die by, I agree with that assertion.

You probably use version control right now, even if you don't know it. Do you have any folders that say "XXX Php Code (December)" or "XXX.php.bak.2"? These are forms of version control already. A good version control system will take care of this for you automatically. You will be able to roll back to any point in time (that you have data checked in) and be able to see an exact copy of that data.

Furthermore, if you adopt a system like subversion, and use a remote repository (such as one on a server you own), you will have a place to keep all of your code. Need a copy of your code somewhere else? No problem, just check it out. Hard drive crash at home? Not an issue (at least with your source code).

Even if you don't use version control now, you will likely use it at one point in time later in your career and you could benefit from becoming more comfortable with the principles now.

Solution 4

Even working alone, has this ever happened? You run your app, and something does not work and you say "that worked yesterday, and I swear I did not touch that class/method." If you are checking in code regularly, a quick version diff would show exactly what had changed in the last day.

Solution 5

Here's a scenario that may illustrate the usefulness of source control even if you work alone.

Your client asks you to implement an ambitious modification to the website. It'll take you a couple of weeks, and involve edits to many pages. You get to work.

You're 50% done with this task when the client calls and tells you to drop what you're doing to make an urgent but more minor change to the site. You're not done with the larger task, so it's not ready to go live, and the client can't wait for the smaller change. But he also wants the minor change to be merged into your work for the larger change.

Maybe you are working on the large task in a separate folder containing a copy of the website. Now you have to figure out how to do the minor change in a way that can be deployed quickly. You work furiously and get it done. The client calls back with further refinement requests. You do this too and deploy it. All is well.

Now you have to merge it into the work in progress for the major change. What did you change for the urgent work? You were working too fast to keep notes. And you can't just diff the two directories easily now that both have changes relative to the baseline you started from.

The above scenario shows that source control can be a great tool, even if you work solo.

• You can use branches to work on longer-term tasks and then merge the branch back into the main line when it's done.
• You can compare whole sets of files to other branches or to past revisions to see what's different.
• You can track work over time (which is great for reporting and invoicing by the way).
• You can recover any revision of any file based on date or on a milestone that you defined.

For solo work, Subversion or Git is recommended. Anyone is free to prefer one or the other, but either is clearly better than not using any version control. Good books are "Pragmatic Version Control using Subversion, 2nd Edition" by Mike Mason or "Pragmatic Version Control Using Git" by Travis Swicegood.

---

Original author: Bill Karwin

View more solutions

Comments

[spender]

...or "Copy of Copy of Copy of MyWork"

[Robert Venables]

@spender: Exactly, that's what I remember from the dark days before I started using version control :-)

[JasonDavis]

that does sound nice, so it can be local and doesn't have to be on the web for anyone to see? I use php designer, I love it and it has integration for Tortoise SVN, not sure if that is a good one

[JasonDavis]

It does sound very useful and my current project is somewhat large, at least 150-200 files, how does this work, i hear "version" doe that mean like version 1 and version 2, if the number increments, what if I modify 1 file and not the rest, will I have 200 copies of unmodified code or just copies of file that are modified?

[1800 INFORMATION]

just use anything at all to start with - then after a while when you know a bit, read up on alternatives and try one of them out, then another and so on

[spender]

Only the delta of your changes is stored, so if you change one line in one file, that is all that will be stored at that version. A file in version control can be thought of as the sum of all its changes

[Almo]

This guy has nailed it. Even when I work on projects alone, I prefer to have some version control running. Perforce's fully-functioning demo for 2 users is great for that.

[naught101]

@jasondavis in response to your specific questions (even though you probably know by now), you can use any distributed VCS (git, mercurial, etc) locally, without a server. You could also use a centralised VCS (CVS, SVN, etc.) locally, but it'd be much more annoying to set up, and wouldn't provide much benefit. Regardless of the VCS you use, you can have it on a server and still not have it public (useful for transferring between computers, and providing another backup) - search for "private repository". You can't use TortoiseSVN with git, but there's a Tortoise-Git out there.

[potasmic]

sounds useful.. until i have to learn and master it. heh

[sleske]

Good points. However, note that version control is not a backup! A backup is stored on a separate system/media, and keeps old backups for a while (just in case your repository gets screwed up somehow).

[si618]

Couldn't agree more sleske. That's why along with our standard VM backup and nightly repository verification, I keep a mirror repository which is synced hourly and is also backed up and verified :) We use Subversion and have found svnedge to be a good product.

[Tim Eckel]

I've never used version control and have never had any of these problems. All of my source backs up automatically and instantly to my home cloud storage every time I save locally. It automatically archives the last 100 versions. All 5 of my development systems are synced to my cloud storage and all are synced in real time (or as soon as they're turned back on). I distribute my code by using a website that provides information, help files, examples, and the source code itself. The advantage of doing it this way is that it's 100% automated and far easier than learning command line commands.

[Tim Eckel]

Or, I just pull the latest version from my backups that are created every time I save a file.

[Tim Eckel]

I find version control slow, inefficient, and gets in the way of development. Far easier to setup an automated cloud backup of all files that automatically saves the last 100 updates. Nothing to ever get or push or sync. Just code.

[Tim Eckel]

But what if you break something between commits? Then you're lost. When using automated versioning you never have this problem that exists when using useless versioning services like GitHub and the likes.

[si618]

Hi Tim, how do you track your change history? How do you link your change history to an issue tracker or release notes? How do you manage merging different branches of your code? How do you find the changes you made in your last 100 versions? Maybe if you code alone, or never worry about why you changed code, then maybe just having a backup is enough, but I bet once you used a decent VCS you will understand why so many people use them.

[Abhinav Gauniyal]

@TimEckel and some other people just revert their changes :)

[Abhinav Gauniyal]

@TimEckel what do you mean by 'break something b/w commits' ? If I write something after my last commit and commit new changes with non-working code, then I just revert my changes to last commit. As simple as that.

[Charleh]

@TimEckel saying that GitHub is useless is like saying that Linux is useless - millions would disagree with you, but you are saying it anyway because you are obviously smarter than those millions, right?

[Tim Eckel]

@Charleh just because millions use it, doesn't mean it's good. Millions still use AOL, and have Britney Spears albums. I use GitHub every day, and hate it every time I use it. I see no need for it, it gets in the way and slows things down.

[dan carter]

@TimEckel If you have a simple workflow like that with no branching and only one developer, you release that using source control control is as simple as pushing one button in your editor to save your work to the repository? No complicated command lines to learn.

[henrebotha]

I have traveled through time to correct the comment above me: version control does not necessarily only store the delta, but it represents the version as a delta.

[12431234123412341234123]

Points 0,1,2,3 are also possible without version control. Copy you source for every version and go back if you did it wrong and use diff to check changes.