SIGGD Docs Articles
Articles I have written for SIGGD Docs, the documentation site I started and maintain for Purdue SIGGD. The current set covers getting a 50 person game project running locally and contributing to it without breaking anything.
Every year SIGGD takes in a wave of new programmers, most of whom have never worked in a shared repository before, and every year the same questions come up in the first fortnight. I started SIGGD Docs to answer them once. These three guides run in order, taking someone from nothing installed to a merged pull request, and they assume no prior Git at all.
- 01
Getting Set Up
Joining the GitHub organisation, installing Unity and GitHub Desktop, and getting the game building on your own machine. This is the one that has to work first, because nothing else matters until the project runs locally.
- 02
Git Good: First Commits
Git from zero: what the working directory, staging area and repository actually are, then cloning, committing, branching and resolving your first merge conflict. It ends on Git LFS, because a game repository fills up with textures and audio fast, and Git handles binary files badly without it.
- 03
Git Good: The PR Workflow
How a change actually lands in main: opening a pull request, what to check before you do, how review works, and why we squash merge. That last part matters more than it sounds, since squashing means your PR title becomes the commit message and your individual commit messages do not.