Why should I use version control? [closed]

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.

Medlock

you mean you were reading "coding horror"... – Micro

@jason, no i was reading a post on reinholdweber.com – Medlock

It is a strange phenomenon that many developers (usually early in their careers) hold this view, and it's only when you force them to use source-control that the benefits start to unravel in their heads. – Dustcloth

@spender: I am ashamed of thinking like that as well some years back (high school). I could I do anything back then is still a mistery to me. – Manifestative

I use phpdesigner for an IDE and it has support for 1 called Tortoise SVN, I will deffinately look into these, it does sound like something I won't be able to live with after I learn to use it. – Medlock

Hands up who doesn't share Martinho's shame. :) – Dustcloth

@jason: I guess you mean "without" – Manifestative

I've been programming for 35 years and have never needed the version control most are talking about. My backups are cloud based and 100% automated and synced to all of my development systems. I never have to commit anything. Every time I save a file, it automatically creates a version which is backed up to the cloud. It's far easier and faster to do it this way as there's not another layer in the way that slows me down and I would still risk losing code between commits. Without a version control system, I never have this problem and have never lost code. – Corpora

@TimEckel You never needed to branch or merge? Never needed to revert a group of changes? Never wanted to tag a release? Never worked with another developer? You were cloud syncing 35 years ago, well before there was a cloud? Backups and version control solve different problems. There's no reason you can't backup your working code with Google Drive as well as store it in a Git repository. – Mexico

Don't even know what a branch or merge is. I write code lineally, there's only forward, not sideways. To revert I undo or load a backup (which happens almost never). No idea what a tag a release is or why I would use it. Other developers only mess up my code, I do it myself. If someone has an idea, they can submit it and I'll consider implementing. Now I cloud sync, before I did USB drive backups or to floppy before that. I simply see no need for a layer which just slows things down. – Corpora

Somebody show @TimEckel a bisection, where version control magically points you at a three line change from three months ago and says "the bug was introduced here." Mind=blown. – Sunward

@TimEckel , you are still using a version control, another type with less features. – Momus

You have a very narrow minded understanding of software development. Version control is by the far the single most productivity boosting tool in software. It gives you accountability, ability to recall past changes and in general some solid backup options. Hell its even awesome if you the only person working on the code, you can revert when you shoot yourself on the foot. Grow up and learn at least one. – Redoubtable

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

Pascha

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

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

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

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

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

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

@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. – Warfield

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

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

Manifestative

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

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

+1 for the bullet on never commenting out code – Smock

@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. – Palatine

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

Authenticity

...or "Copy of Copy of Copy of MyWork" – Dustcloth

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

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? – Medlock

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

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

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

Smock

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

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

Answer 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

Blasien

Answer 6

Even as a single developer source control offers a great benefit. It allows you to store your code's history and revert back to previous versions of your software at any time. This allows you fearless flexibility to experiment because you can always restore to another version of your source code that was working.

It's like having a giant "undo" button all the way back to your first line of code.

Giuseppe

Answer 7

Version control is almost impossible to live without after you start using it. It is indispensible if more than one developers are working on the same code base...but it also quite useful for a single developer.

It tracks the changes in your code and allows you to roll back to previous versions. It frees you to experiment with the knowledge that if anything breaks you can undo your changes.

Sepsis

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

Answer 8

You gain security (in the sense of having a back-up of your code) and versioning of your code (assuming you get into a habit of committing your changes often). Both are very good things even if nobody else ends up ever working on the code with you...

Vine

Answer 9

Version control is great for checking previous versions, even if you're working alone. For example, if you accidentally delete code or a file you can get it back; or you can compare previous versions to see why a new bug has crept in. It's also good if you're one person working in multiple locations.

My personal favourite is git.

Moult

Answer 10

There are a number of reasons to use version control, even if you are the only person who will ever touch the code.

• Backup - what if your hard-drive crashes? Do you have a copy anywhere?
• Revision history - Do you currently keep copies of code in different folders? Version control gives you the ability to track your changes over time and easily diff different revisions, merge, roll back changes, etc. using tools.
• Branches - the ability to test out some changes, still track what you are doing, and then decide whether or not you want to keep it and merge into the main project or just throw it away.

If you keep your code under version control, then it makes it really easy to see which files you have changed (or have forgotten to add to the baseline).

Warford

Answer 11

Something that no one else seems to have explicitly mentioned is the tagging or labeling of releases. If you have a client using version 1 of your software and you're busy working on version 2 what do you do when the client reports a bug and you need to build version 1.1?

A source control system will let you label every release you make so you can go back to it later, make the fix (and merge that fix into the new version 2 code) and make a new release without worrying that you might accidentally deliver something that isn't ready.

Source control is a core part of modern software development. If you're not using it (even for personal projects as the more experience you have the better) you're doing something wrong.

Usually one of the first questions I ask when being interviewed for a job is "What do you use for source control?" So far only one place has said "Nothing" but they were planning to fix that "Real soon now..."

Sneakers

Answer 12

The fact that other developers participate or not is totally orthogonal to the need of a version control system.

You can be the only developer but still will benefit from:

