Version Control for Game Developers: Best Practices for Beginners

Updated on
11 min read

Introduction — Why Version Control Matters in Game Development

Version control systems (VCS) are crucial for game development as they track changes to files, allowing for easy recall of specific versions. This article provides beginner-friendly insights into version control tailored for game developers, offering guidelines on selecting the right VCS, managing large binary assets, utilizing branching workflows, and avoiding common pitfalls. Whether you are an aspiring indie developer or a part of a larger game studio, mastering these best practices will streamline your collaboration and enhance your team’s productivity.


Choosing the Right Version Control System

When it comes to version control, several popular options cater to different use cases:

  • Git + Git LFS: Commonly used for code. When paired with Git LFS (Large File Storage), it efficiently manages binary assets, making it ideal for small indie teams.
  • Perforce Helix Core: This is an industry standard for AAA studios, featuring centralized management, excellent binary performance, file locking, shelving, and fine-grained access control. You can explore more about Perforce’s solutions here.
  • Plastic SCM: Designed specifically for game development, it integrates well with Unity and supports locking and rich branching. Check out Unity’s guidance on using Plastic SCM here.

How to Choose the Right VCS

Consider the following criteria when selecting your VCS:

  • Team Size and Scale: Smaller teams (1-10 members) can often effectively use Git + LFS, while larger teams (50-100+) benefit from Perforce or Plastic.
  • Asset Types and Size: For extensive binary assets like terabytes of textures and audio, Perforce or Plastic offers superior performance.
  • Hosting Model: Choose between hosted Git solutions (like GitHub or GitLab) or self-hosted options for greater control.
  • Budget and Tooling: Git is free, while Perforce and Plastic have costs associated with larger deployments.

Rule of Thumb: Start with Git + LFS for indie or small studios. If performance becomes an issue, consider switching to Perforce or Plastic. For further information on Git LFS, visit their official website.


Repository Structure and Organization

Designing a clear repository layout is essential for effective clone times, access control, and developer workflows.

Mono-repo vs. Multiple Repositories

  • Mono-repo: A single repository has benefits like a single source of truth and easier integration but may lead to larger clone sizes.
  • Multiple Repositories: Separating code, art, assets, and builds provides smaller clones and finer access control but requires more management.

Suggested Top-Level Folder Layout for a Game Project

Example layout:

  • /Engine/ (custom engine or fork)
  • /GameCode/ (source code, scripts)
  • /Assets/ (art, models, textures)
  • /Audio/
  • /ThirdParty/ (vendor libraries)
  • /BuildTools/ (scripts)
  • /Docs/

Tip: Exclude generated build artifacts and temporary files from VCS. For large binary libraries, consider separate asset repositories or a dedicated LFS server to minimize main repo size. To enhance your server management, refer to our guide on building a home lab.


Handling Large Binary Assets — Git LFS and Alternatives

What is Git LFS?

Git LFS replaces large files in your Git repository with small pointer files, storing the actual content in a separate server to maintain a lightweight Git history.

Basic Git LFS Workflow

# Install Git LFS
git lfs install

# Tell LFS to track file types
git lfs track "*.psd" "*.fbx" "*.wav"

# Commit tracking rules
git add .gitattributes
git add <large_files>
git commit -m "Add tracked binary assets"

Limitations and Costs

Managed providers like GitHub and GitLab impose bandwidth and storage limits for LFS, which could lead to expenses for large asset libraries. Regularly monitor usage and plan for long-term storage.

Alternatives

  • Perforce and Plastic: These offer built-in solutions for managing large binary assets and provide robust locking mechanisms advantageous for larger teams.
  • Hybrid Approaches: Use Git for code and either Perforce or Plastic for art assets, though this adds complexity to your builds and continuous integration (CI).

Practical Tips

  • Only track essential large files with LFS.
  • Optimize assets (compress textures and remove unused data) before committing.
  • Deduplicate assets whenever possible.

Branching Strategies and Workflows

