> I am interested in using git as a versioning and backup solution for
> my work.
> I have access to a networked drive and my computers' local drives. I
> would like to be able to access my repository from a number of
> computers, all of which have access to the networked drive.

"Backup" solution can be achieved by combining `git push --mirror
ORIGIN` for "saving" data and `git fetch ORIGIN` (plus necessary fast-
forwarding of local branch(es)) for getting the data back into another
local repo, with ORIGIN being set up to point to the backup repo.

I use similar workflow (though my "backup" repo is accessible via SSH)
and it can be set like this:

1) Create a bare repository on your networked drive using `git init --

2) In your work directory run `git init` to make it managed by Git.
What results, will be assumed to be our first local repo in this

3) Create a "remote" named "origin" pointing to your backup repo:
git remote add origin file://path/to/your/backup/repo

It should be noted that you could call it any way you like, say,
"backup", but the name "origin" is special because that's what Git
creates for the remote repo when you clone it using `git clone`. So
using "origin" in our case makes setup more unified with the common

4) Create a convenience alias for pushing the changes:
git config alias.backup 'push --mirror origin'

This step is absolutely unnecessary, it just makes things simpler.

5) Add the files, make the root commit and "back up" the local repo by
git backup
which will result in running
git push --mirror origin

6) Now the trick is to make the "master" branch in the local repo
track the backup repo. This is just to make our local repo look as if
it was cloned from the backup repo.
The simplest way to do this is to just recreate the master branch:
a) Run `git log` and find out what's the name of the initial commit.
b) Check that commit out:
git checkout COMMIT
c) Delete the master branch:
git branch -d master
d) Get the up-to-date state of the backup repo (which will bring its
master branch in):
git fetch origin
e) Make your local master branch track that of the backup repo:
git checkout -b master origin/master

(I'm sure there's more logical way to do this, but I have never
managed to understand how I can make an existing local branch to track
a remote branch just by running `git something`.)

To set up another local repo, just clone the backup repo:
git clone file://path/to/your/backup/repo
and then configure the "backup" alias for it, if desired.

Now the workflow is like this:
1) Make some changes to a local repo.
2) Run `git backup` to push all the changes to the backup repo.
...and on another local repo:
3) Get the changes from the backup repo:
git pull
4) Return to point 1.

Observe three subtleties:

1)  `git pull` tries to merge changes from the remote branch it is set
to track. That is, if you are on the "master" branch in your local
repo, and do `git pull`, you will get your local "master" branch fast-
forwarded to the "master" branch as was backed up from another local
repo. So, if on the first local repo you did some work on another
branch (say, "another"), and then "backed it up", on another local
repo you probably want to get that another branch. This has to be done
by hand:
git fetch
git checkout -b another origin/another

2) While `git push --mirror` pushes all possible changes to the
specified remote repo, `git fetch` (which is used by `git pull` also)
omits tags which are unreachable from any fetched branches.
Unreachable tags can be useful sometimes though, and if you pushed
some of them from one local repo, you had to explicitly get them into
another using
git fetch -t

3) This workflow assumes you have no local modifications on your local
branch when you do `git pull`.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to