Getting started with Git

I’ve long worked without a code versioning system – mostly because I usually work on a project alone. For a couple of years now I’ve regularly synced most of my code to Google Drive as backup medium, but I’ve finally realized that using a versioning system might be smart after all:

• Being able to view previous versions can be very helpful in the case of problems.
• It makes it easier to sync code when working on more than one computer.
• Having a code library that is completely detached (unlike e.g. Google Drive or One Drive, which syncs constantly) protects against possible ransomware attacks.

The two most popular versioning systems in use today are Subversion (SVN) and Git. I’ve used Subversion at one of my previous employers. Subversion works with a central repository, so one would always sync before and after a coding session to make sure that you start with the latest version and that others get it as well. Git uses a decentralized approach instead – everybody has his own repository and works on his own branch. When necessary, these branches are merged again into a single master branch.

Since Git is clearly more popular these days than Subversion, I decided to use Git. Subversion is supposed to work better with large binary files, so if you want to use it also for synchronizing stuff like drawings, point clouds, etc., this might be the better choice.

There are several ways to get a access to a Git server for remote repositories. You can use a cloud service like Github, or install a Git server on a NAS or a server. I took the somewhat more laborious path of installing Gitlab on my server. Gitlab is a full-featured Devops environment, that also offers functionality like bug tracking. I made life extra difficult for myself by installing Gitlab on a server that was already running Apache, so I had to change the configuration to use Apache instead of the NGINX web server that comes with Gitlab.

Most Git documentation shows command line use of the Git tools. I understand that this is the quickest way for someone who uses Git daily, but it is a bit challenging. Visual Studio supports Git, but getting it to work with a Git server that uses SSH keys for authentication can be a bit fiddly. I use the Git GUI that comes with the Git tools for Windows.

It took me a bit to understand how to use Git with a remote repository as archive, as most examples talk mostly about branching and merging. But if you are a single developer working on a code, you can work in a more Subversion-style process.

It starts with creating an empty project on Gitlab (or whatever platform you use) and a local repository. I use one project/repository per Visual Studio solution, which to me is the logical way to do it – but as Git simply looks at all subdirectories, there’s no one keeping you from combining multiple solutions or programs. The process of adding (updated) files to the local repository is the Commit. This always requires the addition of a message of the reason behind the commit – if you’re disciplined about this, you can build a good changelog. Git does of course only commit changed files. With the Git GUI, you first have to stage the changes.

The second step is the Push, which uploads the the local repository to the Git server. Note that this is not a full synchronization – changed code on the server will not be added to the local repository. This is done by a Pull or Fetch operation. Fetch only downloads, Pull also merges. But if you only work on one computer and just want to use the remote repository as archive, this is not necessary.

It is likely that there are some files that you don’t want to add to a repository, e.g. large files used for testing. This is easily achieved by creating a file .gitignore, which affects all subdirectories as well. Just add the filenames or extensions that you want to be ignored line by line.

So, to summarize the workflow for a single development computer with a remote repository as archive:

1. Create project on the server hosting the remote repository
2. Create local repository
3. Initial commit and push
4. After each coding session, commit and push

If you use two or more development computers, you need to add the step of first cloning and then pulling changes

1. Create project on the server hosting the remote repository
2. Create local repository
3. Initial commit and push
4. On second computer, clone the repository from the remote server once
5. Before each coding session, do a pull
6. After each coding session, commit and push