blog/posts/forking-gitea.md

title, slug, date, description, og_description, og_image, excerpt, author, author_initials, author_role

title	slug	date	description	og_description	og_image	excerpt	author	author_initials	author_role
Why We Forked Gitea and Built Our Own Git Platform	forking-gitea	2026-05-20	Game studios need git hosting that understands large files, 3D assets, and team workflows. We forked Gitea and built tinqs-git --- here's why and how.	Game studios need git that understands LFS, 3D previews, and team workflows. We built tinqs-git.	https://www.tinqs.com/img/og-cover.jpg	GitHub doesn't understand game dev. We forked Gitea to build tinqs-git --- with 3D asset preview, LFS-first workflows, and project management for game teams.	Ozan Bozkurt	OB	CTO & Developer, Tinqs

GitHub is built for web developers. Game studios need something different --- LFS that works, 3D asset previews in the browser, and project management that understands sprints and milestones. So we forked Gitea and built tinqs-git.

The Problem with GitHub for Game Dev

We used GitHub for two years. It was fine for the docs repo --- small files, text diffs, pull requests. But the game repo was a different story.

A single character model with textures and animations is 50--200MB. A terrain heightmap is 16MB. An island's vegetation data is another 10MB. Our game repo was 12GB in LFS alone, growing every week. GitHub's LFS bandwidth limits, slow clone times, and $5/50GB pricing made it untenable.

More importantly, nobody on the team could see what changed. A PR that modifies a GLB file shows a binary diff. You can't preview it. You can't compare before and after. The artist pushes a model, the developer approves it blindly, and three days later someone notices the normals are inverted.

Why Self-Host, and Why Gitea

We evaluated GitLab, Forgejo, Gogs, and Gitea. The decision came down to:

• Single binary. Gitea compiles to one Go binary with SQLite support. No PostgreSQL, no Redis, no Docker compose with 7 services. Just copy the binary, write an app.ini, and run it.
• Resource usage. Our Gitea instance runs on a single EC2 instance alongside four other services. It uses about 200MB RAM. GitLab needs 4GB minimum.
• LFS built-in. Gitea includes a full LFS server. No external LFS store, no S3 configuration for basic use. Files are stored locally. We added S3 backend later when we wanted it, but it works out of the box.
• Forkable. Gitea is MIT-licensed, written in Go, with a clean codebase. We can modify it without worrying about license restrictions or CLA headaches.

We ran vanilla Gitea for six months. It solved the cost and bandwidth problems immediately. But the UX gaps for game development were still there.

What We're Adding: tinqs-git

tinqs-git is our fork. It tracks upstream Gitea (currently v1.26.1) on the main branch and keeps all Tinqs customisations on tinqs/main. We rebase onto upstream releases periodically, fix conflicts, and push.

3D Asset Preview

The headline feature. When you open a PR that contains a .glb, .gltf, or .fbx file, you see a 3D viewer directly in the browser. Rotate, zoom, check materials. No downloads, no external tools. We integrated Online 3D Viewer (O3DV), which supports 22 file formats including STL, OBJ, 3DS, and PLY.

This changes the review process fundamentally. The artist pushes a model, the lead rotates it in the browser, leaves a comment about the UV seam on the shoulder, and the artist fixes it --- all without leaving the git platform.

LFS-First Workflows

Vanilla Gitea treats LFS as an afterthought. You configure .gitattributes manually. There's no dashboard showing LFS usage, no way to see which files are tracked, no warnings when someone commits a large file without LFS.

tinqs-git adds auto-LFS tracking on repository creation. Game file extensions (.fbx, .glb, .png, .wav, .ogg, .tscn, .tres) are tracked by default. An API endpoint exposes LFS storage stats per repo. The goal: LFS should be invisible. It should just work.

Tinqs Branding and Landing Page

Every string that says "Gitea" is replaced with "tinqs-git". Custom amber/gray/black theme using CSS variables (no Fomantic-UI fork needed). Custom logo, favicon, and a landing page that explains what this is and who it's for.

Platform Integration

tinqs-git will integrate with our Team Tool for project management --- issues, sprints, time tracking --- and with the Tinqs platform via OAuth2 SSO. One login for git, the game, and the tools.

The Branching Strategy

Staying close to upstream is critical. We don't want to maintain a full fork that diverges forever. The strategy:

• main tracks upstream go-gitea/gitea. We never commit to it directly.
• tinqs/main is our production branch. All customisations live here.
• Feature branches (tinqs/phase-1, tinqs/phase-2, etc.) merge into tinqs/main.
• When upstream releases a new version, we merge main into tinqs/main, resolve conflicts, test, deploy.

We deliberately limit what we touch. We modify templates, locale strings, CSS variables, and a handful of Go packages. We never touch the database models --- schema is owned by upstream, and we ride their migrations. This keeps rebasing manageable.

What We Learned

Self-hosting git is surprisingly easy. The hard part isn't running Gitea --- it's convincing yourself that you're allowed to. After years of GitHub being the default, it feels transgressive to host your own git. But a single Go binary on a $10/month server handles a team of 8 with room to spare.

LFS changes everything for game repos. Our clone times went from 45 minutes to 3 minutes. Developers only download the LFS objects they need. CI only pulls what changed. The bandwidth savings alone paid for the server.

Forking is maintenance, not rebellion. The romantic version is "we forked Gitea and built our own platform." The reality is we changed 200 lines of Go, 50 template strings, and a CSS file. 99.5% of the code is upstream's. We're just customising the last half-percent for our use case.

3D preview is a game changer. We expected it to be a nice-to-have. It turned out to be the feature that made the rest of the team actually use git. When the artist can see their work rendered in the browser, they stop asking the developer to "check if it looks right."

---

tinqs-git is built for game teams that are tired of paying GitHub for LFS bandwidth and reviewing binary diffs blind. We're building it for ourselves first, but the plan is to make it available as a standalone product. If you're a game studio that self-hosts, we'd love to hear what features you need.