Common Branching Models Suitable for Game Teams

  • Simple Feature Branching: Merges short-lived feature branches into a main or trunk branch frequently. Ideal for small teams and beginners.
  • Gitflow: Involves multiple branches (develop, feature/, release/, hotfix/*). Suitable for teams with formal release cycles but can be cumbersome with asset-heavy projects.
  • Trunk-based Development: Focuses on small, frequent commits to a single main branch, preventing long-lived merges and aiding continuous integration.

Branching Comparison Table

ModelProsConsBest For
Feature BranchesEasy to understand; good for small teamsCan become messyIndie teams, beginners
GitflowStructured release processComplexity with many branchesFormal release cycles
Trunk-basedFewer merge conflicts; effective for CIRequires disciplineTeams with continuous builds

Game-Specific Considerations:

  • Avoid long-lived branches to minimize merging issues, particularly for binary assets.
  • Create release branches for milestone builds and utilize hotfix branches for urgent needs.
  • Encourage artists and designers to use short-lived branches while locking assets to prevent conflicts.

File Locking, Merge Strategies, and Binary Assets

Why Merges Fail for Binary Assets

Merging binary files poses challenges, as traditional diffs and merges are ineffective. When two users edit the same binary file, a decision must be made on which version to keep.

Locking Solutions

  • Perforce and Plastic: Provide native file locking for exclusive edit access.
  • Git LFS: Has locking commands (git lfs lock), although performance is not as robust as Perforce or Plastic.

Example Git LFS lock command:

# Lock a file before editing
git lfs lock Assets/Characters/Hero.fbx

# Unlock when done
git lfs unlock Assets/Characters/Hero.fbx

Best Practices for Collaborative Editing

  • Modularize Scenes: Break large scenes into smaller sub-scenes or prefabs to decrease lock contention.
  • Prefab Workflows: Adopt workflows that allow parallel work for artists, particularly in Unity.
  • Consider Unity’s YAML Serialization: Leverage text serialization for easily mergeable assets, but be aware that not all assets serialize cleanly. For more on version control with Unity, check the documentation here.

Repository Hygiene — .gitignore, .gitattributes, and Policies

Maintain clean repositories by utilizing properignore rules and attributes:

Sample .gitignore Snippets (Unity + General)

# Unity
[Ll]ibrary/
[Tt]emp/
[Bb]uild/
Obj/
*.apk
*.aab
*.log
# Visual Studio
.vs/
*.user
*.suo

# Generated Files
*.exe
*.dll

Sample .gitattributes for LFS and Merges

# Track large binary types with LFS
*.psd filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text

# Treat Unity scenes as text if using YAML serialization
*.unity text
*.prefab text

Repository Policies and Enforcement

  • Pre-commit Hooks: Use hooks to prevent accidental commits of large files or ensure LFS tracking is in place.
  • Continuous Integration (CI): Validate changes through automated checks and asset validation.
  • Documentation: Keep a CONTRIBUTING.md file to onboard new artists and programmers effectively.

Example Pre-commit Hook:

#!/bin/sh
# Check for files larger than 50MB
MAX=52428800
for file in $(git diff --cached --name-only); do
  if [ -f "$file" ]; then
    size=$(stat -c%s "$file")
    if [ $size -gt $MAX ]; then
      echo "Error: $file is larger than 50MB. Use LFS or remove it."
      exit 1
    fi
  fi
done
exit 0

Commit Messages, Reviews, and Collaboration Etiquette

Effective commit messages and review practices save time by minimizing context-switching interruptions.

Commit Message Format

Short summary (50 characters or less)

More detailed description (wrap at ~72 characters).
Refs: ISSUE-123

Review Workflows

  • Encourage programmers to review code changes while artists review art assets.
  • Utilize pull/merge request templates to ensure all relevant information is included, including testing steps and issue references.
  • For art reviews, request thumbnails or notes reflecting changes in LODs, texture compression, or target platforms.

Communication Practices

  • Always refer to tickets or issue IDs in commit messages.
  • Preemptively announce any planned locks or significant asset edits to maintain team awareness and reduce workflow interruptions.

Automated Builds, CI/CD, and Release Management

Automating builds and checks catches integration issues early and saves time.

What to Automate

  • Build distributions for various platforms (PC, console, mobile) on main or release branches.
  • Validate assets, checking for missing references or compilation issues.
  • Implement smoke tests to ensure builds are stable.

CI Considerations for Asset-Heavy Projects

  • Use incremental build caching to speed up build processes.
  • Run significant platform builds on dedicated runners (cloud or self-hosted). Consider Docker containers for these processes; refer to our Docker containers guide for advice.
  • Store build artifacts in an artifact repository or cloud storage to maintain organization within your VCS.

Example CI Triggers (Pseudo YAML):

on:
  push:
    branches: [main, release/*]
jobs:
  build:
    runs-on: self-hosted
    steps:
      - checkout
      - setup-unity
      - build-for-windows
      - upload-artifacts

Keep in mind that engine-specific build issues may require special handling for assets and shaders. For best practices on managing shaders, visit our game shaders guide.


Backups, Access Control, and Security

Backups

  • For on-prem servers, conduct periodic snapshots and off-site backups, testing restores periodically.
  • Verify backup and replication strategies with your cloud provider.
  • If using custom storage solutions like Ceph, assess the replication and recovery processes outlined here.

Access Control

  • Limit push/merge rights on main branches.
  • Implement role-based access, providing appropriate permissions, such as locking/unlocking capabilities.

Secrets and Credentials

  • Avoid storing API keys or passwords directly in repositories. Utilize CI environment secrets instead.
  • Regularly rotate credentials and audit access logs for security compliance.

Common Pitfalls and Troubleshooting

Slow Clones and Large Repositories

  • Utilize shallow clones (git clone --depth) and sparse checkouts to optimize download times.
  • Consider separate asset repositories or proxies for Perforce/Plastic to enhance workflow efficiency.

Merge Conflicts in Scenes or Prefabs

  • Use strategies like reverting or re-evaluating with the asset owner to reconcile changes effectively.
  • Promote small, focused edits and encourage frequent merges to minimize conflicts.

Running Out of LFS Quota

  • Monitor your LFS usage regularly and consider cleaning up unused large files (git lfs prune).
  • Evaluate self-hosting LFS or migrating heavy assets to Perforce or Plastic for better management.

Corrupted History or Accidental Deletion

  • Protect main branches and avoid force pushes without prior review.
  • Maintain frequent backups and regularly practice restore procedures.

Practical Checklist and Onboarding Steps

Quick Onboarding Checklist for New Team Members

  1. Install your VCS client (Git or Perforce) and Git LFS if applicable.
  2. Clone the relevant repository and set up large file tracking (git lfs install).
  3. Configure your editor/engine integration (Unity, Unreal). Windows users might find installing WSL beneficial.
  4. Review CONTRIBUTING.md and the coding/asset guidelines.
  5. Run a local build and follow the CI build steps.

Day-to-Day Best Practices

  • Pull the latest changes before starting.
  • Commit small, focused changes.
  • Push often and communicate about locks effectively.
  • Create short-lived feature branches and merge regularly.

Sample CONTRIBUTING.md Checklist

# Onboarding Checklist

- [ ] Install Git, Git LFS
- [ ] Clone repo and run initial build
- [ ] Configure Editor integration
- [ ] Read coding and asset guidelines

# Daily Workflow
- Pull the latest from main
- Create a short-lived branch for features
- Commit frequently with clear messages
- Use locks for binary assets when needed

Conclusion and Further Reading

Key Takeaways

  • Match the VCS to your team size and asset needs: Git + LFS for smaller teams; Perforce or Plastic for larger asset-heavy studios.
  • Treat assets differently than code: implement locking, modular scenes, and utilize LFS or enterprise solutions when required.
  • Automate builds and maintain repository hygiene through .gitattributes, pre-commit hooks, and continuous integration.

Next Steps to Deepen Mastery

  • Experiment with a small test project to practice Git LFS locks and branching workflows.
  • Consider setting up a home lab if self-hosting; explore our hardware guide as a starting point.
  • For insights on CI runners and service containers, consult our Docker containers.

References and Authoritative Resources

Checklist for Implementation

Copy the sample CONTRIBUTING.md checklist above into your repository or use it for onboarding new team members. Start by applying these practices to a small prototype project and gradually refine your workflow as your team expands.

TBO Editorial

About the Author

TBO Editorial writes about the latest updates about products and services related to Technology, Business, Finance & Lifestyle. Do get in touch if you want to share any useful article with our community.