Git should not require GitHub.
That sounds obvious until a team tries to leave. The code is in Git, but the working shape of the team is somewhere else: remotes, permissions, pull requests, reviews, project visibility, and the small rituals that make work legible. Over time, "we use Git" quietly becomes "we live inside a large developer platform."
For many teams, that is too much gravity.
The problem
Git is already decentralized. The workflows around it usually are not.
If a small company, agency, research group, or agent-heavy team wants to host its own Git workflow, the common choices are awkward. Run a full forge with more surface area than you need. Keep using GitHub because the collaboration layer is familiar. Or stitch together remotes, chat, review notes, and deployment scripts by hand.
None of those are wrong. They are just heavy for teams that want the basics:
- A place to push and pull code.
- Clear permissions around who can see and change it.
- Pull requests and review without ceremony.
- A visible workspace for humans and agents working together.
That is the space Gitty is meant to explore.
What Gitty is
Gitty is an open-source project for simple, self-hostable Git collaboration.
The aim is not to clone GitHub. The aim is to make the everyday team loop feel understandable again: create a repo, invite the right people or agents, review a change, merge it, and keep moving.
The project is public and accessible at github.com/Hassion-Studio/gitty.
Right now, Gitty is early. It is a scaffold and a direction, not a production forge. We are using the project to work through the right primitives: repository hosting, access control, review flow, workspace visibility, and the small bits of product language that make self-hosted software feel safe instead of lonely.
Why this matters to us
Hassion Studio runs on Git, but more and more of our work is done with agents. That changes what a code workspace needs to show.
It is not enough to know that a branch exists. We want to know who or what opened it, what brief it is carrying, what checks passed, what decisions were made, and where a human needs to step in. That should be visible beside the code, not buried across five services.
At the same time, we do not want every project to inherit a giant platform just to review a patch.
Small teams deserve boring ownership. Put the Git server where you want it. Keep the collaboration layer small enough to understand. Bring humans and agents into the same room without signing the whole room over to someone else.
Where it is going
The first useful version of Gitty should be modest:
- Self-hosted remotes. Repositories that can live on infrastructure a team controls.
- Simple permissions. Enough access control for real teams without enterprise theater.
- Pull requests and review. The familiar loop, stripped down to the parts that help work move.
- Agent-aware workspaces. A visible place for briefs, runs, branches, checkpoints, and handoffs.
There is plenty we are not trying to solve yet. Gitty is not production GitHub parity. It is not a marketplace, an issue tracker, an enterprise compliance suite, or a social network for code.
It is a small bet that Git collaboration can be self-hosted, legible, and calm.
The invitation
If you have ever wanted the GitHub workflow without the GitHub dependency, Gitty is for you to watch, fork, argue with, and shape.
We are building it in the open because the point is ownership. The work should be inspectable. The tradeoffs should be visible. The result should be something a team can run for itself.
The public repo is here: github.com/Hassion-Studio/gitty.