Git Repositories

The device can host git repositories. You clone, fetch and push over HTTP with any git client, and you can publish a website with every push. Your code lives on your own hardware.

Creating a repository

On the Content tab, choose New Git Repository… and it appears in the tree as a folder with the name you gave it and a .git directory inside. A repository is an ordinary checkout and not a bare one, so the files themselves are right there. You can browse them in the Files app, open them on the network drive or read them with an S3 client like any other folder. The detail screen of the repository shows the clone URL and the branch that is checked out, and lets you switch to another one.

Cloning and pushing

Repositories use device accounts, which are the same username and password as the network drive. The access level of the repository decides who needs one:

• Private or Protected: cloning, fetching and pushing all require an account.
• Public: anyone can clone and fetch, and pushing always requires an account.
• Off: the repository is not served at all.

Over HTTPS, clients sign in with the ordinary password prompt or with one of the API tokens of the account. Plain-HTTP connections on the local network never send the password itself, as the server uses digest authentication there. You can also scope an account to particular repositories, and the ones it cannot reach answer as if they were not there.

API tokens

An API token is a long random string you use instead of the password of an account, so a script or a build machine can hold a credential of its own that you revoke without changing any password. Once the server hosts a repository, a Git Tokens section appears on the screen of each device account in Settings → Authentication. Tap Create API token… and name it after the machine or script it is for. The token is shown once in full with a Copy button, and after that it sits behind dots like the password and needs Face ID, Touch ID or the passcode to be read again.

You paste the token where a git client asks for a password, or as the username with the password field left blank, depending on what that client prefers. A token reaches exactly what its account reaches and nothing more, and you revoke a single token by swiping it away. Each row shows when the token last signed in. An app that speaks the GitLab API can also create a token for itself the first time it signs in, so a token can appear carrying the name of that app rather than a name you typed. Creating a token always requires the password, so one token can never create another.

Pushing updates the files

Because a repository is a checkout, pushing to the branch it has checked out also updates the working tree, in the same way as git's own updateInstead. When you push a commit from your laptop, the new files are immediately what the Finder, the Files app and any website served from that folder see, with no deploy step in between.

The tree is only moved when this is safe. A push is refused when the checkout has tracked changes of its own, staged or unstaged, and the client is told why in the usual [remote rejected] line. Untracked files never get in the way. Pushing to any other branch is an ordinary push and leaves the working tree alone.

Large files

The server speaks Git LFS, so repositories with large binaries work without a second service to run. Pushes and clones carry LFS objects through the standard batch API, and the objects are stored beside the repository in .git/lfs/objects in the layout git-lfs uses itself. The git lfs command line and Working Copy both work against it unchanged, and switching branches in the app fetches the objects the new branch needs.

Working Copy

Working Copy, from the same developer, discovers NAS Reborn servers on your network automatically. On the same Wi-Fi the device appears under Settings → Hosting Providers in Working Copy, and adding it signs in with a device account, the same username and password as the network drive. From there Working Copy lists the repositories the account reaches, clones them, and creates new ones on the device. Away from home the https://yourserver.nas2.dk address works the same way, entered as the provider address.

Tower and other GitLab clients

The server answers a slice of the GitLab API, so desktop clients with a self-hosted GitLab option can list, create and clone repositories here. In Tower you add an account in the Services view, choose GitLab Self-Hosted, and enter the address of your server, your device account username, and an API token created on the account's screen in Settings → Authentication. The token is the part to get right: Tower and most GitLab tools send a token rather than a password when they talk to the API, so the password stays in the password prompt of plain git clients and the token goes wherever a GitLab tool asks for one. Both the https:// address and the local http:// one work, since a token is scoped and revocable and so may travel where the account password may not. Connecting self-hosted servers is part of Tower's Pro plan.

Any other git client needs none of this and works with the clone URL alone.

Push to publish

A repository containing a website, whether plain HTML or a Jekyll-style template site, is also served as one. It is published at https://yourserver.nas2.dk/name/ under the name of the repository, subject to the same public access level as any other site. A push moves the working tree in one step, so visitors always see a complete revision and never a half-updated one. You can write a post in Working Copy on the sofa, push, and the site is live on the device.

Free tier

The free tier serves up to 2 repositories. Repositories have a budget of their own, so hosting one does not spend from the folder limit even though a repository is a folder in every other sense. With more than 2 turned on, git serving pauses until a repository is set to Off or deleted, and the Pro unlock removes the limit. The repositories themselves remain plain folders in the Files app.