Git Tutorial for Beginners

Col­lab­o­ra­tive de­vel­op­ment of software projects not only happens within companies. Within the open-source sector, several hundred to thousands of vol­un­teers (depending on project size) are involved in main­tain­ing, op­ti­miz­ing, de­vel­op­ing or modifying a program. These kinds of projects would be virtually un­work­able without a suitable system for recording and managing the numerous changes submitted by different de­vel­op­ers.

One of the most popular solutions to version man­age­ment is the license-free tool Git. It’s easy to learn and free of charge. In this tutorial, we explain the most important Git basics you need to get started with the version man­age­ment program.

Git is a dis­trib­uted version control system developed by Linux creator Linus Thorvalds in 2005 and released under the free GNU-GPLv2 license. What’s special about the tool is that, although a central repos­i­to­ry exists for each project, all involved users download a local working copy of this directory onto their own working devices. Each of these copies rep­re­sents a complete backup of the repos­i­to­ry, rendering a con­tin­u­ous network con­nec­tion un­nec­es­sary and enabling offline working. Moreover, the copies can be used to restore each project in the event the main repos­i­to­ry fails or becomes damaged. Im­ple­ment­ed changes can be exchanged with all other project par­tic­i­pants at any time and – where relevant – included in the repos­i­to­ry.

Anyone who wishes to learn software man­age­ment with Git should first fa­mil­iar­ize them­selves with the software and its user interface. Git is available for Windows, Unix/Linux and macOS, however, the various versions differ slightly in terms of their use. After in­stalling the re­spec­tive version, you can control the tool platform-in­de­pen­dent­ly using the command line or a graphical user interface.

Binary in­stal­la­tion files, guides for packet manager in­stal­la­tions (Unix systems) and turn-key portable editions for the in­di­vid­ual systems are available on the official website of the Git project. Simply download the required packet or use the suitable packet in your packet man­age­ment and then follow the in­stal­la­tion wizard in­struc­tions. The in­stal­la­tion step is un­nec­es­sary in case of a portable edition, of course.

Once Git is installed on your system, you can use the version man­age­ment system to manage your projects. As with any software, you’ll first need to learn the basic functions and commands to get the most out of the ap­pli­ca­tion. As part of our complete Git tutorial for beginners, we’ll explain the most important steps for setting up Git and the necessary command line in­struc­tions, allowing you to establish and manage your own repos­i­to­ry with ease.

The Git repos­i­to­ry is the central directory of a managed project and therefore the main hub for all par­tic­i­pants. It’s where the complete version man­age­ment is con­trolled. Your first step in Git will be to create a central repos­i­to­ry – or clone one (in the form of a working copy), if you’re joining a col­lab­o­ra­tive de­vel­op­ment project already managed using Git.

If you want to configure version man­age­ment or install the tools to learn how to work with Git, you’ll need to create a new repos­i­to­ry. To do so, switch to the desired local repos­i­to­ry on your device via “cd” (change directory):

Now execute the following command to generate a .git repos­i­to­ry:

If the Git repos­i­to­ry for your project already exists, you’ll just need the web or network address for this repos­i­to­ry in order to generate a working copy on your computer using the “git clone” command:

The efficient or­ga­ni­za­tion of the working repos­i­to­ry is among the most important pillars of Git. It allows you to propose your own changes and additions to a project that can be adopted as “commits”, and obtain in­for­ma­tion about the ad­just­ments made by other users. You can check the current status of your working copy by running the following command:

To add a new file for version man­age­ment or submit a revised file for the next commit, apply the “git add” command to the file (it must be contained in the working repos­i­to­ry). In our Git guide, we add a text document called “Test” as an example:

All changes that you submit for version man­age­ment (as described in the previous section) always need to be confirmed via Commit in order to be included in the HEAD. The HEAD is a type of index that refers to the last effective commit in your current Git working en­vi­ron­ment (also known as “branch”). The command for this step is shown below:

As you can see in the screen­shot, after running “git commit” you’ll receive a summary regarding the commit. In the preceding square brackets, you’ll find the name of the branch (“master” in this case, since our working repos­i­to­ry is also the central repos­i­to­ry), in which the changes have been adopted, as well as the SHA-1 checksum of the commit (“c0fdc90” here). This is followed by the freely chosen comment (“test” in our example) and specific in­for­ma­tion about the changes made.

