Version control for a student game project

A student game dies in a folder named final_FINAL_thisone, emailed at midnight, missing the one script that made the jump work. Version control is the unromantic habit that prevents that death. It keeps a history of the project, lets two people change it without overwriting each other, and gives you a way back when a bold idea was not bold so much as broken. You do not need to become a scholar of the tool. You need a few habits before the jam starts, not during the panic.

What you are saving

A commit is a snapshot with a sentence attached. The sentence should say what changed: add door lock, fix double jump, break boss on purpose while testing. A snapshot named update is a snapshot you cannot find. Commit when the game still runs, not only when the week ends. A history of working snapshots is a ladder. A single zip from three weeks ago is a cliff. Scenes, prefabs, and messy project folders stays manageable if the tidy moments are saved. Otherwise you tidy once and lose the tidy to the next overwrite.

What does not belong in the history

Builds, huge intermediate files, and personal editor settings will swell the repository until nobody can download it. Learn the ignore file for your engine and use it before the first large import. Art source you can still edit usually belongs in the project. A 4K video of the trailer does not. An asset pipeline from file to playable fails when the source file never made it into the shared copy. Agree on what is source. Commit that. Leave the generated junk out.

Branches without a religion

A branch is a side copy of the work so an experiment does not wreck the main line. Use one when the idea might not survive the afternoon. Merge it back when the game runs, or delete it when the idea failed. A student team does not need a branching philosophy. It needs main to stay playable. If two people must touch the same scene, talk before you both save. Version control merges text better than it merges a binary scene both of you rearranged. The tool is not a substitute for a sentence in chat.

The hour before you work

Get the latest changes before you start. Commit or stash what you have before you pull a teammate's week into a dirty folder. Those two habits prevent the sad merge. Push before you sleep if the work is something the team needs. A commit that lives only on a laptop in a backpack is a rumor. Free Game Engines for Beginners: How to Choose is a fine debate. It will not restore a file you never shared. The repository is the project's memory, and memory that stays on one desk is a diary.

When something breaks

Look at the recent snapshots before you rewrite the system. The bug often arrived with a specific change, and that change can be reversed. If you cannot run the game, return to the last snapshot that ran, then reapply the idea more slowly. Heroic all-nighters that edit the only copy are how prototypes vanish. A calm revert is a skill. It feels like losing and it is the opposite. You are buying the chance to try again without the wreckage.

Frequently asked questions

Is a shared drive enough? It is better than nothing and worse than history. A shared drive overwrites. It does not remember Tuesday. Use real version control if the course possibly allows it.

How often should we commit? When a small change works. Several times in a work session is normal. Once at the end of the month is how you lose the month.

What if two people edited the same level? Expect a painful merge. Decide who owns the level today, or split the work into separate scenes. Process beats a clever merge tool when the file is a binary blob.