• a history trail of all your changes
• ability to go back and forward on that history
• ability to experiment with the source and while still having a working version (branching)
• a backup copy (especially if you use a different machine as the source control server, and even more if that machine is regularly backed up)

Now, if you have a group developing on the same codebase version control is still more necessary so

• people can edit the same file at the same time (depending on the particular system, but most sane ones allow you to do this)
• you can tell who did what to the code when

When there is more people involved it is more relevant which version control tool you pick, depending on the style of development.

Couldst

Answer 13

It is also about backing up old file that why it is called "Subversion". So you can manage multiple version of your work in which you can return back (revert) and manage the different implementation of it (branching).

Liris

Answer 14

You may find that you had a working version of your program.

You decide to add a few new features over a period of time and you release that.

You start getting bug reports affecting some code that you thought you didn't touch.

By using SVN, for example, you can move back to an older version, and check to see if the new bug exists. Once you find a version that introduced the bug it will be easier to fix it as you can compare the version that worked to what didn't work and see what changed, then it will narrow down the search.

Source control has many uses, even if you are the only developer.

Wallah

Answer 15

Sounds like you're looking for something a bit more light-weight. Check out Mercurial (awesome reference book). I use it for everything, from source code to personal correspondence.

Some benefits:

• Giant Undo button, so you can return the those halcyon days of last week when the code actually ran
• Throw-away code. Not sure if this is the best way to do something? Make a branch and experiment. Nobody but you ever has to know about it if you're using a DVCS like mercurial.
• Syncronized development. I develop on 4 different computers. I push and pull between them to keep the current, so no matter which one I'm at I've got the newest versions.

Naga

Answer 16

Even if you haven't been in a situation yet where you needed an older version of your program, having a source control gives you greater confidence to make major changes.

I found myself doing more aggressive refactoring after using source control because I always knew that a working version could be easily restored.

Ardra

Answer 17

I have also only recently begun to get interested in version control. In version control systems, you have the concept of a repository for your code. A wealth of new shell commands get learned very quickly so that you can interact with this repository.

Once you save your code to a file, you can then commit this to your project's repository. As you develop your code and commit your changes the repository develops a series of revisions. You can access any of these by checking out a revision. If you work alone it's unlikely that you'll be doing much checking out unless you lose your code files or want to work on a different machine. In these cases you'll usually check out the latest revision of all files.

For my own part, i no longer keep files or folders named 'project_old' when I decide to refactor something. Any changes I make are stored incrementally and I will always be able to step backwards to a project that worked as a whole. I rarely use FTP to deploy now because I just checkout my code through ssh. Only the files I've changed are downloaded and if I need to reload on the server the terminal is already there.

I found this talk on GIT to be really instructive; http://www.youtube.com/watch?v=4XpnKHJAok8

It's a google talk where Linus Torvalds makes an argument for using one version control system over another. In doing so he explains how they work using concepts and then compares different ways of implementing them.

Volteface

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

@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. – Momus

@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? – Sibylle

@Sibylle 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. – Corpora

Answer 18

You'll probably want something like subversion even if you're working by yourself so that you have a history of all your changes. You might want to see what a piece of code looked like once upon a time to remember why you made a change.

Having source control is also useful when you check in often. If you check in often, you'll always be in a state to roll back often too. Many times you could start going down one path to solve a problem and then realise it was the wrong path to go. Many times you could just keep barking down the wrong path and end up building a terrible solution - only because you didn't want to lose all your work. By checking in often, the last point of "happiness" is not far away so even if you go down the wrong path you can always roll back and try again and make a more elegant and simple solution. Which is always a good thing so you can understand and maintain what you wrote in the future.

Hyperbole

Answer 19

It depends on the size of the project and how often you change your mind about parts of it. For small projects where you're just getting something done in a linear fashion, version control is probably not going to be of much help (though if you accidentally delete or corrupt a file without version control, you'll be crying).

But a couple of weeks ago I met a friend who was writing an enormous hobby project on his own. He had ten or twenty copies of his code, with suffixes like "X1", "X2", "test", "faster" and so forth.

If you've made more than two copies of your code, you need version control. A good version control system lets you undo a change you made a while ago without undoing the stuff you did after making that change. It lets you see when certain changes were made. It lets you split your code into two "paths" (e.g. one for testing out a new idea, the other to keep your "tried and trusted" code safe until you've finished testing) and then merge them back together.

Dodgson

Answer 20

It is 2019. I am encountering objections, at this relative late date, to using Git; objections I see some raising here. This discussion has clarified greatly the imperative of using source control rather than simply making named back-up copies. One key point is source control use even where we've single developer projects. Nobody is perfect. You make mistakes. If you're exceptionally good and smart you're going to be developing more complex apps; but you're still gonna make some mistakes and this handles it. Geez oh Pete! I never use Linux but I think we all respect the great technical intelligence of Linus Torvalds. He recognized the importance of source control and he made key contributions to the inception of Git. That's a summary point for all the reasons given here. Torvalds gets it: source control is very important: use source control. Thanks to all who've commented on this long running topic.

Castellanos