Git access

Where repositories live

Git has its own hostname, separate from the API and from the app. A repository is addressed by workspace and name:

https://git.rezee.app/<workspace>/<repo>.git
ssh://git@git.rezee.app:2222/<workspace>/<repo>.git

The clone menu on any repository page has both, filled in. The API lives on api.rezee.app and the app on work.rezee.app; neither serves git.

HTTPS

The simplest path is to let the CLI answer for you. rezee auth login offers to register itself as git's credential helper, and once it has, git push works with nothing else configured:

$ rezee auth login
$ rezee repo clone acme/api
$ git push

Without the helper, git asks for a username and password. The username can be anything; the password is a personal access token.

$ git clone https://git.rezee.app/acme/api.git
Username: anything
Password: reze_pat_...

A scoped token needs code:read to fetch and code:write to push, and honours any repo: scope it carries. An unrestricted token skips that check entirely. Either way the repository's own access rules have the final say - a token cannot widen what its owner may do.

SSH

Add your public key once, from the terminal or from account settings:

$ rezee ssh-key add          # finds ~/.ssh/id_ed25519.pub
$ rezee ssh-key list

It reads only the .pub half. A file without that suffix is refused rather than uploaded, because the other half is the one that must not travel. The key can also come from a path or from stdin.

Then clone with the SSH URL. Note the port - git over SSH is on 2222, not 22, which is why the URL has to be written in ssh:// form rather than the git@host:path shorthand:

$ git clone ssh://git@git.rezee.app:2222/acme/api.git

An SSH caller carries no scopes. Public-key auth establishes who you are and nothing narrows it further, so an SSH push is governed purely by your access to the repository.

If you would rather not type the port every time, an entry in ~/.ssh/config does it once:

Host git.rezee.app
  Port 2222
  User git
  IdentityFile ~/.ssh/id_ed25519

Who may read and who may push

Access comes from three places, and the strongest wins:

A private repository answers an anonymous request with a challenge rather than a refusal, so git asks for credentials instead of failing outright. A named caller who still lacks access is told the repository was not found - its existence is not something a stranger gets to confirm.

An archived repository takes no pushes from anybody, its owner included. That is enforced here, at the door git comes through, because a read-only repository somebody can still push to is not read-only.

What a push sets off

A push is checked before it lands and acted on after. Before: branch protection - whether this ref may move, whether the update is a deletion or a force push, and whether the pattern protecting it allows either. A refused push says which rule refused it, and the gate fails closed.

After the commits land, in the same moment: a pipeline run if .rezee/actions.yml says so, a webhook delivery, a refresh of the searchable file paths, and a task for any agent watching for doc-worthy changes. A branch whose name carries an issue key - ACME-12 anywhere in it, any case - links itself to that issue.

Working from an issue

Because branch names are what link work to issues, the CLI will make one for you:

$ rezee issue develop 12     # checks out a linked branch, moves the issue on
$ rezee issue branch 12      # just prints the name

Git LFS

Not supported yet. A repository that pushes LFS pointers will store the pointers - the file browser recognises one and says so, with the real size - but there is nowhere for the objects themselves to live, so git lfs push has no endpoint to talk to. Keep large binaries out of Rezee repositories for now.