Understanding git

Only a few people in the world get to create one famous piece of software. A guy called Linus Torvalds created two that are used every day by millions of people: Linux, and git.

What is git?

Git is a version control system. Version control is an important element in software development, as it is the only way to have multiple people work on the same piece of software in a reliable and efficient manner. Older systems were CVS and SVN, but Linus Torvalds wasn’t happy with them for the development of the Linux kernel, and his previously-used system became unavailable. Today, git is the most-used version control system by a wide margin.

Why should I use git as a lone developer?

Even if you develop alone and never have to synchronize your work with someone else, there are at least two reasons to use git. First, it allows you to go back to previous versions of the code if something that worked in the past doesn’t work anymore. Second, it makes it easy to work on the same project on multiple computers.

What do I need?

You need the git command line tools, which can be found on the git website. These are available for Windows, Linux, and Mac OS – the BSD guys will have to compile them themselves. On Linux, chances are that you can install them with your distribution’s package manager, e.g. sudo apt install git on a Debian-like distribution. There are also various GUIs available. I think that the Windows installer always installs a simple GUI. Most IDEs, including Visual Studio Code, also have built-in git functionality.

You also need someplace to store your stuff (repositories). The easiest way is to create an account on Github. You can create public repositories that are visible to anyone, and private repositories that are only visible to yourself. You can also use Gitlab. For a beginning git user, github is probably the easier solution. I chose Gitlab because I can self-host it, which gives me full control over my repositories.

Basic workflow

Adding a new repository

Let’s say you’ve got a local directory with a project, and want to add this to a new repository on Github. You create a repository “project” on Github, then open a command line in the project directory and type the following commands:

git init
git add .
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/username/project.git
git push -u origin main

This will

• Create the local repository
• Add everything in the current directory to it
• Create a “commit”, which you’ll do every time when you’re ready to commit changes to the repository
• Select the main branch
• Add a remote repository – the one you just created on Github
• Push everything in the main branch to the remote repository

Note that it’s not necessary to push every commit immediately. Let’s say you’ve just finished parts of the program and want to save that state before continuing. Just do a new commit, then continue coding. Do another commit and push at the end of the day.

Cloning, pulling and fetching

OK, so how do you get the files onto a second computer to continue your work there? This starts with cloning the repository. You might have seen this already in public Github repositories. You can download the code as ZIP, but you can also clone it, which will create a local copy of the entire repository.

After making changes, you’ll want to commit and push them again like described above. On the other computer, you’ll now either have to pull or fetch and merge to get the changes. fetch only downloads the changes, but doesn’t integrate them into the local copy yet – which is done with merge. pull directly applies all changes.

Here we go – you can now synchronize the repositories on multiple computers, using the Github repositories as central exchange.

Branches

There are times when you want to try something new, but are not sure yet whether that’s going to be the definitive solution. Instead of editing your old code, and then having to revert to a previous commit (which would mean losing all changes), you can also create a branch. On this you can make changes and then at some point merge it into the main branch, deciding which changes to keep and which to ignore.

.gitignore

Chances are you’ve got files in the project directory that you don’t want added to the repository – output files, binaries, intermediate files from compiling, and other stuff. In a .gitignore file, you can define which files and subdirectories are to be ignored. A lot of useful templates can be found here.

Contributing to other projects – forks and pull requests

Once you start looking at active projecs on github, you might notice that the maintainers say something like “pull requests welcome”. What does this mean, and how do you contribute to other people’s projects? You can’t edit their code or commit to their repository directly. Instead, the workflow is like this:

1. You create a fork. This is a copy of the original project in your own repository.
2. You make the desired changes to this copy and also commit/push them to it.
3. Once you’re satisfied, you create a pull request in the original project. This tells the maintainers that you’ve mad changes that you’d like to integrate into the original codebase. They can then review the changes you’ve made. Once they’ve merged them, the original project will contain your changes.