Version control with Git

Version control with Git#

The version management system called Git enables collaborative work on the source code of the work as well as the exchange of contributions between the authors and the traceability of the changes.

It is therefore also an important tool for reviewing and discussing changes and thus achieving quality assurance in the team.

Here, too, there are essentially 3 important things to get to know:

  • The database (repository)

  • Contributions (commits)

  • Branches

Git is basically based on entries that build on one another, i.e. the respective changes are entered in Git and Git always saves the changes in relation to the *previous version.

This creates chains of entries (contributions, commits) with changes that always refer to the predecessor.

These chains of contributions can branch out if, for example, two authors make different changes starting from a common basis. Branches are used to depict this classic situation. They allow different people to edit the work in parallel and at the same time, independently of one another. These branches can of course also be merged again. Ideally, the different changes made by the respective authors are then combined with one another and a uniform version is created with the contributions of the authors involved. Of course, conflicts can also arise when merging, for example if two authors have edited the same part of the work. It is then up to a representative to resolve the conflicts sensibly and create a cleaned-up version.

A repository (directory) is essentially a database in which the respective entries are recorded.

The repository is the database#

The versioning database of a project versioned with Git is called a Git directory, Git repository or simply repository or repo.

Commits (inputs/contributions)#

But how is the version information saved or recorded? To do this, Git compares the status of the files in the project folder with the last saved status in the database and displays changed content. The user can now summarize changes in entries (commits), add a description and have them entered into the database (commit).

Each commit consists of a description text, a check number and the changes compared to the previous commit. This means that each commit only saves the changes and not the entire project folder, and therefore always builds on the previous commit. This results in a tree of entries, from the very first entry to the last commit.

Branches#

The real highlight are the branches.

Let’s imagine a small repo with 3 commits (A, B and C):

A→B→C

Furthermore, we have 2 authors (X, Y) who make changes in version C independently of each other (X1, X2 or Y1, Y2, Y3), this would look something like this:

A ─ B ─ C ─ X1 ─ X2
        │
        └── Y1 ─ Y2 ─ Y3

So we now have 2 competing version lines: X2 and Y3. We see that both version lines are based on C and then – branch. So these version lines are called branches.

Of course we want to merge these branches, which an editor does after checking the changes – But before that we have another challenge, we have to name these branches. So the commits of the branches get a name tag with a name, in our case we name the branches after the authors (Author-X and Author-Y). A commit of a branch can also have several name tags.

Then there is a special branch called master. In this branch the editor manages the contributions he has recorded from the other authors:

At the beginning there is only the master branch:

        ┌────────┐
        │ master │
        ├────────┘
        │
A ─ B ─ C

Then a branch is created for each author, so Commit C has 3 name tags:

        ┌────────┐
        │ master │
        ├────────┘
        ├─────────┐
        │ Autor-X │
        ├─────────┘
        ├─────────┐
        │ Autor-Y │
        ├─────────┘
        │
A ─ B ─ C

Finally, the authors edit their branches:

        ┌────────┐
        │ master │
        ├────────┘
        │        ┌─────────┐
        │        │ Autor-X │
        │        ├─────────┘
        │        │
A ─ B ─ C ─ X1 ─ X2
        │
        └── Y1 ─ Y2 ─ Y3
                      │
                      ├─────────┐
                      │ Autor-Y │
                      └─────────┘

The following applies:

  • Each commit builds on the previous one and thus forms

a branch.

  • Each branch has at least one name tag.

Finally, the editor combines the two branches, resulting in commit D, which contains the 5 author contributions and any changes made by the editor:

                 ┌─────────┐    ┌────────┐
                 │ Autor-X │    │ master │
                 ├─────────┘    ├────────┘
                 │              │
A ─ B ─ C ─ X1 ─ X2 ─────────── D
        │                       │
        └── Y1 ─ Y2 ─ Y3 ───────┘
                      │
                      ├─────────┐
                      │ Autor-Y │
                      └─────────┘

Merge branches (“Merge”)#

Special case: Installing a repository on a local computer#

If you install a repository on a local computer to work on it, it consists of two things:

  1. Working folder: This is where the project files are located at a version level specified by the user. Changes to files are made in this project directory in the usual way.

  2. .git** folder** or the actual Git database:

The database in which the version information is stored is always located in the .git subfolder of the work folder. The user actually has nothing to do with this folder, but of course it must not be deleted.

There can be several of these databases for the same project, which exchange data with each other and thus keep each other up to date. In principle, every author can have such a database on their computer (or several) and exchange contributions with other, remote databases.

Our project has set up a central database called origin where authors send their contributions or download contributions from other authors. A repository (normally) consists not only of the database, but also of a working directory. This represents the status of a version at a defined point in time (or at the time of a defined contribution). Git can be instructed to set the working directory according to any point in the version history of the database (checkout). The files and documents in the working directory can then be edited. Git then recognizes all changes to the files compared to the originally set version. These changes can then be entered into the database as contributions (committed). The working directory is used to edit entries and thus to create new entries in the database.

Technische Details#

Wikipedia contributors. (2019, June 21). Git. In Wikipedia, The Free Encyclopedia. Retrieved 10:35, June 23, 2019, from https://en.wikipedia.org/w/index.php?title=Git&oldid=902826917

Seite „Git“. In: Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand: 23. Mai 2019, 06:47 UTC. URL: https://de.wikipedia.org/w/index.php?title=Git&oldid=188859677 (Abgerufen: 23. Juni 2019, 10:41 UTC)

Git. (2018, September 16). Wikibooks, The Free Textbook Project. Retrieved 10:46, June 23, 2019 from https://en.wikibooks.org/w/index.php?title=Git&oldid=3464901.

Git ist eine freie Software zur verteilten Versionsverwaltung von Dateien, die durch Linus Torvalds initiiert wurde.

Git ist ein verteiltes Versionsverwaltungssystem, das sich in einigen Eigenschaften von typischen Versionsverwaltungssystemen unterscheidet:

On this page ...