For quite some time I was living under the impression that in order to sync Git repos across multiple machines one had no choice but to use one of the hosted service like GitHub. It was until a few weeks ago that I tried to directly link to machines without using GitHub for the first time. It's actually pretty easy and straightforward.

Also, once you've set up a direct sync link between machines, that SSH key stuff on GitHub (yeah, that stuff that's required but never properly explained) also starts to make a lot more sense.


The only requirement on both of your machines (apart from Git obviously) is some sort of a SSH server. Both Linux and Mac OSX either ship with one or make it really really easy to install one.


I'll just cover Debian-like (Debian, Ubuntu, Mint et al.) distributions but I guess it will be equally easy on other distributions. To install i.e. OpenSSH all you need to do is type the following in your terminal:

> sudo apt-get install ssh openssh-client openssh-server


Mac OSX actually ships with a SSH server, it's just hidden by your firewall. I've found this relatively old instruction that simply opens the according port on your machine, making way for incoming SSH connections.


And that's it. Those servers come with smart defaults and don't need any more setting up.

You should now test the link by typing the following in your terminal (replace user by your username and machine by the hostname of the target):

> ssh user@machine

You should see a line asking you for your password. After identifying yourself you're presented a prompt (the stuff in front of the blinking cursor) as if you were on your local machine. Close the connection using

> exit

Your prompt should now change back to the one of the machine you're sitting in front of.

Sharing Public Keys

Now comes the part that you've probably already done on GitHub, maybe without noticing: You need to share your Public Key with the target machine.

Your public key sits in the file ~/.ssh/ and looks something like


To share your key with the target machine all you need to do is copy and paste that line into the file ~/.ssh/authorized_keys there. I know it's a bit tricky to copy and paste from one computer to another, you'll figure out a way. :-)

You should now test again by typing the following in your terminal:

> ssh user@machine

Except now you will not be asked for your password but instead be immediately logged in. That's the magic of Pubkey-Authentication.

If it still asks for a password check for typos in ~/.ssh/authorized_keys.

Cloning a repository

After setting up the pubkey authentication you can treat that machine as if it were GitHub: Cloning, pulling, pushing; everything will work as expected now. Start off by cloning one of the repositories on that machine:

> git clone user@machine:/home/user/path/to/repository

Again, replace user and machine with your username and the remote hostname but also make sure the path (the stuff following :) is absolute. Relative paths like ~/path/to/repo will not work here. You can easily find out the absolute path of a repo by executing pwd in the correct directory.

Bi-directional syncing

One caveat worth mentioning is the fact that you can't push into "checked out branches".

Say you have checked out master on your desktop workstation and try to push into it from your notebook. Git will reject the push because you would be changing files in the workspace, potentially irritating the person working on them.

The easiest way is doing it the other way round: Add the notebook as a remote to your desktop (enable the SSH server and share your public key first) and pull from it.

Easy, right?

The joy of being distributed!

Related: to avoid having to type user@machine every time, you can store this info in ~/.ssh/config:

Host fred
    User david
Host barny
    HostName 131.438.434.832
    User david

You can then do ssh fred and git clone barny:/repo newrepo

Thanks for sharing this!

I documented a similar workflow for private Git repositories.

You don't even need SSH. You can set up some bare repositories on a local hard drive and use them to push and pull to. Or you can use a mounted volume.

We have some shared servers where I sometimes store repositories for design files.

Set up a bare repository on a shared server to serve as the remote:

cd /Volumes/shared_server
mkdir git
cd git
mkdir repository_name.git
cd repository_name.git
git --bare init

Then set up a repository for the working files:

cd /path/to/local/directory
git init
git add .
git commit -m "Initialize repository"
git remote add origin /Volumes/shared_server/git/repository_name.git
git push origin master

I'm tempted to use Git for all sorts of backup and storage functions. I prefer it to rsync because of the history that it maintains. It just may not be the most efficient way of tracking changes to binary files.

