Or: How I learned to love my Raspberry Pi.
I’ve been around the block on backups, version control, and sharing of data for my game development projects. As a hobbyist developer, paying for storage is entirely impractical, so I’ve tried a lot of things to balance workflow with free-ness.
TL;DR I now use a Raspberry Pi as a dedicated Git server. Go to the bottom for links to learn how.
Homebrew Engine Runaround
- Nothing — On my earliest projects, like most people, I used no VCS. When I screwed up code, I had to unravel all my mistakes. Code refactors were a hellscape of fear.
- Google Drive (round 1) — When I first started developing games at home, I would periodically zip the entire project up and put it on Google Drive.
- 👍 Sufficient space for free.
- 👍 Reliable server.
- 👎 Terrible workflow.
- Perforce Repo — My codebase was getting way too big not to have proper version control. I was familiar with Perforce, and it was free to use locally on my machine, so I went with that.
- 👍 Free for individuals
- 👍 Decent for code, if a little clunky.
- 👎 Astronomical overhead for team projects.
- Google Drive (round 2) + Perforce — I later onboarded a friend to help with art. He needed to share assets with me and run the game. The Engine code lived on perforce on my machine only. New engine builds were added periodically to Google Drive. The asset folder structure was synched onto Google Drive.
- 👍 With one coder and one artist, this worked fairly well as long as we didn’t often dip into the same spaces.
- 👍 Reliable, free hosting.
- 👎 Backup, but no version control functionality, even for text-based assets, like level scripts or maps.
- BitBucket + Mercurial — A friend tipped me off to free version control hosting on BitBucket. This is where that project still lives today.
- 👍 Free private repos with multiple users!
- 👍 Plenty of space for smaller projects.
- 👍 Distributed version control means we can share the repo without relying on internet connection.
- 👎 Command-line use of mercurial prohibitively intimidating for artist.
- TortoiseHg made it usable enough, though that is also pretty clunky.
- 👎 The concept of merging is still pretty intimidating to artists. I’ve really only seen this handled well in Perforce, by avoiding it all together with file locking.
Unity Engine Runaround
I started getting serious with Unity projects around 2015, when I left my job at Activision. At the time, there was no Unity Collaborate, so I started where I had left off, but swapped out Mercurial for Git.
- Bitbucket + Git — Bitbucket had adopted Git, which I was more familiar with, so I switched to that, using a .gitignore file specific to Unity.
- 👍 Git has a more mature toolset compared to Mercurial.
- 👎 Working alone this was fine, but conflicts in assets are effectively unfixable.
- 👎 CLI version control is a bear for non-coders.
- 👎 Unity projects get big, fast, and Bitbucket has a “soft limit” of 1Gb and a “hard limit” of 2Gb. Bring in a few store assets, and you’re beyond that in a hurry.
- Unity Collaborate — In 2016, Unity announced the beta for Collaborate. A friend had been using it professionally and recommended checking it out (at least, over Git).
- 👍 It’s integrated right into the editor.
- 👍 It can do some amount of conflict resolution on assets.
- 👍 Workflow was much easier to understand for artists.
- 👍 During beta, they offered 15Gb of storage.
- 👎 In 2017, they dropped the free tier to 1Gb, which meant buying pretty much any store asset bumped you over the limit. This was the final straw for me.
- 👎 Workflow was awful for coders — I think it’s built on Git, but it locks you out of access to nearly everything useful about Git. Diffing, merging, branching, offline commits? Nah.
- Personal Raspberry Pi Server + Git — I knew nothing about hosting my own git server, but I figured someone must, so like a good programmer, I typed my problem into Google and figured it out.
- 👍 Access to central repo from anywhere.
- 👍 As many users as my little Pi can support in traffic.
- 👍 Effectively unlimited storage
- 👍 State-of-the-art version control for code with loads of 3rd party and open-source tools support.
- 👍 Distributed system for offline work.
- 👎 Still clunky for asset conflicts.
- The Unity team themselves have provided a merge tool, but I haven’t tried it yet.
- 👎 SD Card failure rate is high on Raspberry Pi, USB failure rate is lower, but still present. Reliability is eclipsed by that of cloud services.
How I set up my Raspberry Pi Git server.
I’m not going to go into detail on this part. Plenty of people have explained this better than I can. I’ll link you to the resources I used.
- Set up a Raspberry Pi git repo (Instructables).
- Note: use a USB drive, not a SD card, as they tend to burn out on high traffic in Raspberry Pis. It also allows you to pull the drive out if something goes wrong with your Pi.
- Set up an SSH key on your Raspberry Pi.
- This is technically optional, but it’d be foolish to skip. You’ll be exposing your Pi to outside threats, so every bit of security is worthwhile.
- Assign your Raspberry Pi a static IP from your router.
- This gives you direct access to your Raspberry Pi from anywhere.
- Update the ‘origin’ URL of your git repo to point at the new static IP instead of the inside-your-house IP.
- Remember setting the remote repo url in Instructables step above? Do that again, but change out the previous IP address for your new static one.
- (optional) Give your Static IP a friendly DNS name.
- If you pay for site hosting, odds are your hosting service will let you assign a subdomain to it. This can make it a little easier to work with — something like gitpi.mysite.com