Why does Git dominate revision control

namespace cpp

I firmly believe that a pound of beef makes a good broth.

Version control is an important tool for programmers. For open source projects, version control with Git and Github as external source code storage dominates today. Getting started on Windows systems is easier with GitExtensions. Once you understand the principle, it's easy to remember. This is to be shown here. Terms such as repository, clone, commit and merge are explained.


Required software

Git for Windows forms the basis. The version control can thus be used both via the console and by right-clicking in Explorer (Git-Bash).

You can quickly find your way around the graphical interface of GitExtensions once you have understood the concept. Instead of "click here" or "click there" I will therefore present the commands in the command line version. This is also easy to learn. I assume that programmers know how to open a console and use it to navigate directories. After 30 years of Windows, this is no longer a matter of course. If you can't cope with it, you can use the attached pictures as a guide, which appear when you right-click in the Explorer.


For the resulting example project, three directories are sufficient, which may be on different computers and which are assigned to three contributors. Let's call them Anton, Bernd and Charlie. First of all, every Git user has to set a few things that are important later: (Charlie already has a Github account and does not want to see his own email address published there.)

git config --global user.name charlies-username git config --global user.email CharliesPrivateNoReplyGithubAddress

Single user system

Create and version a project

Charlie's real name is Charlotte, but her friends call Ingrid (incomprehensible to non-Saxons). Charlie is planning a project for a cookbook with Saxon dishes. She creates a new folder for the project:

md cookbook cd cookbook

As an experienced programmer, she immediately sets up version control:

git init

This creates a repository in the hidden subdirectory of the cookbook folder. The filing system saves all the versions of the project that are created.

Console programs unsettle some beginners because they do not provide any chatty feedback "Repository created". The programs only complain when an error has occurred. No news are good news. It is okay not to see the storage folder on the graphical user interface: Access for unauthorized persons is prohibited. If you should see it, don't mess with it! Otherwise there is a risk of ruining the repository. On the console, Charlie can make sure that it has been created:

to you

But she is deliberately not interested in the content. Charlie can now create, change, add files and apply the changes to the repository. She puts a file


with the name and places the file with

git add index.html

under version control. With

git status

she can see what changes have been made to the versioning and submit the changes with the command

git commit

in the filing system (commit). An editor opens. A brief description of the changes must be included in this:

Project cookbook created

At least this should be done. Charlie made the file a minimal HTML file

<html> <body> Rezepte: </body> </html>

expanded. After another

git add index.html

which caches the current work status, called "staging" in Git, and

git commit -m "table of contents changed"

the first two versions are in the repository, which can be accessed with commands such as

git show git status git log --pretty = oneline

can convince. Each version is given a fairly long number (hash value):

723872d7480b99cc5cd015901d6b758a6fcbb340 (HEAD -> master) Table of contents created bd0e0a1562f2e069706562bf796b82e7739c7180 Project cookbook created

The graphical tool GitExtensions even provides this information with a click of the mouse:

Version control is that easy. But what is it good for?

time Machine

For Charlie, version control is a time machine with which it can jump to all previous statuses in the history of the project. Jumps to future versions such as "Project Completion" are unfortunately not possible. (Why not?)

Charlie needs to test an earlier version of their project again. To do this, it sets the working copies, specifying the hash value

git checkout bd0e0a1562f2e069706562bf796b82e7739c7180

to an earlier state. No juggling with data carriers, nonexistent backups or the like. She can do her test immediately and

git checkout master

brings the working directory up to date again.

If Charlie has made changes to the working copies that have failed or deleted files since the last commit, she can use these changes with

git checkout index.html

just undo.

Basically, the work under version control always runs in these steps:

  1. Test if it works.
    • If so, commit the change.
    • If no, undo the change.

If you only want to use version control as a single-user system, you can stop reading here. There is nothing more to explain.

Clone projects

Charlie has a very crazy idea about her project that she wants to try out. She suspects that this experiment will take a little longer and will probably also require several versioning steps. But she doesn't want to affect the current project if her experiment fails. To do this, it creates a copy (a clone) of the current project repository:

cd .. git clone cookbook experimental

The version control creates the specified directory for this. The clone can now be modified independently of the main branch. This "code fork" gives rise to various branches of development. If Charlie's idea is not feasible, she can safely delete the experimental directory.

Why not just copy the directory, you can? The problem is not with copying, but with merging different lines of development. Without version control, it becomes a nightmare.