You're all complete nerds.

But that's why I like talking to you ;o)

It's really useful to have this stuff written down somewhere, great work guys.

DavidOliver: I'm using that too. Pretty handy when you have messy hostnames and if you have no control over what your username is.

bauhouse: Yeah, I use quite a few local filesystem clones too, but not over remotely mounted volumes. The thing I like with SSH you don't need anything else besides SSH (wich is provided on even the most simple systems). Plus you get the sideeffect that SSHing into that machine becomes so simple (no username or password required, just a ssh desktop).

Mounting stuff always means you have to configure at least one more thing. Also I guess the additional layer will make things a bit slower than over SSH.

I'll just cover Debian-like (Debian, Ubuntu, Mint et al.) distributions but I guess it will be equally easy on other distributions. To install i.e. OpenSSH all you need to do is type the following in your terminal

For all the (amazing) ArchLinux users:

sudo pacman -S openssh
sudo /etc/rc.d/sshd start

That should suffice.

The funny thing is that I thought Mercurial had an advantage when it comes to simple syncing between machines: They have a hg serve command that shares the repo via anonymous HTTP.

But the fact that Git's solution is more secure and more persistent (no need to run anything on the remote machine before pulling) makes it so much more awesome. :-)

I'm pretty sure you can do the same with Mercurial if you have access to the repo to clone without using its built in server.

Update: you can. Just tried it.

hg clone

Yeah, I expected that. I just didn't expect syncing across SSH to be such a clean solution.

Just adding another little trick I use: setting up Git projects in Dropbox will allow auto-instant-syncing-Git-projects™ without any hassle. Doing this removes the need for 'local machines as remotes'.

Here be dragons™ Use at your own risk™ Own your data™ Don't drink and drive™ etc.etc.

Now, @phoque (and other sensible folks) will probably frown upon this but I've never run into issues and have enjoyed seamless Git bliss between multiple machines.

I simply set up ($> mkdir my-project && cd my-project && git init) my projects in my ~Dropbox folder and can continue working on them on multiple machines in the exact state I left the project.

At home I use a Macbook Air, I have a MBP and an iMac at work. I can literally start working at home ($> touch awesome.txt), stop and drive to my office, open my project on my iMac and find my # modified: awesome.txt file in full glory. No need for remotes etc.

Maybe obvious for you guys, but I was pleasantly surprised this worked so perfectly.

PS: FYI; I still use Remotes (Codebase/Github) and I backup.

That's a pretty awesome idea! I'm guessing you definitely have a Pro Dropbox account though ;)

Nope, I was just an early user and have about 10GB through referrals ;) Thinking about Pro though, Dropbox is awesome. Even better would be to self-host through e.g. Sparkleshare etc. But I have yet to find a service/tool that works as well as Dropbox.

Thanks David, looks like a nice clean and simple approach!

But I have yet to find a service/tool that works as well as Dropbox.

You could of course try to create one yourself :)

You could of course try to create one yourself :)


I haven't tried it yet, but it sure looks interesting.

Or SparkleShare which, coincidentally, is based on Git. :-)

@Remie I am not going to develop such a service myself. Way too difficult! :) @DavidOliver Interesting: have not seen it before. Will look into it. @Phoque I've seen/installed Sparkleshare but it's not nearly as polished/hassle-free as Dropbox. I will give it another chance soon.

Then I'd also like to try

@phoque (seriously) I'm interested to hear what you think of setting up a Git repo in a Dropbox folder. Can you think of issues?

As I understand it, a Git repo in Dropbox is fine as long as it's always only you using the repo and you always give the whole directory time to completely synchronise with Dropbox before turning off (it's only files), but if you have different users checking out different changesets/branches, making commits at the same time, etc. it would be a disaster.

Re. SparkleShare, I try to avoid Mono so I didn't use it, but it is looking very tempting... :-)

Good point re: different users checking out different branches in 1 shared Dropbox folder. That would result in a mess I guess.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details