⎇
Ordinary git
Clone, branch, push, pull request. Your editor, your terminal and your existing scripts all work, because it speaks the protocol rather than imitating it.
Source control and deployment are usually two products, two bills and a pipeline somebody maintains between them. Here they are the same thing: a push is a deployment, because the place your code lives is the place it runs from.
Standard git. Any client, any tooling you already use.
What teams keep here
Every team that ships has written the glue between their repository and their hosting at least once, and maintains it forever. This removes the seam rather than automating it.
Clone, branch, push, pull request. Your editor, your terminal and your existing scripts all work, because it speaks the protocol rather than imitating it.
Choose the branch that goes live and it does, on every push. There is nothing between the two to configure, break or debug at midnight.
Access is through tokens you issue and revoke, each one scoped and individually traceable. Only the hash is stored.
A new repository is private. Making something public is a deliberate act, not the thing that happens when you forget.
The history, the branches and the running deployment in one place, so the question 'what is actually live right now' has one answer instead of three systems to reconcile.
The glue is where the outages come from. Not the repository, not the host — the thing somebody wrote in a hurry to connect them, which nobody has looked at since.
Clone, fetch, push and pull work from any client, because this implements the protocol rather than wrapping a different one. Your existing scripts, hooks and editor integrations do not need to know where the repository lives.
Issue one per machine or per purpose, and revoke it without touching the others.
If the copy cannot complete, both repositories are left exactly as they were.
Pack resolution happens server side, including for pushes that depend on objects only we hold.
A push that would take you past what is included is refused through git itself, with the reason in your terminal — not after the storage has already been written.
We deleted the deployment pipeline. Four hundred lines of it, and the two people who understood it got their Fridays back.
It is git. Any client that speaks the protocol can clone, fetch and push, and your existing tooling works unchanged. Nothing proprietary has to be installed.
You nominate the branch that goes live. Every push to it triggers a build and publishes the result. There is nothing between the repository and the running site for you to configure.
Through tokens you issue, each scoped and individually revocable, with only a hash stored. Revoking one takes effect immediately and does not disturb the others.
Yes. Push an existing repository here as you would to any remote, with its full history intact.
Ten repositories and 100 GB of storage. Usage is summed from what your pushes actually stored, and the limit applies at the moment of the push rather than afterwards.
Nothing. A fork copies the objects and refs, so the two are independent from that point. Rewriting history in one cannot affect the other.
Push a repository, pick the branch that goes live, and stop maintaining the part in between.
Ten repositories and 100 GB included.