Why should I use version control?

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.