Skip to main content

Working with Git (Version Control)

Git Overview

All professionally managed projects require some kind of version control system.
This type of software goes by several names:

We'll stick to the name "Version Control" to keep it simple. Professional game development typically uses either Perforce or Git. - We will be using Git, as it is free and open source. While it's less popular for game development than Perforce is, it is a tool that you can continue to use for free in your personal projects after you learn to use it during BUGJam.

There are four components to Git that you need to know about:

  • Git
  • Git LFS
  • Git GUI
  • Software Forge

Git

Git is a "decentralized" version control system. It is a command-line tool used primarily for software development. It manages source code repositories, and tracks versions of files that you check in. Git by itself is a powerful tool, but it is incomplete for our needs. Since it is decentralized, it doesn't need to connect to a central server in order to function, but without a central server you can't easily collaborate with other people.

Git LFS (Large File Storage)

By default, large art assets (binary files) aren't well supported by Git. The de facto solution to this is a plugin for Git called "Git LFS" (Large File Storage). You will not interface with LFS differently than you would with regular Git, it runs in the background and moves your large files into a large files storage container on the server. Once it's installed you can forget that it even exists.

Git GUI (Graphical User Interface)

Git is a command line tool, this means you interface with it by typing commands into the terminal, so unless you're well versed in typing all of your commands into the console, its usually not a desirable way to work. So third-party tools are available to add a graphical user interface to Git. There are dozens to choose from but we will be focusing on a free and open source tool called "SourceGit".

Git GUI tools are all just wrappers on top of git, and they just issue commands via the Git command line on your behalf, they all do the same thing, but some offer a much better experience than others. SourceGit is very new, and a little rough around the edges as it is in rapid development, but it's one of the best FOSS options.

Software Forge

Git's decentralized nature means that it doesn't have it's own system for hosting the repository. During collaboration we need a place to push our changes to so that others can pull those changes. Among very many other awesome features, this is something that "Forgejo" provides.

Git Terms

Repository / "Repo"

A repository is the what Git uses to manage projects. Every version of every file, every change, every diff, every reference log, every blob, is all stored in the repository. You can thing of it as the thing that contains the entire project. For BUGJam we will have two repos: One for art source content, and one for in-game content.

Monorepo

Some projects put all of their project content into a singular repository making one massive monorepo. This is not really appropriate for game development since it's more ideal to separate out the art source content from the in-game content. For BUGJam we will not be using a monorepo.

Branch

[INSERT DESCRIPTION HERE]

History

A full list of every change that has happened within the repository. Every file that was checked in, every modification, addition and deletion is stored in the project's history.

Local Changes

Any change you make to the files within the repository will automatically be detected by Git: Creating a file, editing a file, moving a file, deleting a file. These will all show up in your local changes. These changes will not immediately show up for other users. Local changes are volatile, they aren't checked into the version control system yet, so be careful, if you revert your local changes without committing, they are lost forever.

Commit

Every time you have a change you want to submit to the repository, you need to commit it into Git's history. This represents an actual check-in which saves your work into the repository. Without a commit, your work is in a volatile state, you must commit to make your changes permanent. Note that this still will not make these changes available for the other users yet, since the commit only happens on your local computer.

Commit Message

[INSERTSometimes DESCRIPTIONit's HERE]unclear what changes took place within a commit, all commits must have a commit message which is usually one or two lines of text describing the changes you're about to check in. Example: "fire extinguisher: Create block mesh". This will make it clear what this commit contains when we view it in the project history.

Commit Hash

[INSERT DESCRIPTION HERE]

Fetch

[INSERT DESCRIPTION HERE]

Push

[INSERT DESCRIPTION HERE]

Pull

[INSERT DESCRIPTION HERE]

Merge

[INSERT DESCRIPTION HERE]

Rebase

[INSERT DESCRIPTION HERE]

Diff (Difference)

[INSERT DESCRIPTION HERE]

Stage

[INSERT DESCRIPTION HERE]

Stash

[INSERT DESCRIPTION HERE]

Cherry Pick

[INSERT DESCRIPTION HERE]

Back to top