FAQ
Opinionated product, opinionated answers.
Workflow
Why no pull requests?
Pull requests solve two problems: code review and gating. gittan replaces the gating part with a pre-receive hook that runs your pipeline before accepting the push. If the pipeline fails, the push is rejected. Code review happens through pair programming, mob programming, or async review of commits on main. PRs add ceremony that slows teams down without making code better.
Why trunk-based development?
Long-lived branches create integration debt. The longer a branch lives, the harder the merge. Trunk-based development forces small, frequent integrations. Every push is tested against main. Merge conflicts are rare because changes are small. If your change is too big for a single push, use feature flags.
Why terminal feedback?
You just ran git push. You are already in the terminal. Opening a browser to watch CI is a context switch. gittan streams pipeline output directly to your terminal during push. You see results where you already are. No tabs, no notifications, no polling a web UI.
Architecture
Why micro repos instead of monorepos?
Monorepos need specialized tooling (Bazel, Nx, Turborepo) to avoid rebuilding everything on every change. Micro repos are just git repos. The dependency graph shows which repos depend on which, so you see the blast radius of a change before you push. You get the visibility of a monorepo with the simplicity and ownership clarity of separate repos.
Why no Actions marketplace?
GitHub Actions marketplace is a supply chain nightmare. You pull in third-party code that runs with full access to your secrets and source code. One compromised action poisons thousands of repos. gittan pipelines use container images you control. Pin a specific image tag, scan it, sign it. Your org policy can enforce image sources.
Why no issues, wiki, or project boards?
We do three things: git hosting, pipelines, and team management. Issues belong in a dedicated tracker. Wikis belong in a documentation tool. Project boards belong in a project management tool. Bundling everything into a git host creates a mediocre version of each. Use the best tool for each job.
Pricing and plans
Why no per-seat pricing?
Per-seat pricing punishes collaboration. Need a contractor for two weeks? That costs you a seat. Want a junior to shadow a senior? That costs you a seat. gittan charges per team, not per person. Add as many people as you need on the Team plan.
Why is OIDC/SSO included on every plan?
Because SSO is a security feature, not a premium add-on. Every other git host charges extra for SSO, which means small teams are forced to use passwords. That is backwards. Every gittan plan includes OIDC. Connect your identity provider on day one.
Can I self-host gittan?
No. gittan is SaaS only. Self-hosting creates a support surface we cannot control and splits focus between product and infrastructure. If you need on-prem git hosting, Forgejo and Gitea are excellent options. We run Forgejo under the hood.
Metrics and philosophy
Why no stars or popularity metrics?
Stars measure marketing, not engineering. A repo with 50,000 stars and 200-second CI is worse than one with zero stars and 8-second CI. gittan tracks team metrics inspired by DORA: push frequency, pipeline lead time, rejection rate, and recovery time. These measure engineering effectiveness, not popularity.
Will you add feature X?
Probably not. gittan is intentionally limited. Every feature we add is a feature we have to maintain, document, and support. We would rather do three things well than ten things poorly. If the feature you want is covered by a dedicated tool, use that tool instead.
Why are you building this?
Everything available is either too complex (GitLab), too expensive (GitHub Enterprise), too limited (bare Gitea), or too opinionated about workflow (Gerrit). We wanted trunk-based development with gated push, fast pipelines, team-centric permissions, and nothing else. It did not exist, so we built it.