Why should I use version control if I'm working alone and already back up regularly?

Question

I'm working on a project:

• Just me, no collaboration/source code sharing
• I'm already backing my code up regularly, and I can use Dropbox to restore mistakes

What advantages do I get from setting up a git repository (or something else) for my project?

Answer 1

Revision history. Knowing which changes happened when and how it affected your project. It's also just good practice to be in the habit. If you ever expand the project and need more people to help, you'll already have a repository for other people to work with.

Answer 2

Ever make a change to a file and think "Oh sh**..., I wish I could undo that!".

That's why a one man development team still needs version control.

Edit: I should clarify that version control allows you to cherry pick revisions over your entire project history. With most systems you can do a side-by-side compare before reverting as well. This is a far cry from simply picking a backup at some point, restoring it, and hoping you have the file you wanted.

Answer 3

You're saying you're using Dropbox to restore mistakes (or "can"), so in effect, you're using Dropbox as your version control. A very simple, badly designed one. Dropbox is great for many things, but it won't help you figure out which files were changed together in the same time, or return a folder to a particular snapshot.

These are things that a "proper" version control can do better for you.

Answer 4

Ever look at some piece of code and think, "Why did I do that?" Source control will answer that for you, via timestamps and comments on each commit.

And if nothing else, knowing how to use source control is a valuable skill for a developer.

Answer 5

Once you start using version control (for a small project, may I recommend the easy to setup Bazaar?), your question will answer itself almost instantly, and with a clarity no discussion board could ever provide :)

Answer 6

• Revision History
• Check-in comments
• Changesets
• Branching
• Tagging

Answer 7

Metadata. You can tag and comment on checkins. Even though I work in a team environment I often use this to maintain my train of thought and/or keep track of items I have completed.

Answer 8

To play devil's advocate, I am thinking Distributed Revision Control is more useful than just a simple version control system that is centralized.

For an individual developer, distributed tools are almost always much faster than centralized tools. This is for a simple reason: a centralized tool needs to talk over the network for many common operations, because most metadata is stored in a single copy on the central server. A distributed tool stores all of its metadata locally. All else being equal, talking over the network adds overhead to a centralized tool. Don’t underestimate the value of a snappy, responsive tool: you’re going to spend a lot of time interacting with your revision control software.

Distributed tools are indifferent to the vagaries of your server infrastructure, again because they replicate metadata to so many locations. If you use a centralized system and your server catches fire, you’d better hope that your backup media are reliable, and that your last backup was recent and actually worked. With a distributed tool, you have many backups available on every contributor’s computer.

The reliability of your network will affect distributed tools far less than it will centralized tools. You can’t even use a centralized tool without a network connection, except for a few highly constrained commands. With a distributed tool, if your network connection goes down while you’re working, you may not even notice.

Answer 9

1) Once the version control system is set up, it will make your life so much easier. Manually backing up your source changes? Oh man, please no. What a PITA.

With version control in place, you just fire off a command. It tracks what changes and makes it easy to save them.

Why would you want to punish yourself by manually handling version control? Using git to track local changes is SO easy. Easy to set up also.

2) Keeping track of the history. Keeping a history of commits manually will almost immediately get out of hand.

Answer 10

Also check out Kiln and Fogbugz (which work in combination with Mercurial) They offer free accounts to students or teams of one or two people. http://www.fogcreek.com/

When you look at that, You might wonder why of all things I would recommend a distributed version control system to a single dev...

Well, overall I think its extemely useful, and Kiln and Fogbugz is super easy/fast to set up.

The key thing is, that merging of branches work way better in distributed version control systems like mercurial or github. So if you got a good part of your current project coded, and you have a really wild idea, you can branch it, and when the idea actually works, merging it back works really well. And because the merging works, until you find your wild idea works, you can still add other features and fixes to the trunk in the meantime.

Kiln's commenting / review functions that are syncronized with your versions make sense for a single person also, I think. I know I have to remind myself of needed improvements to some part, or to review something, or I'll forget.

This package is really well integrated and worth trying, they have good and short blurbs on the concepts on their site.

If you think its overkill, maybe so, but I think the extra horsepower in this setup will not get in your way.

Answer 11

The feeling, "Oops. Guess I should have spent time on that" in a job interview isn't fun, especially on something so helpful/essential. Prospective employers like to see flexibility and responsibility, even if your CV of code is great. :)

I've found that using version control (git is my preference) keeps me disciplined into rolling out batches of progress in my code, and I suspect it leads to other best practices as well.

I'm also a solo developer and I've never shared a repo.

Answer 12

Because most of the code you write is wrong. Mine certainly is and I am considered a damn good coder.

Its nice to be able to backtrack to a working version, also, you will find users ( and this may include yourself! ) flip flop between "I want it all" and "I just want a summary" its useful if you have the "I want it all" version safely stashed.

Answer 13

Lots of good reasons why to do it in the other answers. Personally, I like knowing I can look back at code that "used to work before I tried to fix that bug"; a situation that occurs far more often than I'd like.

For my personal needs, I've found that fossil is a good choice. It is distributed, low ceremony, installs as a single executable file, and available for Windows, Mac, and Linux out of the box and portable beyond that. It provides a wiki and ticket tracking in addition to revision control. It has a built-in web server, used along with your browser to provide a GUI for management tasks, and useful for ad-hoc cloning and updates. It is easily integrated with a web host. Its home site is served by a copy of fossil, for instance.

Answer 14

In addition to already listed

• gives you metrics (you can see how many commits you made, when and even for what reason)
• comments - gives you another place to document and organize your code, which in turn gives you a new ways to manage your code
• memory - you can track exactly what you changed when you were fixing such and such issue (you have full trackback at your disposal)

Answer 15

I recommend using bzr as it works best for someone who is just using it for their own code (not a team) as it doesn't require backing up to a server (all revisions are stored with each "branch")...

As far as the benefit, its so you can roll-back changes in the code to any point in time, so if you do daily backups, you can roll-back the code to get it from any day that you made a backup. This way you can feel comfortable re-writing code or deleting old code that you think you won't need but if you do end up needing it again it is accessible. For larger projects it helps with debugging since, if a new feature makes a bug appear you can roll-back to earlier if needed.