The clone saves the information from which repository it originated. If the experiment is successful, Charlie can transfer the experimental versions to the higher-level repository ("push"). In the opposite direction, changes from the higher-level repository can be imported into the experimental clone ("pull"). The processes of this comparison with several, distributed repositories are similar to those in teamwork.

Charlie makes the project available to her employees, mostly via a repository server on the web, we assume via Github, for example. She creates a new repository on Github and follows the instructions given there for an existing project:

git remote add origin https://github.com//kochbuch.git git push -u origin master


Distributed work

Anton creates a copy of the project

git clone https://github.com//kochbuch.git cd cookbook

on his computer. All files of the project are now in its directory. Its local repository is located in the subdirectory. Anton creates a recipe

Abernmauke ---------- Wash 1 pot full of potatoes, peel them and cook them in salted water until they are soft, then drain while adding milk, mash with grated nutmeg and a little salt to taste

and saves the version in its repository:

git add abern.txt git commit

Bernd does something similar:

git clone https://github.com//kochbuch.git cd cookbook

Why is there only Charlie's file in his directory? Anton put the "Abern" recipe in his local repository, not Charlie's. Git is a distributed version control system. After cloning, Anton and Bernd can work on their local repositories without a permanent network connection. The data traffic with the local hard drive is much faster than via the network connection.

Bernd creates the recipe

Blinsen ------- 1 liter of milk (fresh or sour), mix 3 eggs + 3 tablespoons of sugar with the addition of flour until a thin dough is formed, spread a thin layer of dough in a well-oiled pan as soon as the underside is golden brown

and also stores its version:

git add blinsen.txt git commit

Did I mention that Anton and Bernd also configured their usernames for Git?

Without version control, the current situation is a nightmare. We have (luckily only) three developers and three completely different project versions. Who should keep the overview and bring it together again? The developers do this themselves under distributed version control.

Publish local changes

Anton wants to return his changes to Charlie's repository. Before doing so, it asks for changes in the higher-level repository:

git fetch

Because the Github repository is unchanged, Anton can immediately follow his changes

git push


Maintain incoming changes

Bernd sees Anton's change. With

git merge

Both development branches are merged in the working directory. Since only new files () are added, there are no conflicts. The merging of both revisions can now be done by Bernd

git push

Send to the higher-level repository. Anton takes over this version

git pull

(that's in a) turn to its local repository. Anton now also has the current status in his working directory.


Anton and Bernd now both change the index file of the cookbook:

<html> <body> Rezepte: <a href="abern.txt">Kartoffelbrei</a> </body> </html>

but in different ways:

<html> <body> Rezepte: <a href="blinsen.txt">Eierkuchen</a> </body> </html>

Both adopt the changes in their local repository (commit). Anton puts his change in the central repository first:

git push

Bernd finds the changes and transfers them to his repository:

git pull

Because the same file was edited, there is a version conflict:

The version control system can automatically merge changes in different sections of the text file in the working directory without any action. Since both authors have inserted the same line, but with different content, the conflict can only be resolved manually in the editor (click on the red field at the bottom right: Resolve ...). A comparison tool like kdiff3, which (after installation and configuration) can be called up via the graphical interface of GitExtensions, makes this easier.

Bernd has to decide whether

  • both, if so, in which order,

is taken over. After saving and exiting, the conflict is considered resolved. It may still have to be deleted. The merged version is stored by Bernd and transferred from the local to the higher-level repository:

git add. git commit git push

Anton takes the changes back into his directory. When Charlie comes back from the field, updates her working directory and looks at her repository.

She notices that Anton and Bernd added two recipes, and, and to the table of contents during their absence:

charlie / index.html
<html><body> Rezepte:<a href="abern.txt">Kartoffelbrei</a><a href="blinsen.txt">Eierkuchen</a></body></html>

Teamwork is fun this way!

Repository server

Setting up repository servers with high security requirements requires administrator knowledge, which is beyond the scope of this text. Github has also been offering private repositories since 2019. Registering, setting up repositories and sharing are all done via the web browser. Wiki and issue tracking can be used for each project. Only invited users ("friends") see private repositories and may be allowed to make changes there.

Write rights are not required for public repositories. Each user can clone other people's projects, add "pull requests" from others to their local repository and then publish the merge again under their own account. This "pull-only" version control is practiced by large open source projects.


The process described here is based on the following software:

Install Git, configure and. Optionally install a mergetool, enter the mergetool / difftool in GitExtensions.

No source code is lost again ...

Last modified: 2020-05-31 15:51 by