1-855-288-2260
We're here 24/7 to help!

Using Git for version control means having the ability to push and pull changes to code with just a few, simple terminal commands. With an account on a popular git hosting platform like GitLab, GitHub, or Bitbucket, software developers have quick and easy access to code from anywhere on the internet.

As a developer, you might need to store a second copy of your code locally – let’s say on your Mac. What if you could use Apple’s iCloud to store a local copy of your code and have it available on any of your Apple devices as well? This is certainly possible. Below you’ll learn how to setup iCloud as a local+remote Git repo.

Getting Started

First, you need an Apple iCloud account. You likely already have one if you’re running a recent version of OS X/macOS or if you have an Apple device running iOS. If not, set one up on your device or by visiting iCloud.com in a web browser.

Next, you’ll need to navigate to the folder on your local Mac computer where the existing code is stored. It should be setup as a git repo. If it’s not setup with `git init` yet, you’ll need to do that and commit all of the files before we continue.

The Git website has a great tutorial to help you get started with initializing a git repo. With that done, we can go over the `git add` command.

Git Add Remote

The process for adding a new remote is simple for users of any skill level.

If you have added remotes in the past using GitHub, this command will look familiar:

git remote add origin https://github.com/macstadium/example.git

That’s an HTTPS address, by the way; if you’re using SSH it’ll look like this:

git remote add origin git@github.com:macstadium/example.git

We can break down the command to make it easier to understand. Start with the git command and combine it with the remote and add subcommands which tell git what action to take in the current code repository.

Next, you have a name for your remote, and finally, the address of the remote. There is no strict naming guideline for remotes. Best practices state that if you have a single remote, name it origin. If you have multiples or plan to, you can name them based on the location.

An address is usually either http(s) or ssh, as mentioned earlier. In our case, it’ll be a local file path that we decide on shortly.

Git with Local Repos

Since GitHub and other remote code repositories have become popular locations to store code, many software developers may never use local repositories for git. It’s not wrong to strictly use remote hosting, but it does mean you are dependent on an internet connection to store a second copy of your code.

It’s beneficial to always have at least one git remote available. This provides for at least some form of redundancy in place for your code.

Having a local iCloud repo can come in handy in this situation. By being both a local directory as well as hosted cloud storage, you’re still storing code in a second local directory if you can’t access an internet connection to allow iCloud to sync.

It’s important that we prepare our remote directory before adding the git remote and pushing code to it.

Setting up a Bare Local Git Repo

If you’ve ever used GitHub or GitLab, you’ve likely created the repo on that remote service before pushing code to it. We need to follow the same process for our local repo by running one command. This command will create a bare version of our code repo (a non-working directory) that we can then push to and pull from.

First we need to know the location where iCloud stores user data on our computer. The directory for iCloud on a Mac running OS X/macOS can be accessed through your relative user directory or via the absolute path by traversing the root Users directory.

You should choose whichever you feel more comfortable with. Relative to your user home directory, the address is:

~/Library/Mobile\ Documents/com~apple~CloudDocs

If you use ls to list the contents of that directory from your terminal, you’ll see it matches what you can see in the Finder application from the OS X/macOS GUI.

Now, there are a few different routes you can take here. You can create directories within the iCloud folder as listed above. Or, you can create any number of subdirectories to organize them.

We’ll follow the latter path in this example by creating a directory called git within our iCloud folder to store the backup. We’ll also be naming the backup directory with the .git suffix; this is just a best practice for bare repos and not a requirement.

git init --bare ~/Library/Mobile\ Documents/com~apple~CloudDocs/git/example.git

You can see that I created a new directory, titled example.git, with the bare flag in the git subdirectory of iCloud relative to my home directory. The bare flag means this is not a working directory; I can’t navigate to that directory and see whole files like what is in my local directory that I started in.

If you’re curious, use ls to see what that looks like but don’t touch anything if you’re unfamiliar with it; directly editing files may corrupt the directory’s git structure which you cause instability or errors if we attempt a git push to it.

Now that we have a directory in our iCloud folder that has been git initialized with the bare flag, we can add our remote

Adding your Remote

The structure for adding a local repo is the same as a remote repo up. You need a name for your repo as well as the absolute or relative directory where you’ll be storing your code.

Back in our example code repo, we can go ahead and add the remote with the following command:

git remote add icloud ~/Library/Mobile\ Documents/com~apple~CloudDocs/git/example.git

You’ll notice that I named my remote icloud. This is a personal choice as mentioned earlier.We now have our remote setup. Let’s push to it for the first time and configure it as the default upstream if we desire.

Git Push to iCloud

git push icloud master

Simple, right? Every time we hit that command, we’ll be pushing to our folder in icloud. If we have internet, we’ll then see the icloud sync icon appear next to the folder in the Finder application.

That’s it, really. If the icloud remote is our only remote repo and we want to make it the default remote, we use the `-u` flag to mark it as the default upstream like so:

git push -u icloud master

Now we only need to use `git push` and git will know we mean to push the master branch to the remote titled icloud. And with that, we’ve completed setup of iCloud as local+remote git backup.Below are a few more tricks as well as tips in case you need to make changes or troubleshoot.

A More In-Depth Look at Git Remote

Besides add, there are several other ways to manipulate our git remotes. We can quickly remove the icloud remote with git remote remove icloud or we can change the url (maybe moving from HTTPS to SSH) with:

git remote set-url git@github.com:macstadium/example.git

Interestingly, rather than just replacing the url with set-url, we can also add another one to push to multiple repositories at once.

Let’s say we want the git push command to push our code to iCloud and Github simultaneously. We can’t set both as the default upstream using the -u flag mentioned earlier.

What we need to do is create a new multi-repo remote. We can title it all to make remembering it easier.

So we’ll run git remote add all git@github.com:macstadium/example.git to first add the github url. You can run git remote -v at anytime to see your progress and check your work.

Next, we want to add the local url to the iCloud directory:

git remote set-url --add --push ~/Library/Mobile\ Documents/com~apple~CloudDocs/git/example.git

Notice we added the –push flag. That means this url is only for pushing. We’ve done this because if we accidentally git pull from the all remote without using –push we’ll receive an error due to having two urls in the remote.

The –push flag tells git that we’re restricting this address to push only; we’re not allowing fetch from that second url. If this were a remote that was only for pulling, we could use the –fetch flag instead of –push.

Below are a few more references to look at if you need further examples.

References