Should I use a code repository if I am the only one working on a project? [duplicate]

Question

Possible Duplicate:
Version control for independent developers?

I am not sure if I should use a code repository when I am the only one working on a project.

Answer 1

Yes. You never know when more people might be brought on to the project. Also, repos allow you to rollback when you accidentally add something that doesn't work.

You could use git for version control on your own machine without the need for a centralized repo. However, as long as you're using git, you might as well set up a repo on on GitHub. It only takes a few minutes if you're already on there. If you're not on GitHub, you should take the time to become familiar with it. It's a useful tool.

Edit

As @DanRedux pointed out, it also allows you to easily fork projects and explore other paths.

Answer 2

Actually, there is little reason NOT to use a code repository. Just the fact that I can easily roll back to any prior version has covered my rear end so many times when I accidentally introduced regression bugs - despite my automated tests.

If you need a recommendation - try Mercurial. It's really simple, yet very powerful. I would avoid Git because of its unnecessary complexity. Of course, this is only my personal opinion. So choose whatever suits you best.

Answer 3

Well, nowadays with the third generation of Source control, it's not that hard to start using them specially git or mercurial, I cannot think on any downside of why you should not use any of them.

Also If you do not want to set a remote environment you can use sites like Github, bitbucket, CodeGoogle to keep your source up, and grab it whenever you want.

I have to disagree with @Christian git is actually a very simple and straighforward solution, well documented and very powerful. Personally I have used mercurial few times and short term so I can't have a strong opinion about it.

TL;DR the answer is Yes, Ja, Si, Oui!

Answer 4

I am the only developer at my company. I use SVN for anything that is currently in production or might possibly be in production someday. Ten reasons why I use it:

1. BACKUP. If my HD fails, I don't want to lose all my code!

2. Makes it easy to roll back to previous versions of the code in case I completely stuff something up (makes you feel braver when doing large refactors too)

3. Makes it easy to setup a continuous build that runs my unit tests everytime I check in

4. The continuous builds also create a "staging" version of my application for anyone else in the company to look at (or for testing, or UAT, or demos)

5. Gives a good history for the boss (and me) to see what I've been working on

6. When new programmers come onboard I can easily point them towards the code

7. Lets me tag a "current production release" version of the code, in case I need to deploy an urgent fix without introducing the new features that I'm working on

8. Makes it easier to manage a re-usable code library that is shared across multiple solutions (I'm in the c# world)

9. Keeps me up to date with everything in the SVN world (hey, the latest version of tortoise SVN automatically prompts you to update if you do a commit that is out-of-date, cool!). The great thing about working on your own is that it's much easier to test out a lot more things - you don't have to worry about breaking the code/build/tests/framework for anyone else.

10. If I'm off sick (or holiday, whatever) the code isn't stuck on my machine, the boss can get it out of SVN.

Also serves to reminds me that I'm a software engineer not just coding scum :)

Answer 5

A code repository is a history, and having a history never hurts. I've goofed things up in a bash shell script ~/bin directory, and having revision control bailed me out. Think of it also as a different kind of source code backup, as long as the repository is being backed up. I've restored our town's tax collection software from CVS, when migrating to a new Linux platform, and everything built after the checking out of the repository.

I would use the same software you use at work, or something more modern, like git.

Answer 6

I agree with Tim, yes, you should use some version control system. But I would use something simple where you don't need to setup a server. I use Git for all my projects, even if they are simple and small (at first…). To setup a Git repository all you need to do is git init, so it's really easy. Of course, if you have not used Git up to now it might not be the right choice for you…

Answer 7

Definitely! Purely for the reason that it will allow you to roll your code back to previous versions etc. Version control is worth it. There's only so much "ctrl + z" one can do!

Answer 8

Yes for anything bigger than a small script. One of the benefits is being able to charge forward with a new design and strong refactoring of your code base without worrying that you will obliterate the original copy or that will be a large pain to merge your changes into the original code base if you determine that your changes are ready to be rolled in.

Answer 9

For single developers the question simplifies to "Should I take backups of the source code if I am the only one working on a project". You most likely want to.

The additional benefits pale in comparison with this, but you will most likely find some of them very useful anyway. The advantages just show up much later in the process.

The second most useful feature is the ability to build the bits shipping to customers in a clean room environment. This ensures that the build is reproduceable which is very important when you need to maintain them later.

Answer 10

The benefits of having your code in a VCS are well documented. Regression/rollback testing, the ability to add people in the future, comment history of changes, etc.

But for very small "projects" that consists of only a few files or don't need versioned releases, you may be able to get away with absolutely bottom-of-the-barrel version control using RCS. RCS is the per-file Revision Control System that CVS was originally built on top of. If your goal is just get the benefits I noted above, then RCS will do, without requiring a centralized repository OR a steep learning curve.

I still use RCS to maintain a revision history of server configuration files, or individual shell scripts that don't have much use outside their particular areas. Once you start needing to package a number of files up together into a "release" version of something, you've outgrown RCS. But it still has its place.

My $0.02.

Answer 11

I am in this boat. Not only do I use source control, I build all the software on a completely separate box.

This makes sure that all the source code created on my machine has actually been checked in to source control. Plus I have a another backup of everything.

The cost of another machine is around £300 in the UK, so IMO you can't justify not doing this!