I shift laptops and devices a lot, and mounting storage is not ideal between devices. For my use case I decided I liked a git repo the best for document storage (markdown files)
To be able to access that repo I wanted it to be accessible on my server, from my home via SSH. (Remotely I use VPN to my home network to sync)
When searching for remote Git repositories I mostly see paid alternatives or fullblown Git servers being advertised. That is too much functionality for me, and not necessary.
Solution
- Create repo on server
- Clone repo on client(s) via ssh
These are all that’s necessary, and it’s so much simpler than using Git servers.
1. Create repo (on server)
# connect to your server ssh yourserver # change directory to your project cd /git # create a git repo git init --bare notesmygoats.git
2. Clone repo on client(s)
# cd into the directory which will contain your git repo cd /home/notetaker/documents #git clone the remote repo git clone yourserver:/git/notesmegoats.git Cloning into 'notemegoats'... remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (3/3), done.
Tips
Use links to create structure
The directory /git/
is a link to a folder in my storage. I like to use links to create logical structure, that’s completely personal though.
If you can SSH into a server, you can use any directory for the git repo, just make sure you replace the clone command with the directory you’re actually using:
git clone yourserver:/home/youruser/mygitrepo
Bare repository
Copied from https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-init
The –bare flag creates a repository that doesn’t have a working directory, making it impossible to edit files and commit changes in that repository. You would create a bare repository to git push and git pull from, but never directly commit to it. Central repositories should always be created as bare repositories because pushing branches to a non-bare repository has the potential to overwrite changes. Think of
--bare
as a way to mark a repository as a storage facility, as opposed to a development environment. This means that for virtually all Git workflows, the central repository is bare, and developers local repositories are non-bare.