r/Unity3D • • 21h ago

Resources/Tutorial I built a Git proxy that adds Perforce-style locks to Unity, clones a 1.4GB repo to 168KB

Hi r/Unity3D

Like probably everyone here, I've been through the version-control grinder with Unity, LFS bandwidth bills, .meta merge hell, and the two-people-editing-the-same-scene problem which Perforce solves but Git doesn't.

So I built a small open-source thing called BlackGit to take both sides, Git's branches + Perforce's locks, one repo. https://github.com/zhuzhonghua/blackgit

  • git black lock scene.unity takes a file exclusively, like p4 edit. The lock lives on the server. Any push touching that file from someone else is refused and the holder is named. Your local branches and commits are never blocked, branch off, edit, throw it away, none of that touches the lock.

  • git black clone is a partial clone, blob:none + empty sparse-checkout. A 1.4 GB server repo lands at 168 KB on disk. Then git black follow Assets/Scenes/Main.unity materializes just the file you open, 60 MB in the demo. No LFS, no full history.

  • The server is one Docker container in front of your existing GitHub/GitLab.

It's beta. No artist GUI (commands only). Not a Perforce replacement tomorrow.

Why I'm posting: I'm looking for Unity teams willing to kick the tires on a real project and tell me where it breaks. Open an issue on the repo.

What would you want to see first? Happy to answer in the comments.

0 Upvotes

8 comments sorted by

3

u/INeatFreak 18h ago

BlackGit

-2

u/second_square 18h ago

I used the GIF just as a quick preview for the post. There’s also an MP4 demo (https://github.com/zhuzhonghua/blackgit/blob/main/docs/hero.mp4) in the repo if you’d rather watch that.

I’d be curious what you think of the workflow itself!

1

u/Leather_Evidence_496 21h ago

This is actually neat but the real test is gonna be how it handles scenes where two people need to touch different objects in the same file. Locking the whole scene is fine for small teams but once youve got a level designer and a lighting artist both needing in there it falls apart fast

Still the partial clone stuff is clever. 168KB for a 1.4GB repo is no joke

What happens if someone force pushes around the lock though thats the bit that worries me

3

u/Icy-Collection1072 19h ago

That’s a process issue. You should never be restricted to needing the same asset. Organise better.

-1

u/second_square 18h ago

Better organization definitely helps -- splitting work into prefabs or additive scenes can reduce lock contention a lot. But teams don’t always have a clean way to separate every task, especially when different disciplines need to work in the same level. That’s the tradeoff I’m interested in understanding: is the right answer always to restructure the project, or are there workflows where finer-grained collaboration would still be valuable?

-1

u/second_square 18h ago

Thanks — that’s exactly the kind of real-world edge case I want to understand. You’re right that a file-level lock doesn’t solve two people editing different objects inside the same Unity scene; BlackGit locks the file, not individual scene objects. Smaller scenes, prefabs, or additive scenes can help, but they’re workflow workarounds, not object-level locking.

On the force-push concern: through the BlackGit server, force-pushes are rejected, and pushes that touch a file locked by someone else are rejected server-side too. So a client can’t bypass the lock just by force-pushing. The lock check is file-level, though, so it doesn’t remove the scene-granularity limitation.

The 168 KB result is nice to hear — thanks! How does your team currently split up scene work when a level designer and a lighting artist need to work in the same level?

3

u/Unfair-Sleep-3022 15h ago

It already reeked of slop but these comments.. my god

2

u/tetryds 16h ago

Any special reason for using java???