Yes, of course.
You're misunderstanding what git is. I mean, why would you assume it's only useful for teams?
git is even more worth it if you're a single developer.
Pros:
- svn requires a server to run in the background. git on the other hand, is a simple utility, you just run it as if you're running
grep or ls or any other simple command line utility. You don't need to setup any server or anything like that.
- The .git folder is the entire repository, you can take it with you anywhere (for example, on a USB stick) and it will always have your repo. Your entire repo, along with its history, and everything else, and it's actually compressed very well, so it doesn't take that much of space. (Hint: that's why git doesn't need a server; when you run git commands, git just changes the internals of the .git folder).
- Branching and merging is really easy. You can work on experimental new features on a separate branch, and only merge when its stabilized. Meanwhile, you can do maintenance work on the master branch (e.g. bug fixes) and all the while you can keep merging the bug fixes from the master branch into your experimental (topic) branch with ease.
- This point is subjective, but I find it much easier than svn. I tried to use svn for a while, but found it too complicated, and often it got in my way (I don't exactly remember that what's and why's, I just know it wasn't a pleasant experience). For example, renaming files is not an issue. You can rename files and git won't make any fuss, it just doesn't care about the file name. The only thing is, you have to remember to add it after you rename it, it's as if you created a new file.
Cons:
- Not many visual tools. There's a git-gui, it's not bad, (I haven't used it much) but you don't wanna depend on it. You need to get used to using it from the command line. If you're used to visual tools with svn, this maybe a con, but in my opinion, the only con here is that you have to step a little bit out of your comfort zone to learn it; but trust me it's worth it.
- There maybe some issues with line-ending on windows, it's not a big problem if you're the only developer, but if you're developing on windows and others are developing on linux, you need to make sure that all files use unix-style line ending instead of windows', in order to avoid any issues.
- Due to lack of visual tools, resolving conflicts (when they appear) might be trouble some at first. I personally use WinMerge, and invoke the command
winmergeu <conflictfile> on every conflict file, to resolve conflicts. (Note: WinMerge is not a command-line merge tool, it's a visual merge tool, with a normal gui).
- This brings me to another point. While it's really easy to get started with git, there maybe some learning curve to dealing with issues that come up later (such as conflict resolution). If you don't branch and merge, then you won't even run into conflicts, but then again you'll also be missing a very powerful feature.
UPDATE:
I didn't notice the bit about you working from several different machines.
It doesn't make a difference, you just have to remember to push and pull whenever you switch to a different machine, but you already do this with svn: commit/update.
You'll get the power of branching/merging. Don't under-estimate this power.
How many times have you thought of implementing some crazy idea, but never dared to do it because you don't want to mess up your code? git relieves you from these worries. Just do it in a branch, if it works out, merge it to the main branch, if it didn't, delete the branch and forget about it.
Sure, you might say that you can do the same with svn revert, reverting back to the revision before you started the crazy idea. but what if you had bug fixes applied in the meantime? If you revert your crazy idea, you'll lose all the bug fixes/maintenance work you did while experimenting with your crazy idea.