Skip to content

Version Control Systems and Git#

As programmers, we often face the same questions over and over again. "Is this fix already in the release?", "What is the latest version of this file?", "Who has been working on that?". You also often need to compare the current state of your project to some earlier version. Version Control Systems solve these kinds of problems, and that is why pretty much all professional development is stored in such systems.

Git is a version control system that has been gaining popularity in the early 2000s, and today it is one of the most widely used tools for the job.

Bird's Eye View on Git#

Whenever you make changes to your code, you can commit these changes to git, and it will remember this as a distinct version. With this commit, you will also be storing a human-readable summary what it was that you were working on - this is called a "commit message". You can retrieve any older version of your code, and you can make comparisons against these older versions. Git can also tell you who wrote which lines of a piece of code, making it much easier to ask the right person if something goes wrong.

Git will also facilitate other ways of teamwork, but this is not part of this course, yet.

The collection of all your files and all their histories is called a repository.

Git Clients#

You can use Git with a lot of different software and you can mix and match them to your needs. Personally, I use a combination of git command line, Github Desktop and the git integration in my Code-Editor on the very same project. Each of these has their own up- and downsides so I just use all of them.

Github Desktop - Great to get started#

Screenshot of Github Desktop

Github Desktop is a relatively simple git GUI. It hides some of the complexity of git from you, which is why it is a great place to start.

Git Command Line - The Original#

Git output on the command line

Git itself is actually a command line tool. This makes it nearly impenetrable for new users, but it is the version that gives you the most options and can deal with the most obscure of questions you might throw at it. This is also in many cases what your graphical software will use under the hood.

Git in your IDE#

Git integration as seen in Atom Editor

Many code editors or IDEs have Git support built in. Processing, which we are using for this course, does not have this feature1. If the editor you use supports some of git's features, it is usually a good idea to enable this. Most commonly, it will highlight changes since the last commit (seen in the screenshot above in orange and green).

More Tools#

Two excellent Git Clients for advanced users are Git Tower (starting at 59€ per year) and Atlassian Sourcetree (requires registration, but does not cost money).

Single-Person Workflow#

  • Change your code: Of course you still need to make the changes that you would normally need to do.
  • Add: After you made changes to your program that you are happy with, you would add these changes for the next commit. In this step, you get to choose what exactly belongs to your commit and what doesn't. It is a good idea to add only changes that "belong together" into the same commit.
  • Commit: After adding, you actually perform the commit itself. This will create a history entry with a timestamp, a version number like a21bace and will also ask you for a commit message (we're going into more detail about the commit message below).

Working with a Server#

Git works perfectly fine on its own. But in most cases you will have a repository that is somehow connected to it. Most commonly today, you will have some kind of Code Forge (Gitlab, Github, Gitea ...) where you have more options to collaborate with other team members.

Clone#

To get an existing repository onto your hard drive, you git clone it onto your machine. After cloning you have a full copy of everything, including all historic versions, on your machine. The command requires some kind of address where the repository comes from and (optionally) one destination where you would like the cloned repository stored on your computer.

The repository address can look somewhat like these:

  • git@code.fbi.h-da.de:some-path/project-name.git

Fetch, Pull and Push#

To share your work with your team members, you need to get their work from a server or need to upload your work to that server. This is done with the commands git fetch, git pull (actually a combination of fetch and merge) and git push. Fetch and pull drag stuff from the server onto your machine. Push takes your version and sends it out to the server.

Only Commits

You can only fetch/pull/push commits. That means, everything you want to share via git must be in some form part of the git history.

Other Important Git Commands#

Log#

The git log is the list of commits. This shows you all past versions that you stored in Git. Graphical tools will usually always have this list somewhere.

Status#

With git status you can see if everything in your repository has been checked in or which files have changed since the last commit. Graphical tools commonly display this automatically.

Importance of the Commit Message#

XKCD Comic Nr 1296. A fictional list of 10 git commits over the past 14 hours. Each is shown with a dot for the commit, a message and the relative timestamp. As time progresses, commit messages go from sensible to batshit crazy.

XKCD #1296, by Randall Munroe, Used under CC-BY-NC 2.5

A commit message gives you a hint of what has changed. This seems tedious at first, but in long-running projects or on teams with many members, these messages can be very helpful. If you have a hard time coming up with a good summary for a commit message, maybe you were trying to put too many distinct changes into one commit.

Which files to store#

When in doubt, store all files in git. But if you know that some files can be created from source files that are already in git anyway, you probably should exclude them. This is commonly the case in programming languages that compile to a binary, like in your Unity3d environment. Those binary should be excluded.

Further Resources#

  • Github has a nice Git-Cheatsheet for the most important commands. There is also a very similar german version of the cheatsheet available.
  • Oh Shit, Git?! lists common problems you may encounter and it explains how to solve them.
  • Git's Documentation is an in-depth resource if you need every last detail about every command. This is great if you already know git and need to look up some specific detail. It is not a great resource for first-timers.

  1. There is an extension, but it is outdated and has not been updates since 2017. I would not recommend using it.