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.
11 Answers
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.
-
4They also allow you to fork. I want to quickly split my project down 2 paths and be able to compare them, and pick one to continue working with. It's all handled nicely by repo's, and it makes you feel more at home when you do HAVE to work in a repo with a team.– DanReduxApr 22, 2012 at 22:42
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.
answered Apr 22, 2012 at 22:43
-
You're right about there not being a reason to not use one. Whether Git is easy or not is debatable.– RomanApr 23, 2012 at 3:51
-
1I can't imagine working on any sort of project that takes more than a few minutes without using source control. Even on a solo project source control just makes life so much easier. I like Mercurial also, but Subversion is fine also. Apr 23, 2012 at 4:24
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!
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:
BACKUP. If my HD fails, I don't want to lose all my code!
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)
Makes it easy to setup a continuous build that runs my unit tests everytime I check in
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)
Gives a good history for the boss (and me) to see what I've been working on
When new programmers come onboard I can easily point them towards the code
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
Makes it easier to manage a re-usable code library that is shared across multiple solutions (I'm in the c# world)
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.
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 :)
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.
answered Apr 22, 2012 at 22:50
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…
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!
answered Apr 22, 2012 at 22:50
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.
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.
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.
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!
cd where_the_code_is; git init; git add .; git commit-m"Initial Commit"Now you have source control. That's a low barrier!git remote add {github address}; git push;now you have a backup.