Gitea & Git LFS
Our version control. A self-hosted Gitea server, with Git LFS for binary assets and file
locking so two people cannot edit one .blend at once.
This replaced Unity Version Control and Gluon. Those are no longer used.
What you need
Our own Git client, downloaded through the Bubbly Games Launcher. That is why the launcher
comes first in the install order.
You do not need to install Git or Git LFS separately, and you do not need a terminal. The client is
ours, so if something about version control is awkward in daily use, that is a fixable bug rather
than something to work around.
It is the tool everyone here touches every day and the one with the least written about it. What
this page needs:
- Its name, and where the launcher puts it
- The server address, and who creates Gitea accounts
- First-run setup: signing in, credentials or keys, anything per-machine
- Cloning a project, and roughly how long the first clone takes on our largest one
- Where lock, unlock and "who holds this" are in the UI. That is the daily operation, and the
whole reason we have our own client rather than handing artists a generic one - What it does about LFS, and whether any of it needs thinking about
Do this one with someone the first time rather than from a page. Cloning a large LFS repository has
a couple of first-run steps that are much easier shown than written, so nobody
has written them down yet.
The daily loop
- Pull before you start
- Lock what you are about to edit
- Work
- Run the checker (Check Your Work)
- Commit and push,
.metafiles alongside their assets, using the
commit format - Release your locks
Everything else
How we use it is on Version Control: locking, branching, the commit format, what is and is not in the repository, and
what to do about a stale lock.
Is LFS locking enabled on our repositories? It depends on server configuration and on each
repository carrying the right .gitattributes. Everything we document about locking assumes yes.
→ Version Control > Setup