If you adopt changes in the form of a commit, you can sub­se­quent­ly revise or even remove the content at any time. A typical case in which ad­just­ments are necessary is, for example, if you have generated the commit too soon and forgotten important files or changes. In this instance, you’ll need to provide the new or adjusted files retroac­tive­ly using “git add” and repeat the entry into the central repos­i­to­ry. To do this, add the option --amend to the standard command:

However, if you want to withdraw the most recent commit, you can use the following Git command:

This command reverses the commit last included in the HEAD. The files it contains are then reset back to the status: “Planned changes for the next commit”. To delete the files entirely, enter the command below instead:

Learning how to manage projects with Git is worth­while because of its basic ver­sion­ing features. One of the big ad­van­tages of the open-source system is that you can view which changes were last made to the repos­i­to­ry. The Git command for this is:

The log command can also be modified by various pa­ra­me­ters. Some useful options are shown in the table below:

So far, we’ve shown you how to save changes as a commit in the HEAD of the local repos­i­to­ry. For the commit to be included in the central repos­i­to­ry, however, the following command needs to be entered:

After inputting this command, Git au­to­mat­i­cal­ly adopts all generated commits, which pre­vi­ous­ly existed only in the working copy, into the central repos­i­to­ry. This repos­i­to­ry is also referred to as the “master”. If you replace this name in the listed code with the name of another branch, the files will be sent there instead.

Like many other version man­age­ment systems, Git also offers a tagging feature that allows selected points in the history of a repos­i­to­ry to be marked as important. These tags are typically used to label the releases of a software program (like version 1.0, 2.0, etc.) so that they remain easy to access even for larger projects. Git supports two types of tags:

• “Annotated” tags are saved as in­de­pen­dent objects in the database, including their own checksum, tagging message, date, name, and email address of the tag author as well as an optional GNU Privacy Guard signature (GPG signature).
• “Light­weight” tags act like branches, only serving as a reference to a commit. This type is suitable when you only need temporary tags or don’t want to save the extended in­for­ma­tion.

You can create annotated tags in Git by using the “git tag -a” command on the re­spec­tive commit. If you also add the “-m” parameter as a suffix, you can compose the desired tagging message directly in the command line (between straight quotation marks). In this Git guide, we generated the “Test” commit which we can also link with a tag including the message “example tag”:

The approach for light­weight tags is similar. However, you only need to use the basic command “git tag” on the relevant commit – without any further pa­ra­me­ters. This command would appear as follows for our Git tutorial example:

As soon as tags exist for your repos­i­to­ry, you can also display them with the “git tag” command and the optional “-l” or “--list” pa­ra­me­ters:

To delete a tag from the local working repos­i­to­ry, apply the command chain “git tag -d” to it. We can delete our tag for “Test” as follows:

Tags have to be manually adapted into the central repos­i­to­ry. To do so, both the tag name and the command “git push origin” are required. Instead of the tag name, you can also add the parameter “--tags” which carries all generated tags over to the repos­i­to­ry.

The branches used in this Git tutorial are es­sen­tial­ly the in­di­vid­ual working versions of the central repos­i­to­ry, which itself is clas­si­fied as a branch – called “master”. With these branches, Git offers the perfect foun­da­tion for de­vel­op­ing features and functions in isolation and combining them at a later date. This process is also known as “merging”.

It’s quite easy to create a new branch: You only need the in­struc­tion “git branch” which you then sup­ple­ment with the desired name of the branch. To create an example branch called “test_branch”, you’d enter the command below:

After that, you can switch to this branch at any time using “git checkout”:

If you want to merge branches, you can use the “git merge” command. First, enter the “checkout” command to switch to the repos­i­to­ry that is to integrate the other branch and then execute the merge command including the name of the branch to be merged. For example, our working version “test_branch” can be merged into the central repos­i­to­ry as follows:

Once you’ve merged the branches and therefore no longer need a certain branch, you can simply delete it. To this end, add the command “git brand -d” to the branch no longer needed. Our Git tutorial example “test_branch” can be removed by running the command below: