Git as a backup and Version Control System

I want to use Git to backup my home drive, but I also want to use it开发者_开发问答 as a version control system for projects that will be stored in my home drive.

How would I go about doing that? Do I .gitignore all the projects root folders and make new repositories for them?

Edit:

Ok I explained what I wanted wrongly. I want to have a history of changes made to my home drive like I can get with Git and I also want to back that up.

I wrote a blog post about this a while back:

Version control systems, with the possible exception of SourceSafe, are great at keeping track of code. Why is that? Because they were designed to keep track of code.

Unfortunately, though, the features of a good VCS are entirely different – and often exactly the opposite – of the features which make a good backup system.

Take, for example, file ownership. A good VCS will, very rightly, ignore file ownership: when I check out someone else's code, I should be the owner of those file - not whatever uid originally created them. A good backup system, on the other hand, will do everything in its power to preserve file ownership: when I restore from my backups, I want /etc/shaddow to be owned by root and /home/wolever/ to be owned by wolever.

BUT, if you really want to, check out bup - as far as I can tell, it does backup with git "right".

Use rsync for backup. Use git for version control.

You really want to use rsync to backup your data. Check out the following url for more information on rsync and also some examples on how to backup your data:

http://www.sanitarium.net/golug/rsync_backups_2010.html

I've found the backintime-gnome (glade/python, separate backend?) to be good for scheduled incremental backups, it works for your daily, weekly, monthly etc.. Then Git repos for source files or other change-critical data would wrap it up nice. I haven't played with the bachintime-common backend commands but they all seem to be python.

I'm using it in Ubuntu, "Keep in mind that Back In Time is just a GUI. The real magic is done by rsync (take snapshots and restore), diff (check if somethind changed) and cp (make hardlinks)." -http://backintime.le-web.org/documentation/

There are a few projects that aim to solve that problem:

bup seems to have made the most progress: https://github.com/apenwarr/bup

But you may also want to search for gibak or coldstorage.

Great idea, i actually use it daily and it works fantastic until your pc crashes mid-commit and corrupts your repo. First time that happened it took me a day to fix everything and restore backups, you end up learning quite a bit about git internals in the process so that's an added benefit. Assuming you're on linux, I recommend having a local copy of the .git dir backed up on a separate drive or whatever, then git init at the / root of your os and use .gitignore to control what gets versioned. Some files are "special" so you probably wanna exclude them by default, like stuff in /proc. You can watch exactly what different software is doing to your fs and rolling back broken installations and keeping track of configuration, logs, etc. is a breeze. I don't know why all these nay-sayers are saying "don't do it" because I did it and it's very practical and very awesome. Like I said only downside is corrupted repo when something unexpected happens, but if you prepare for that fixing a broken commit is just a matter of copying the pre-corrupted .git over the corrupted one.

That reads pretty much like what I'm doing. I have a git repository in my home directory, but I use that to track only those configuration files that I can edit by hand. (This rules out state files kept by "modern" desktop environments and almost everything that is stored as XML.) Everything else goes into .gitignore. Once upon a time, I decided that my "notes" directory and my ~/.emacs.d should go into their own repositories, so I created git repositories in those directories and had the main repository ignore them.

I don't use this setup for backup purposes but to synchronize the tracked files between accounts on different machines, but I suppose that this could also work for backups.

On windows git-extensions as well as the gitGui allow you to clone a repository, which would allow you to make a backup without all the files in .gitignore.

Next 7zip it up and you are done!

For the projects that you want to keep a close track or make some rollback, you can use git in a normal way.

If you want to upload projects with large files and you don't want to be able to checkout to previous commits in order to get old files, you can use git lfs. This will make the .git folder much smaller if to make changes on large files:

Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server like GitHub.com or GitHub Enterprise.

This solution would be an approach to have a Git Project as a backup. Or even you can use both in a same project, tracking and keep changes only with the files you want.