Working remotely, I often switch between a desktop at home and a laptop when I’m on the road. It’s as simple as it gets; in theory, I could work anywhere, on any computer, with just a few basic requirements.
However, one of these needs poses a serious obstacle: I need to have my current job with me. All previous attempts to solve this problem were wrong, but Git was the answer I was looking for.
Why use Git to sync local files?
OK, there are alternatives: shared drives, ssh, rsync, etc. So why use Git in this particular case?
On the one hand, I know Git very well. I use it every day, I’ve set it up to work the way I like it, and I even understand a little about how it works! Git is now a proven tool, with countless applications and commands to support it. It’s essentially the de facto standard for version control, and it generally does its job well, despite its complexity.
Anyway, I’m also looking to use version control with these files, so I have a proper backup and history of my work. Git is the obvious choice, so if I can leverage it to sync files across devices, that’s two birds settled.
Sometimes I resort to Google Drive to quickly host something in the cloud, but it feels fragile and takes more effort than it should. It’s the same with USB sticks, which aren’t always reliable, or external drives: too much tinkering for what should be an instant task.
Why should you avoid GitHub?
A possible solution to this problem would be to simply host a repository on GitHub. This gives you a centralized location that is always available (well, most of the time), provided you have access to the Internet.
There are two small problems here, however. First, the downtime I alluded to could be an issue, although it’s really not that common that I would base my decision on that alone. But hosting some of these files on a third-party server makes me nervous: Some of this work may be confidential, and what happens if I accidentally save a password or other sensitive data?
Sure, I could work with a private repository, but that all seems pointless: why involve a remote third party unless I really need one? It’s not like I’m going to use any of the collaboration or project management features of the GitHub platform, so it seems a bit redundant to me. There has to be a better way.
How to sync files with git
And there is a better way: Git local. Synchronizing files between machines is, after all, part of Git’s core mission, and doing it over a local network isn’t much different from doing it over the Internet.
You should find this system quick to set up; it just involves a few distinct parts. But each one is simple and when you’ve done it once, syncing is easy.
Enable remote connection
The first thing you will need to configure is SSH access. macOS calls this “Remote Connection” and you will need to use the mechanism provided by your operating system to do the same. You should only do this on one computer, which will host the repository.
Changing this setting will give you command line access when you run the following command:
ssh username@ip-address
Configure static IP addresses
This is another step that will depend on your environment. In fact, if you already have a local network, you may be able to avoid it altogether and use DNS to configure your Git configuration instead.
But I was starting from scratch and wanted to give myself as little work as possible. To avoid overcomplicating the process, I opted for IP addresses instead. The only problem is that you’ll need consistent local IP addresses, but a quick router setup should be enough.
Again, you really only need to do this on the repository host machine, but there’s no harm in setting it up for your other devices while you’re at it.
Create SSH keys
If you don’t want to enter your login information every time you sync the repository, I recommend setting up an SSH key on each client. This is a one-time setup that will then allow you to sync files to and from each machine you run it on.
Start by generating a key pair using the ssh-keygen program:
ssh-keygen
You will be prompted for a file name and an optional passphrase, which you may want to use for security reasons. When you have generated a key, download it to the host machine using this command:
ssh-copy-id -i /path/to/key/file username@ip-address
At this stage, I advise checking that everything works with:
ssh username@ip-address
Configure a bare repository
I found this to be the cleanest and easiest solution to implement. First, you’ll need to choose a computer on which to store the repository: not a working tree, but a bare Git repository that can serve as a central sync between clients.
Choose a suitable directory (ideally one that won’t move) and, inside it, run:
git init --bare
A bare repository contains git metadata files, like HEAD and config, at its root rather than in a .git directory, like a working tree does.
This article covers setting up a repository from scratch. If you want to do the same thing with an existing repository, see git clone --bare.
Clone the repository on each machine
On each machine where you want to share files, enter a directory of your choice, then run a command to clone the repository into a new working tree. On the machine that already hosts the bare repository, you can use a local path, for example:
git clone /path/to/repo
On any other machine, you will need to use the login@host format:
git clone username@ip-address:path-to-repo
For example, on my local setup, I ran this command:
git clone bobby@192.168.1.196:/Users/bobby/src/repos/bare/myproject
This will clone the repository into a working tree, much like cloning a repository from GitHub.
Work as usual (add, commit and push)
Now you can work as usual. Edit your files, save them and, from time to time, commit them to git:
git add .
git commit -m 'my latest work'
git pushDon’t forget to run git push when you’ve finished your work for the day or if you’re about to go out and work elsewhere. When you start working each day, remember to run git pull to get the latest updates on the machine you are using.
Obviously you can skip this daily process if you know you’ve only been working on the same machine, but it’s good to get into the habit of knowing you always have the latest work available.
Another potential option is to automate the git process using something like cron. This would keep git completely in the background, letting you focus on saving files and getting on with your work. An automated approach is much simpler if you have a set schedule and keep your computer on all the time.
