Git für Dummies E-Book

Michael Kaufmann

• Herausgeber: Wiley-VCH GmbH
• Kategorie: Wissenschaft und neue Technologien
• Serie: ...für Dummies
• Sprache: Deutsch
• Veröffentlichungsjahr: 2020

Seitenzahl: 421

Beschreibung

Git hat sich als Quellcodeverwaltung durchgesetzt und ist der De-facto-Standard in der Softwareentwicklung. Alle Unternehmen, die noch nicht auf Git sind, werden die nächsten Jahre wechseln. Und nicht nur die Entwicklung - auch Administration, Sicherheit und Dokumentation finden zunehmend auf Git statt. Git ist damit heute das wichtigste Werkzeug für alle digitalen Produkte - quasi die Werkbank. Wenn Sie wissen wollen, wie Sie Git richtig implementieren und welche Regeln Sie für die Zusammenarbeit aufstellen sollten, dann sind Sie hier richtig. Dieses Buch ist eine Einführung in das effektive Arbeiten mit Git - geeignet sowohl für Berufseinsteiger als auch für erfahrene Entwickler, die zu Git wechseln.

Leseprobe

Git für Dummies

Schummelseite

ALLGEMEINE SYNTAX

Git übernimmt immer einen Befehl (command) und dann die entsprechenden Argumente (args) für diesen Befehl:

$ git command args

Argumente können in der langen Form mit zwei Bindestrichen übergeben werden:

$ git commit --all --message "Eine Commit-Message"

oder in der Kurzform mit einem Bindestrich:

$ git commit -a -m "Eine Commit-Message"

Kurze Parameter können auch zusammengefasst werden:

-am ist also dasselbe wie -a -m:

$ git commit -am "Eine Commit-Message"

DIE HILFE AUFRUFEN

Befehl

Beschreibung

$ git help -a

$ git help --all

Liste aller Befehle (command), die in Git verfügbar sind.

$ git help -g

$ git help --guide

Liste von erweiterten Konzepten (concept).

$ git helpcommand

$ git helpconcept

Zeigt eine ausführliche Hilfe zu dem Befehl beziehungsweise dem Konzept.

$ gitcommand-h

Zeigt die kurze Hilfe zu dem Befehl.

$ git command --help

Zeigt die ausführliche Hilfe zu dem Befehl.

SYNTAX IN DER HILFE

Die Syntax der Befehle in der Hilfe enthält folgende Zeichen mit besonderer Bedeutung:

Platzhalter werden in und geschrieben:

<file>

--sort=<key>

Optionale Teile werden immer in eckige Klammern und gesetzt:

[<extra>]

--exec-path[=<path>]

Optional ein oder mehrere Instanzen angeben erfolgt mit drei Punkten:

[<patch> …]

Mehrere Alternativen werden durch getrennt:

[-q | --quiet]

[--utf8 | --no-utf8]

Normale Klammern und werden zum Gruppieren verwendet:

[(<rev> | <range>) …]

In obigem Beispiel kann eine beliebige Anzahl von rev und range angegeben werden, da die drei Punkte außerhalb der Klammern stehen.

Im folgenden Beispiel kann eine beliebige Anzahl von -p angegeben werden, aber nur mit je einem parent zusammen:

[(-p <parent>) …]

Im folgenden Beispiel muss eine Instanz von name angegeben werden. Außerdem muss entweder -a, -d oder branch angegeben werden:

git remote set-head <name> (-a | -d | <branch>)

TAB-COMPLETION

Ihre Shell unterstützt Tab-Completion – also das automatische Vervollständigen beim Drücken von – für Befehle, Argumente und Pfade. Tippen Sie also die ersten ein oder zwei Buchstaben eines Befehls und drücken Sie dann Tab.

$ git co

Je nach Konsole wird Ihnen entweder eine Liste angezeigt, oder es wird der erste Treffer verwendet. Durch erneutes Drücken von navigieren Sie durch die Ergebnisse. Mit + navigieren Sie rückwärts.

Tab-Completion funktioniert auch für Argumente. Geben Sie nach dem Befehl einen Bindestrich ein und drücken Sie erneut :

$ git commit

Dasselbe funktioniert auch bei Pfaden oder Dateien, zum Beispiel bei geänderten Dateien mit git add:

$ git add

SCHREIBWEISE BEI PFADANGABEN

Beim Arbeiten mit Pfadangaben gelten folgende Regeln:

Zeichen

Bedeutung

~

Steht für den Pfad zum Benutzerprofil des aktuellen Benutzers (HOME).

..

Das übergeordnete Verzeichnis.

.

Das aktuelle Verzeichnis.

-

Das zuletzt verwendete Verzeichnis.

/ oder \

Das Stammverzeichnis (Linux oder Mac / und Windows \). Das Zeichen ist auch das Trennzeichen für Ordner in einer Pfadangabe.

?

Steht für genau ein beliebiges Zeichen.

*

Steht für eine beliebige Anzahl an Zeichen.

[aAbB]

Steht für eines der Zeichen in der Klammer (also a, A, b oder B).

[c-f]

Steht für eines der Zeichen in der Klammer (also c, d, e oder f).

WICHTIGE ZEICHEN UND BEFEHLE AUF DER KOMMANDOZEILE

Folgende Grundlagen auf der Kommandozeile funktionieren auf Mac, Linux und der PowerShell:

Befehl

Beschreibung

$ echo "Text"

>Text

Gibt Text auf der Kommandozeile aus.

#Kommentar

Ein Kommentar wird einfach ignoriert und dient nur der Information.

;

Trennzeichen für mehrere Befehle in einer Zeile.

\ oder `

Trennzeichen für Befehle, welche über mehrere Zeilen gehen: \ in Bash und ` in PowerShell. Diese Trennzeichen werden auch verwendet, um spezielle Zeichen als normale Zeichen zu behandeln, indem sie ihnen vorangestellt werden.

$ echo "Text" >Datei.txt

Schreibt Text in die Datei Datei.txt.

$ echo "Text" >>Datei.txt

Fügt Text am Ende der Datei Datei.txt an.

$ catDatei.txt

Gibt den Inhalt der Datei Datei.txt auf der Kommandozeile aus.

$ ls

Listet die Dateien im aktuellen Verzeichnis auf.

$ cdPfad

Wechselt in den angegebenen Pfad (relativ oder absolut).

GRUNDLEGENDE GIT-BEFEHLE

Ein Repository erstellen

Befehl

Beschreibung

$ git init

Erstellt ein neues Repository.

$ git cloneURL

Erstellt eine lokale Kopie eines Remote-Repositorys mit der URL.

Arbeiten mit Branches

Befehl

Beschreibung

$ git branchBranch-Name

Erstellt einen neuen Branch.

$ git switchBranch-Name

$ git checkoutBranch-Name

Wechselt auf den Branch Branch-Name.

$ git switch -cBranch-Name

$ git checkout -bBranch-Name

Wechselt auf einen neuen Branch Branch-Name.

Arbeiten mit lokalen Änderungen

Befehl

Beschreibung

$ git addDatei1 Datei2

Fügt Änderungen in Datei1 und Datei2 dem Index (Staging-Bereich) hinzu.

$ git add [.|--all|-A]

Fügt alle Änderungen dem Index hinzu. Durch den Punkt werden nur geänderte Dateien des aktuellen Verzeichnisses sowie aller Unterverzeichnisse hinzugefügt.

-A oder --all funktionieren aus allen Verzeichnissen des Repositorys.

$ git mvDateiNameAlt DateiNameNeu

Verschiebt eine Datei oder benennt diese um.

$ git restoreDatei

Stellt den Stand der Datei seit deren letztem Commit wieder her.

$ git restore --stagedDatei

Stellt die Datei aus dem Index wieder her.

$ git rmDatei

Löscht Dateien aus dem Arbeitsverzeichnis und dem Index.

Den gemeinsamen Verlauf bearbeiten

Befehl

Beschreibung

$ git commit [-m "Commit-Message"]

Fügt Änderungen im Index dem Verlauf hinzu. Mit der Option -m kann direkt eine Commit-Message angegeben werden. Ansonsten öffnet sich der Editor, und die Message kann dort eingegeben werden.

$ git mergeBranch-Name

Fügt die Änderungen des Branches Branch-Name mit den Änderungen des aktuell aktiven Branchs zusammen.

$ git reset [--hard|--soft|--mixed]REF

Setzt den Status auf eine Referenz REF. Der dazugehörige Parameter gibt an, was mit den Änderungen passiert, die rückgängig gemacht werden:

--mixed (Standard): Änderungen werden in das Arbeitsverzeichnis geschrieben.

--hard: Änderungen werden komplett verworfen und REF komplett hergestellt.

--soft: Änderung werden in den Staging-Bereich/Index geschrieben und können neu commited werden.

$ git rebaseBranch-Name

Die Änderungen des aktuellen Branchs werden auf den neuesten Stand von Branch-Name angewandt.

$ git tagTag-Name

Setzt einen Pointer Tag-Name auf den aktuellen Commit.

$ git rebase [-i | --interactive]

Startet einen interaktiven Rebase.

Referenzen

Einträge in der Historie können absolut und relativ referenziert werden.

Referenz

Beschreibung

Branch

Pointer auf den letzten Commit eines Branches.

Tag

Pointer auf einen bestimmten Commit.

SHA-1

Der SHA-1 ist die ID eines Commits und identifiziert diesen. Es reicht, wenn die ersten Zeichen angegeben werden. Es müssen genug Zeichen sein, damit der Commit eindeutig ist. Ansonsten zeigt Git einen Warnhinweis an.

HEAD

Pointer des aktuellen Status im Arbeitsverzeichnis.

~[n]

Elternteil (Parent) der angegebenen Referenz. main~ referenziert den Parent des letzten Commits vom Branch main. HEAD~2 referenziert den Parent des Parents des aktuellen Standes.

^[n]

Ebenfalls der Parent. Allerdings kann bei Commits mit mehreren Parents ein anderer als der erste referenziert werden. HEAD^2^ zeigt auf den Parent des zweiten Parents des aktuellen Commits.

REF@{index}

Aus dem Reference-Log (git reflog) kann über den Index auf einen Eintrag im Log verwiesen werden. HEAD@{2} zeigt auf den dritten Eintrag im Log.

REF@{makro}

Die Syntax kann auch mit anderen Referenzen und Makros verwendet werden. Zum Beispiel zeigt main@{one.week.ago} auf den Commit, auf den der Branch main vor einer Woche gezeigt hat.

REF..REF

Gibt einen Range von Commits an. main..HEAD zeigt alle Commits zwischen dem aktuellen Stand und dem ersten gemeinsamen Commit im Branch main.

REF…REF

Mit drei Punkten wird der Range mit allen möglichen Commits angegeben. main…HEAD zeigt also alle Commits zwischen dem aktuellen Stand und dem neusten Commit von main.

REF^!

Gibt einen Range zum Vorgänger an. main^! ist eine Abkürzung für main^..main. Diese Syntax ist sehr nützlich, wenn man einen Commit mit seinem Vorgänger vergleichen möchte: git diff eb28a^!

Das Repository synchronisieren

Befehl

Beschreibung

$ git fetch

Ruft Änderungen aus dem Remote-Repository ab.

$ git pull

Ruft Änderungen ab und führt sie mit den aktuellen zusammen.

$ git push

Überträgt alle Änderungen in das Remote-Repository.

Den Verlauf inspizieren

Befehl

Beschreibung

$ git diff [--staged]

$ git diff HEAD^!

Zeigt Änderungen zwischen Commits an. Wird kein Parameter angegeben, dann wird das Arbeitsverzeichnis mit dem HEAD verglichen. Der Parameter --staged vergleicht mit dem Index. Es kann aber auch ein Range für den Vergleich angegeben werden.

$ git status

Zeigt den Status des Arbeitsverzeichnisses.

$ git log

$ git log -1

$ git log --oneline --graph

Zeigt den Verlauf der Commits an. Die Anzahl der Einträge kann beschränkt werden (-2 zeigt die letzten zwei Commits an). Es kann aber auch ein Range angegeben werden. Die Option --oneline reduziert die Ausgabe pro Commit auf eine Zeile. Die Option --graph zeigt Verzweigungen grafisch an.

$ git show

Zeigt unterschiedliche Dinge an.

Commits: zeigt die Log- und Diff-Ausgabe.

Tags: zeigt die Tag-Informationen und den Inhalt des referenzierten Commits (ebenfalls Log- und Diff-Ausgabe)

Trees: zeigt die Namen der im Tree enthaltenen Elemente.

Blobs: zeigt den Inhalt der Datei.

Git für Dummies

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

© 2021 WILEY-VCH GmbH, Weinheim

Wiley, the Wiley logo, Für Dummies, the Dummies Man logo, and related trademarks and trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries. Used by permission.

Wiley, die Bezeichnung »Für Dummies«, das Dummies-Mann-Logo und darauf bezogene Gestaltungen sind Marken oder eingetragene Marken von John Wiley & Sons, Inc., USA, Deutschland und in anderen Ländern.

Das vorliegende Werk wurde sorgfältig erarbeitet. Dennoch übernehmen Autoren und Verlag für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie eventuelle Druckfehler keine Haftung.

Coverfoto: © dekzer007 – stock.adobe.comKorrektur: Birgit Volk, BonnBindung

Print ISBN: 978-3-527-71697-5ePub ISBN: 978-3-527-82623-0

Über den Autor

Michael Kaufmann ist seit mehr als 20 Jahren leidenschaftlicher Softwareentwickler und arbeitet seither mit den unterschiedlichsten Versionsverwaltungen. Seit 15 Jahren befasst er sich mit dem Thema Application Lifecycle Management und DevOps, was ihn vor mehr als acht Jahren zum Thema Git gebracht hat.

Er ist Spezialist für DevOps, GitHub und Azure DevOps und unterstützt seine Kunden als Coach und Trainer auf ihrem Weg zu agilen DevOps-Organisationen und bei der Implementierung von modernen Entwicklungs- und Betriebskonzepten. Seit 2015 wurde ihm von Microsoft jedes Jahr die Auszeichnung »Most Valuable Professional« in der Kategorie »Developer Technologies« verliehen.

Neben der Technik war Mitarbeiter- und Unternehmensführung immer einer seiner Schwerpunkte. Aktuell verantwortet er beim internationalen Beratungsunternehmen CGI als Vice President den Bereich »DevOps & Innovation«. Dort begleitet er seine Kunden bei der digitalen Transformation – nicht nur technisch, sondern auch strategisch.

Michael Kaufmann ist der Gründer des »GitHub Meetup Stuttgart« und einer der Organisatoren des »Azure Meetup Stuttgart«. Er ist regelmäßiger Sprecher auf nationalen und internationalen Konferenzen und publiziert in Fachzeitschriften und auf seinem Blog.

2019 wurde ihm die Auszeichnung »Regional Director« von Microsoft verliehen – eine Auszeichnung für Technologie-Visionäre, die sich durch technische Expertise, Einsatz in der Community und durch ihren Geschäftserfolg hervorgetan haben.

Danksagungen

Mein Dank gilt zuallererst meiner Frau und meinen Kindern Mael und Malena. Ein Buch neben der normalen Arbeit zu schreiben, bedarf viel Wochenend- und Nachtarbeit, und auch etliche Wochen Urlaub mussten dafür geopfert werden. Ich weiß es wirklich sehr zu schätzen, dass ihr mich bei solchen Dingen immer voll unterstützt.

Außerdem bedanke ich mich bei Andrea Baulig, die mich so geduldig durch den ganzen Schreibprozess begleitet hat und von der ich sehr viel lernen durfte. Vielen Dank!

Meinem Fachkorrektor Harald Binkle danke ich für die gute und kollaborative Zusammenarbeit und die vielen Anregungen, die er mir gegeben hat. Ein besonderer Dank gilt Florian Gänßlen, welcher mein Manuskript sehr gründlich gelesen hat und mir sehr wertvolles Feedback gegeben hat. Außerdem bedanke ich mich bei Benjamin Abt und Johannes Nicolai für ihre fachlichen Korrekturen und Ergänzungen: Dass ihr beide nicht mehr zu beanstanden hattet, hat mir ein gutes Gefühl gegeben. Ich danke euch allen für die fachliche und sprachliche Unterstützung!

Mein Dank gilt auch den Teams von Microsoft und GitHub, die ich über all die Jahre begleiten durfte und die so offen ihr Wissen und ihre Erfahrung mit mir geteilt haben, und natürlich meinen MVP-Kollegen und all den anderen ALM-Champs. Ich habe sehr viel von euch allen gelernt!

Inhaltsverzeichnis

Cover

Titelblatt

Impressum

Über den Autor

Einleitung

Über dieses Buch

Konventionen in diesem Buch

Was Sie nicht lesen müssen

Törichte Annahmen über die Leser

Wie dieses Buch aufgebaut ist

Symbole, die in diesem Buch verwendet werden

Wie es weitergeht

Teil I: Grundlagen

Kapitel 1: Was ist Git?

Versionsverwaltung – zentral oder verteilt?

Die Geschichte von Git

Was bedeutet der Name »Git«?

Lizenz und Betriebssysteme

Ausblick

Kurz und knackig

Kapitel 2: Der Einstieg auf Windows

Die Installation von Git auf Windows

Die richtige Kommandozeile

Der richtige Editor

Die Konfiguration von Git

Authentifizierung

Kurz und knackig

Kapitel 3: Der Einstieg auf macOS und Linux

Der Einstieg auf macOS

Der Einstieg auf Linux

Konfiguration

Authentifizierung

Arbeiten mit dem Terminal

Kurz und knackig

Kapitel 4: Hinzufügen, ändern, branchen und mergen

Das lokale Repository

Das Remote-Repository

Schritt für Schritt: Änderungen der Versionsverwaltung hinzufügen

Arbeiten mit Verzweigungen (Branches)

Änderungen zusammenführen

Schritt für Schritt: Branchen und Mergen

Kurz und knackig

Kapitel 5: Weitere Werkzeuge

Visual Studio Code

Benutzeroberflächen für Git

GitHub für unterwegs

Visual Studio, Eclipse, IntelliJ und Co.

Tools mit Windows-Explorer-Integration

Diff- und Merge-Tools

Kurz und knackig

Teil II: Zusammenarbeit

Kapitel 6: Git-Dienste

GitHub

Azure Repos

GitLab

Bitbucket

Kurz und knackig

Kapitel 7: Guidelines bei der Einführung von Git

Das richtige Maß an Governance

Eine minimale Governance-Richtlinie

Empfehlungen für Teams

Training

Kurz und knackig

Kapitel 8: Git-Workflows

Was sind Git-Workflows?

Trunk-Based-Development

GitHub-Flow

Release-Flow

Git-Flow

Den richtigen Workflow finden

Kurz und knackig

Kapitel 9: Teamwork mit Git

Watch, Stars und Forks

Was ist ein Fork?

Code-Reviews mit Pull-Requests

Branch-Protection

Automatisierung

Code-Owners

Der Umgang mit Commits und Messages

Der Pull-Request-Lebenszyklus

Kurz und knackig

Kapitel 10: Weniger Komplexität durch Feature-Flags

Was sind Feature-Flags?

Der Feature-Lebenszyklus

Weitere Einsatzmöglichkeiten von Feature-Flags

Wo fängt man an?

Frameworks

LaunchDarkly

Feature-Flags und technische Schulden

Kurz und knackig

Kapitel 11: Kontinuierlich bauen und ausliefern

Was ist CI und CD?

Build-Infrastruktur

Kontinuierliche Qualität

Automatisierte Deployments

Azure Pipelines

GitHub Actions

Weitere CI/CD-Plattformen

Kurz und knackig

Kapitel 12: Open-Source-Projekte

Geschichte

Open Source versus Open Development

Open Source und Sicherheit

Ihr erstes Open-Source-Projekt

Geld verdienen mit Open Source

Kurz und knackig

Teil III: Vertiefung

Kapitel 13: Unter der Haube

Warum ist Git so schwierig?

Der gerichtete azyklische Graph

Der Hash oder SHA-1

Die Anatomie eines Commits

Was ist denn nun eigentlich Git?

Warum ist Git so einfach?

Kurz und knackig

Kapitel 14: Zeitreisen mit Git

Geschichte ist Geschichte

Freie Wahl der Arbeitsweise

Änderungen rückgängig machen

Navigieren in der Zeit

Zeitlinien manipulieren

Die Vergangenheit interaktiv manipulieren

Die Vergangenheit mit Filter-Branch manipulieren

Manipulierte Zeitlinien mit Force-Push übertragen

Fragen Sie nicht, wozu Git fähig ist

Kurz und knackig

Kapitel 15: Mehr zum Branching und Merging

Branches und Tags

Vorspulen mit Fast-Forward

Ein echter Merge

Ein Octopus-Merge

Konflikte automatisch lösen

Konflikte manuell lösen

Merge-Strategien

Daten vom Remote laden mit git pull

Kurz und knackig

Kapitel 16: Commits und Tags signieren

Warum sollte man Commits signieren?

Was ist GPG?

Installation und Konfiguration

Der erste signierte Commit

Kurz und knackig

Kapitel 17: Git-Submodule

Submodule in Git-Repository einbinden

Submodule klonen

Submodule aktualisieren

In Submodulen arbeiten

Kurz und knackig

Kapitel 18: Große Dateien und große Repositories

Git-LFS

Große Repositories

Kurz und knackig

Kapitel 19: Git an Ihre Bedürfnisse anpassen

Dateien ignorieren

Arbeiten mit unterschiedlichen Dateitypen

Formatierung von Dateien

Kurz und knackig

Teil IV: Der Top-Ten-Teil

Kapitel 20: Zehn Tipps zum Einstieg in Git

Lernen und verwenden Sie Git auf der Konsole

Der richtige Git-Prompt

Richten Sie sich eine Wohlfühlkonsole ein

Lernen Sie die Shortcuts für Ihr Terminal

Lernen Sie einen Editor

Lernen Sie die Shortcuts für den Editor

Üben Sie in der Git-School

Erstellen Sie ein Konto auf GitHub

Verwenden Sie einen schlanken Workflow

Arbeiten Sie mit Pull-Requests

Kurz und knackig

Kapitel 21: Zehn Tipps zur Erhöhung der Effizienz

Arbeiten mit Aliasen in Git

Besser Vergleichen mit »diff-so-fancy«

Automatisieren mit Git-Hooks

Bessere Commit-Messages mit Commit-Templates

Einzelne Commits testen

Besser Versionieren mit Git-Version

Merges aufzeichnen mit rerere

Autokorrektur von Kommandos

Arbeit zwischenspeichern mit Stash

Kurz und knackig

Kapitel 22: Zehn Dinge, die Sie nicht tun sollten

Direkt auf dem Haupt-Branch arbeiten

Mit langlebigen Branches arbeiten

Passwörter und andere Secrets in Git speichern

Nicht oft genug committen

Git nicht als Versionsverwaltung nutzen

Große Dateien speichern

Einen Pull-Request für viele Änderungen verwenden

Einen Reset durchführen, ohne vorher zu speichern

Die veröffentlichte Historie modifizieren

Einen Force-Push durchführen

Kurz und knackig

Kapitel 23: Zehn Git-Befehle, die Sie kennen sollten

Bugs finden mit git bisect

Dateien umbenennen mit git mv und git rm

In Git suchen mit git grep und git log

Den Schuldigen finden mit git blame

Aufräumen mit git clean

Einen Brach wechseln mit git switch

Arbeiten mit Patches: git add ––patch und git apply

Kurz und knackig

Kapitel 24: Zehn Git-Befehle, die Ihnen bei Problemen helfen

Magische Zeitmaschine

Vergessen, Änderungen hinzuzufügen

Commit-Message nachträglich ändern

Aus Versehen auf den Haupt-Branch committed

Commit auf falschen Branch

Diff zeigt nichts an

Älteren Commit rückgängig machen

Änderungen an einer Datei rückgängig machen

Von Neuem beginnen (a)

Von Neuem beginnen (b)

Kurz und knackig

Stichwortverzeichnis

End User License Agreement

Tabellenverzeichnis

Kapitel 3

Tabelle 3.1: Tastenkürzel für das Arbeiten mit dem Terminal

Kapitel 6

Tabelle 6.1: On-Premises-Preise für Bitbucket

Kapitel 7

Tabelle 7.1: Mögliche Namenskonvention für Repositories

Kapitel 12

Tabelle 12.1: Übersicht über gängige Open-Source-Lizenzen

Illustrationsverzeichnis

Kapitel 1

Abbildung 1.1: Das heutige Git-Logo seit 2012

Abbildung 1.2: Versionsverwaltung von Dateien

Abbildung 1.3: Zentrale Versionsverwaltung

Abbildung 1.4: Verteilte Versionsverwaltung

Abbildung 1.5: Das originale Git-Logo von 2007

http://www.gnu.org/licenses/gpl.html

Kapitel 2

Abbildung 2.1: Lizenzvereinbarung

Abbildung 2.2: Auswahl der Komponenten

Abbildung 2.3: Windows-Explorer-Integration im Kontextmenü

Abbildung 2.4: Wahl des Standard-Editors

Abbildung 2.5: Setzen der PATH-Umgebungsvariable

Abbildung 2.6: HTTPS-Validierung

Abbildung 2.7: Umgang mit Zeilenenden

Abbildung 2.8: Terminal für die Git-Bash

Abbildung 2.9: Verhalten bei Git-Pull

Abbildung 2.10: Wahl des Git-Credential-Managers

Abbildung 2.11: Weitere Optionen

Abbildung 2.12: Experimentelle Optionen

Abbildung 2.13: PowerShell in Cmder

Abbildung 2.14: Grafische PowerShell mit »oh-my-posh«

Abbildung 2.15: Installation einer Linux-Distribution über den Microsoft-Store

Abbildung 2.16: Das Windows-Terminal

Abbildung 2.17: Visual Studio Code

Kapitel 3

Abbildung 3.1: Systemweiten Hotkey für iTerm2 festlegen

Abbildung 3.2: Markdown in Visual Studio Code ansehen

Abbildung 3.3: iTerm2 mit Oh-My-Zsh und Powerlevel10

Abbildung 3.4: Ubuntu mit Oh-My-Zsh und Powerlevel

Kapitel 4

Abbildung 4.1: Git-Spickzettel an vielen Monitoren

Abbildung 4.2: Den Systemordner von Git anzeigen

Abbildung 4.3: Das Klonen eines Remote-Repositorys

Abbildung 4.4: Änderungen dem lokalen Repository hinzufügen

Abbildung 4.5: Das lokale Repository aktualisieren

Abbildung 4.6: Eine neue Datei der Staging-Area hinzufügen

Abbildung 4.7: Änderungen hinzufügen und an das Remote-Repository übertragen

Abbildung 4.8: Vergleich zweier Dateiversionen mit »git diff«

Abbildung 4.9: Änderungen von Dateien anzeigen

Abbildung 4.10: Einen neuen Branch erstellen

Abbildung 4.11: Der neue Branch ist ein Pointer auf denselben Commit, auf den HEA...

Abbildung 4.12: Auf einen anderen Branch wechseln

Abbildung 4.13: Der HEAD zeigt nun auf den neuen Branch

Abbildung 4.14: Commit und Push im neuen Branch

Abbildung 4.15: Hinzufügen des neuen Branches zum Remote-Repository

Abbildung 4.16: Vergleich der Änderungen in beiden Branches

Abbildung 4.17: Konsolenausgabe beim Fast-Forward-Merge

Abbildung 4.18: Was beim Fast-Forward-Merge passiert

Abbildung 4.19: Änderungen in zwei Branches

Abbildung 4.20: Der Merge-Commit

Abbildung 4.21: Konflikte in einem Editor wie Visual Studio Code beheben

Kapitel 5

Abbildung 5.1: Git-Support in Visual Studio Code

Abbildung 5.2: Git-Statusbar in Visual Studio Code

Abbildung 5.3: Indikatoren für Änderungen in Textdateien

Abbildung 5.4: Visual-Studio-Code-Erweiterungen für Git

Abbildung 5.5: Git-History für ein Repository

Abbildung 5.6: Git-History für einzelne Dateien

Abbildung 5.7: Git-Lens in versionierten Dateien

Abbildung 5.8: Git-Lens mit weiteren Funktionen

Abbildung 5.9: Die Hit-History in Sourcetree

Abbildung 5.10: Sprache in Sourcetree umstellen

Abbildung 5.11: Die GitKraken-Übersicht

Abbildung 5.12: Merge-Konflike in Git-Kraken beheben

Abbildung 5.13: Der Verlauf in GitHub Desktop

Abbildung 5.14: Änderungen in GitHub Desktop als Commit speichern

Abbildung 5.15: Git-GUI in einem Repository

Abbildung 5.16: Visuelle Darstellung der Branches mit der Git-GUI

Abbildung 5.17: Die Git-GUI auf dem Mac

Abbildung 5.18: Git-Gui mit deutschem Menü

Abbildung 5.19: Git-GUI mit Menü auf Englisch

Abbildung 5.20: Startseite von GitHub für Mobile

Abbildung 5.21: Übersicht im dunklen Modus

Abbildung 5.22: Code-Reviews mit GitHub für Mobile

Abbildung 5.23: Code-Reviews im dunklen Modus

Abbildung 5.24: Merge-Konflikte in Visual Studio

Abbildung 5.25: Das TortoiseGit-Kontextmenü in einem Git-Repository

Abbildung 5.26: Das TortoiseGit-Kontextmenü für eine Datei in einem Git-Repositor...

Abbildung 5.27: Das Commit-Log von Git-Extensions

Abbildung 5.28: Der Änderungsverlauf einer Datei in Git-Extensions

Abbildung 5.29: Visual Studio Code als Diff-Tool

Abbildung 5.30: Einen Merge mit Code-Compare durchführen

Kapitel 6

Abbildung 6.1: Profildetails angeben

Abbildung 6.2: Readme für das Benutzerprofil erstellen

Abbildung 6.3: Fertiges GitHub-Profil mit Readme

Abbildung 6.4: Preise für Organisationen

Abbildung 6.5: Details für eine GitHub-Organisation eintragen

Abbildung 6.6: Ein neues Repository erstellen

Abbildung 6.7: Anlegen eines neuen Repositorys

Abbildung 6.8: Klonen eines Repositorys

Abbildung 6.9: Bei Azure DevOps registrieren

Abbildung 6.10: Erstellen einer Organisation in Azure DevOps

Abbildung 6.11: Ein neues Projekt erstellen

Abbildung 6.12: Azure-DevOps-Module auswählen

Abbildung 6.13: Das Default-Repository initialisieren

Abbildung 6.14: Ein neues Repository erstellen

Abbildung 6.15: Bei GitLab registrieren

Abbildung 6.16: Ein GitLab-Projekt erstellen

Abbildung 6.17: Passwort oder SSH-Key konfigurieren

Abbildung 6.18: Ein Repository von GitLab klonen

Abbildung 6.19: GitLab-Preise

Abbildung 6.20: Registrierung bei Bitbucket

Abbildung 6.21: Ein Repository bei Bitbucket erstellen

Abbildung 6.22: Ein Repository von Bitbucket klonen

Abbildung 6.23: Einen SSH-Key bei Bitbucket hochladen

Abbildung 6.24: Bitbucket-Preisübersicht

Kapitel 7

Abbildung 7.1: Aufbau eines Mono-Repos

Kapitel 8

Abbildung 8.1: Der GitHub-Flow

Abbildung 8.2: Der Release-Flow

Abbildung 8.3: Die Haupt-Branches in Git-Flow

Abbildung 8.4: Der Git-Flow

Kapitel 9

Abbildung 9.1: Stars und Forks des ASP.NET-Core-Repositorys

Abbildung 9.2: Arbeiten mit Forks

Abbildung 9.3: Markdown-Datei und deren Vorschau in Visual Studio Code

Abbildung 9.4: Ein neues Issue anlegen

Abbildung 9.5: Progress-Bar für eine Task-Liste

Abbildung 9.6: Einen Pull-Request erstellen

Abbildung 9.7: Beschreibung des Pull-Requests

Abbildung 9.8: Ein Merge-Konflikt im Pull-Request

Abbildung 9.9: Merge-Konflikt beheben

Abbildung 9.10: Pull-Request-Übersicht in GitHub

Abbildung 9.11: Änderungen in einer Datei anzeigen und nachverfolgen

Abbildung 9.12: Kommentar in einen Pull-Request einfügen

Abbildung 9.13: Einen Vorschlag in einen Pull-Request einbringen

Abbildung 9.14: Einen Vorschlag annehmen

Abbildung 9.15: Einen Review abschließen

Abbildung 9.16: Regeln für Reviewer

Abbildung 9.17: Regeln für Status-Checks

Abbildung 9.18: Erstellen einer Commit-Message in Visual Studio Code

Abbildung 9.19: Einen Pull-Request als Draft erstellen

Kapitel 10

Abbildung 10.1: Einsatz von Feature-Flags

Abbildung 10.2: Der Feature-Lebenszyklus

Abbildung 10.3: Arten von Feature-Flags

Kapitel 11

Abbildung 11.1: Continuous Integration (CI)

Abbildung 11.2: Continuous Delivery (CD)

Abbildung 11.3: Das Test-Portfolio beziehungsweise die »Test-Pyramide«

Abbildung 11.4: Einfaches Testbeispiel für die Code-Coverage

Abbildung 11.5: Code-Coverage-Ergebnis

Abbildung 11.6: Image-Layer eines Docker-Containers

Abbildung 11.7: Eine neue Pipeline in Azure erstellen

Abbildung 11.8: GitHub als Quelle auswählen

Abbildung 11.9: Repository auswählen

Abbildung 11.10: Das passende Template auswählen

Abbildung 11.11: Pipeline im YAML-Editor

Abbildung 11.12: Assistent für Test-Task (I)

Abbildung 11.13: Assistent für Test-Task (II)

Abbildung 11.14: Build-Pipeline-Übersicht

Abbildung 11.15: Einen Status-Badge für eine Build-Pipeline erstellen

Abbildung 11.16: Status-Badge konfigurieren

Abbildung 11.17: Der fertige Status-Badge in GitHub

Abbildung 11.18: Account in SonarCloud aufrufen

Abbildung 11.19: Ein Access-Token erstellen

Abbildung 11.20: Der Azure-DevOps-Marketplace

Abbildung 11.21: Eine neue Service Connection einrichten

Abbildung 11.22: Verbindung zu SonarCloud herstellen

Abbildung 11.23: SonarCloud-Task zu Pipeline hinzufügen

Abbildung 11.24: Projekt in SonarCloud ansehen

Abbildung 11.25: Quality-Gate-Badge in GitHub

Abbildung 11.26: Änderungen committen und Pull-Request in GitHub erstellen

Abbildung 11.27: Status-Check im Pull-Request

Abbildung 11.28: Issue in SonarCloud analysieren

Abbildung 11.29: Eine GitHub-Action erstellen

Abbildung 11.30: YAML-Editor der GitHub-Action

Kapitel 12

Abbildung 12.1: Alert-E-Mail von Dependabot

Abbildung 12.2: Automatisch von Dependabot erstellter Pull-Request zur Behebung e...

Kapitel 13

Abbildung 13.1: Comic von xkcd zu Git

Abbildung 13.2: Git als gerichteter Baum

Abbildung 13.3: Der gerichtete azyklische Graph

Abbildung 13.4: Der Inhalt des Ordners ».git«

Abbildung 13.5: Binärer Inhalt einer Datei in der Objektdatenbank

Abbildung 13.6: Die Datei wurde dem Staging-Bereich hinzugefügt.

Abbildung 13.7: Der Aufbau des Baums (»tree«)

Abbildung 13.8: Nähere Betrachtung eines Commits

Abbildung 13.9: Committer, Autor und Koautor bei Pull-Requests in GitHub

Abbildung 13.10: Ein manuell erstellter Commit wurde dem Branch hinzugefügt

Abbildung 13.11: Das Objekt-Modell eines Commits

Abbildung 13.12: Einen zweiten Commit hinzufügen

Abbildung 13.13: Das Objekt-Modell von Git

Abbildung 13.14: Änderungen an Dateien in Git

Abbildung 13.15: Paketieren von Dateien in Git

Kapitel 14

Abbildung 14.1: Verknüpfung von Commits über den SHA-1 des Parent-Commits

Abbildung 14.2: Pointer verschieben mit »git reset«

Abbildung 14.3: Harter Reset in Visual Studio Code

Abbildung 14.4: Weicher Reset in Visual Studio Code

Abbildung 14.5: Unterschiede zwischen den Argumenten »--soft«, »--mixed« und »--...

Abbildung 14.6: Verwaiste Commits bei Zeitreisen

Abbildung 14.7: Graph nach einem Merge

Abbildung 14.8: Über die Vorfahren navigieren

Abbildung 14.9: Git rebase visualisiert mit Git-School

Abbildung 14.10: »Git rebase« überträgt die Änderungen auf eine andere Basis

Abbildung 14.11: Konflikte beim Rebase

Abbildung 14.12: Ein Squash-Merge eines Branches

Abbildung 14.13: Ein interaktiver Rebase mit Stopp

Kapitel 15

Abbildung 15.1: Wechseln eines Branchs

Abbildung 15.2: Der Branch mit HEAD folgt neuen Commits

Abbildung 15.3: Bei Änderungen in mehreren Branches entstehen Verzweigungen

Abbildung 15.4: Commits bei einem ausgecheckten Tag landen im Nirgendwo

Abbildung 15.5: Der Fast-Forward-Merge

Abbildung 15.6: Ein Merge durch einen Merge-Commit

Abbildung 15.7: Ein Octopus-Merge

Abbildung 15.8: Die Git-History nach einem Octopus-Merge

Abbildung 15.9: Zwei Branches mit unterschiedlichen Änderungen an derselben Datei

Abbildung 15.10: Der Drei-Wege-Merge

Abbildung 15.11: Darstellung von Konflikten in einer Textdatei

Abbildung 15.12: Anzeige des Konflikts mit »diff3«

Abbildung 15.13: Die Änderungen mit »git log ––merge«

Kapitel 16

Abbildung 16.1: Ein signierter Commit in GitHub

Abbildung 16.2: Ein Commit von Linus Torvalds in meinem Repository?

Abbildung 16.3: Der Link im Commit zeigt auf das echte Profil

Abbildung 16.4: E-Mail-Einstellungen in GitHub

Abbildung 16.5: Den GPG-Schlüssel prüfen

Abbildung 16.6: Den öffentlichen GPG-Schlüssel in GitHub speichern

Abbildung 16.7: GPG-Konfiguration von Git in Visual Studio Code

Abbildung 16.8: Ein lokal signierter Commit

Kapitel 17

Abbildung 17.1: Submodule in ein Repository einbinden

Abbildung 17.2: Änderungen im Unterordner des Submoduls werden nicht nachverfolgt...

Abbildung 17.3: Darstellung eines Submoduls in GitHub

Abbildung 17.4: Ein Submodul mit »fetch« und »merge« aktualisieren

Abbildung 17.5: Status des Submoduls nach einem Fetch und Merge

Abbildung 17.6: Alle Submodule auf einmal aktualisieren

Abbildung 17.7: Arbeiten mit Submodulen

Kapitel 19

Abbildung 19.1: Der »ident«-Filter für Markdown-Dateien

Abbildung 19.2: Der »smudge«-Filter wird beim Auschecken der Dateien angewendet

Abbildung 19.3: Der »clean«-Filter wird beim Einchecken angewendet

Abbildung 19.4: Anzeige der gefundenen Formatierungsfehler mit »git diff«

Abbildung 19.5: Formatierungsfehler prüfen mit »git diff –check«

Kapitel 21

Abbildung 21.1: Standardmäßige Konsolenausgabe von »git diff«

Abbildung 21.2: Bessere Diff-Darstellung mit »diff-so-fancy«

Abbildung 21.3: GitVersion generiert Versionsnummern aus Git-Informationen

Abbildung 21.4: Aufzeichnung von Konflikten mit »git rerere«

Kapitel 23

Abbildung 23.1: Fehler mit »git bisect« suchen

Abbildung 23.2: Änderungen in einer Datei über mehrere Commits

Abbildung 23.3: Änderungen einer Funktion über den Verlauf der Zeit

Abbildung 23.4: Die Option »--patch« beim Hinzufügen in den Index

Orientierungspunkte

Cover

Inhaltsverzeichnis

Fangen Sie an zu lesen

Seitenliste

1

2

3

4

5

6

7

8

11

12

13

14

27

28

29

30

31

33

34

35

36

37

38

39

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

211

212

213

214

215

216

217

218

219

220

221

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

405

406

407

408

409

413

414

415

416

417

418

Einleitung

Ich freue mich sehr, mit Ihnen gemeinsam das Universum von Git zu erkunden. Ich erkläre dabei nicht nur die wichtigsten Befehle von Git, ich nehme Sie auch mit auf eine Reise in Open Source, DevOps und die Git-Workflows. Nach der Lektüre des Buches und vielen praktischen Übungen können Sie sicher mit Git umgehen und wissen, wie man im Team effektiv damit zusammenarbeitet. Es wird für Sie dann auch möglich sein, Beiträge zu Open-Source-Projekten zu leisten oder Ihr eigenes Projekt zu starten. Ich wünsche Ihnen viel Spaß beim Eintauchen in dieses spannende Thema.

Über dieses Buch

Ich gebe in diesem Buch eine sehr praxisorientierte Einführung in Git – mit vielen Beispielen zum Ausprobieren und Tipps aus der Praxis. Das Buch ist also kein Nachschlagewerk, das alle Optionen von Git erläutert. Es ist auch kein Theoriewerk über die Funktionsweise von Git. Es ist ein praktischer Einstieg, der Sie mit allem ausrüstet, um danach in bestimmte Themen tiefer einsteigen zu können.

Git ist ein sehr umfangreiches und mächtiges Werkzeug, welches man vielfältig in den unterschiedlichsten Szenarien einsetzen kann. Aber nur weil man etwas tun kann, heißt das noch nicht, dass man es auch tun soll. Ich fokussiere mich deshalb immer auf die Dinge, die in der Praxis gut funktionieren und Komplexität reduzieren, statt sie zu erhöhen.

Konventionen in diesem Buch

In diesem Buch finden Sie sehr viele Befehle, die über eine Kommandozeile einzugeben sind. Befehlen ist immer ein Dollarzeichen ($) vorangestellt. Vor einer Ausgabe, die von einem Programm auf der Konsole ausgegeben wird, steht immer ein Größerzeichen (>).

$ git status

> On branch main> Your branch is up to date with 'origin/main'.>> nothing to commit, working tree clean

Manchmal finden Sie in diesen Teilen kursive Begriffe. In diesem Fall handelt es sich immer um Platzhalter, die Sie durch einen konkreten Wert ersetzen müssen, in nachfolgendem Beispiel durch Ihren Benutzernamen.

$ git clone https://github.com/benutzername/CodingDojo.git

Ansonsten sind kursive Begriffe immer Fachbegriffe, die das erste Mal in diesem Kontext verwendet werden.

Tauchen Befehle im laufenden Text auf, dann sind diese anders formatiert, wie zum Beispiel git status.

Menüeinträge sind immer in KAPITäLCHEN gesetzt. Tasten und Tastenkombinationen werden wie folgt dargestellt: oder +.

Pfadangaben im Fließtext werden wie Befehle formatiert: C:\Ordner\Ordner\Datei.txt oder /home/Ordner/Datei.txt. Relative Pfade werden immer mit dem Schrägstrich geschrieben (./Ordner/Datei.txt), außer, sie beziehen sich explizit auf ein Betriebssystem. Wenn Sie also in der PowerShell die Beispiele ausprobieren, dann müssen Sie stattdessen die Windows Syntax (.\Ordner\Datei.txt) verwenden.

Webadressen sind in diesem Buch immer wie folgt formatiert: https://writeabout.net

Fachbegriffe

Ich verwende in diesem Buch fast immer die englischen Originalbegriffe, nachdem ich sie einmal am Anfang des Kapitels erklärt habe, weil auf der Kommandozeile auch alle Befehle in englischer Sprache eingegeben werden müssen. Außerdem ist es bei der Dokumentation oder der Fehlersuche auch hilfreich, wenn man das englische Original kennt. Das Verstehen der übersetzten Begriffe in anderen Anwendungen sollte weniger Probleme bereiten als das Erraten des englischen Begriffs, wenn man ihn nur auf Deutsch gelernt hat.

Warum Kommandozeile?

Git ist ein Kommandozeilen-Programm. Deshalb lernt man es am besten auch auf der Kommandozeile. Natürlich gibt es zahlreiche Tools, welche eine Benutzeroberfläche für Git anbieten. Aber wenn man ein Problem hat und nach einer Lösung sucht, dann findet man meistens nur Lösungen für die Kommandozeile. Der Vorteil der Kommandozeile ist auch, dass das Interface sehr konstant bleibt und sich kaum ändert. In Kapitel 5 stelle ich einige grafische Anwendungen und ihre Git-Integration vor, ansonsten verwende ich immer die Kommandozeile.

Der Name für den Haupt-Branch

Der Name für die Verzweigung (Branch), der allen anderen Branches zugrunde liegt, war bei Git seit jeher master. In der #blacklivesmatter-Bewegung im Jahr 2020 gab es zu Recht Kritik an diesem Namen, da er an die Sklaverei erinnert. Da es sich bei diesem Namen nur um eine Konvention handelt, spielt es keine Rolle, wie er lautet. Der Branch kann genauso gut trunk (Stamm) oder main (Haupt) genannt werden.

Aus Rücksicht auf Menschen, die durch diesen Namen an schlimme Zeiten unserer Geschichte erinnert werden, werde ich den Haupt-Branch in diesem Buch main nennen. Wenn Sie also in einem anderen Tutorial oder in einer anderen Dokumentation die Bezeichnung master für einen Branch finden, dann wissen Sie, dass dieser Branch meinem main entspricht. Technisch hat der Name keine Auswirkungen, er ist nur eine Konvention.

Was Sie nicht lesen müssen

Die Teile und Kapitel dieses Buchs bauen thematisch aufeinander auf: von den Grundlagen über die Zusammenarbeit im Git-Universum bis zu den Vertiefungsthemen. Trotzdem ist das Buch so modular aufgebaut, dass Sie jedes Kapitel auch für sich lesen können. Wenn Sie schon Erfahrung mit Git haben, dann können Sie zum Beispiel einige Kapitel der Grundlagen überspringen. Dennoch empfehle ich Ihnen, gerade diese Kapitel zumindest querzulesen. Vielleicht findet sich ja doch noch der eine oder andere Tipp, den Sie noch nicht kennen.

Wenn Sie den Techniker sehen – den jungen Mann mit Brille –, dann erkläre ich Ihnen einen technischen Hintergrund. Manche Leser finden gerade das spannend, andere wollen sich bei der ersten Lektüre nicht damit befassen oder kennen den Hintergrund bereits. Sie können diese Passage bei Bedarf getrost überspringen. Sie ist eher für den Blick über den Tellerrand gedacht und für den weiteren Verlauf nicht unbedingt nötig.

Der erhobene Zeigefinger zeigt, dass ich einen Inhalt wiederhole, der an einer anderen Stelle schon behandelt wurde. Sie müssen den Text also nicht lesen, wenn Sie das andere Kapitel gelesen haben.

Törichte Annahmen über die Leser

Dieses Buch ist für Menschen gedacht, welche gemeinsam im Team Software erstellen und betreiben, also nicht nur für Entwickler oder gar Berufseinsteiger, die sich neu mit dem Thema befassen. Es ist genauso geeignet für Entwickler mit vielen Jahren Erfahrung in anderen Versionsverwaltungen, die jetzt einen Umstieg zu Git machen.

In Büchern der »… für Dummies«-Reihe werden anspruchsvolle Themen verständlich präsentiert, ohne dass vom Leser übertrieben viel Vorwissen erwartet wird. Diesen bewährten Weg schlage ich auch in diesem Buch ein.

Trotzdem gehe ich davon aus, dass Sie sich mit dem von Ihnen verwendeten Betriebssystem auskennen – egal, ob Windows, Linux oder macOS.

An der einen oder anderen Stelle des Buches taucht auch etwas Quellcode auf. Das ist bei einer Quellcode-Verwaltung nicht ganz zu vermeiden. Die dazugehörigen Beispiele sind dann möglichst simpel gewählt: entweder in JavaScript oder C#. Da die meisten Leser Entwickler sein werden, sollte dies kein Problem darstellen. Aber selbst ohne Programmierkenntnisse dürften diese Abschnitte kein Problem für das Verständnis des Buches sein.

Wie dieses Buch aufgebaut ist

Dieses Buch ist in vier Teile gegliedert:

Teil I: Grundlagen

In Teil I lernen Sie die Grundlagen kennen. Ich erkläre, was Git ist, wie es funktioniert und wie man es installiert. Darüber hinaus erkläre ich Ihnen alles, was Sie für einen Einstieg auf Windows, Mac oder Linux benötigen und welche Dinge Sie installieren und einrichten müssen. Sie machen Ihre ersten praktischen Übungen und lernen die Grundlagen und wichtigsten Befehle kennen. Außerdem stelle ich in diesem Teil grafische Anwendungen vor, die Ihnen das Leben einfacher machen werden.

Teil II: Zusammenarbeit

In Teil II geht es um die effektive Zusammenarbeit mit anderen Entwicklern. Ich gebe Ihnen in diesem Teil eine Einführung in die vier wichtigsten Git-Systeme für die Zusammenarbeit. Darüber hinaus lernen Sie, was Sie bei der Arbeit im Team beachten müssen und welche Richtlinien Sie einhalten sollten. Insbesondere Git-Workflows – also die genauen Arbeitsabläufe von Git in einem Team – werde ich detailliert erklären. Sie werden lernen, wie Sie mit Pull-Requests zusammenarbeiten und wie Sie Beiträge zu Open-Source-Projekten auf GitHub leisten können.

Teil III: Vertiefung

In Teil III werden ich bestimmte Themen vertiefen. Ich werde Ihnen genau zeigen, wie Git unter der Haube funktioniert. Sie werden die unterschiedlichen Merge-Strategien lernen, den Umgang mit Tags, Git-Hooks und signierten Commits.

Teil: IV: Der Top-Ten-Teil

Teil IV ist der Tipps-&-Tricks-Teil. Ich zeige Ihnen in Form von nützlichen Listen, wie Sie sich das Leben mit Git leichter machen können.

Symbole, die in diesem Buch verwendet werden

Im Buch finden Sie die folgenden Symbole. Einige kennen Sie ja schon, wenn Sie diese Einleitung gelesen haben.

Die Glühbirne kennzeichnet einen Tipp für die Praxis. Wann immer sie auftaucht, sollten Sie besonders aufmerksam lesen!

Achtung heißt es hier. Unter diesem Symbol erfahren Sie, was Sie lieber lassen sollten oder wann Sie sehr vorsichtig vorgehen sollten.

Mit der Lupe erkläre ich Ihnen einen Fachbegriff, der das erste Mal auftaucht.

Manchmal erzähle ich eine Anekdote aus meinem Berufsleben, die Sie vielleicht interessant finden. Sie ist aber nicht für den weiteren Verlauf nötig. Wenn Sie die Sprechblase sehen, dann können Sie den Absatz überspringen, falls die Anekdote Sie nicht interessiert. Aber wer wäre nicht an einer guten Geschichte interessiert?

Die Weltkugel weist auf weitere Informationen im Internet hin.

Manchmal nehme ich Dinge vorweg, da sie im aktuellen Kontext wichtig sind. Das Fernglas kennzeichnet immer einen Ausblick auf ein Thema, das in einem der nachfolgenden Kapitel genauer erklärt wird.

Wie oben bereits erwähnt wurde, erkläre ich Ihnen bei diesem Symbol den technischen Hintergrund einer Sache. Wenn Sie der Inhalt interessiert, dann lesen Sie den Text. Ansonsten machen Sie einfach weiter. Der Abschnitt ist nicht zwingend nötig, um im Buch weiterzukommen.

Auch dieses Symbol haben Sie schon kennengelernt. Wenn Sie den erhobenen Finger sehen, dann wiederhole ich einen Inhalt, der an einer anderen Stelle schon behandelt wurde.

Wie es weitergeht

Und jetzt wünsche ich Ihnen viel Spaß bei dem Einstieg in die spannende Welt der Git-Versionsverwaltung, und zwar nicht nur beim Lesen, sondern auch beim Ausprobieren!

Teil I

Grundlagen

IN DIESEM TEIL …

Was ist Git?Der Einstieg auf WindowsDer Einstieg auf macOS und LinuxHinzufügen, ändern, branchen und mergenWeitere Werkzeuge

Kapitel 1

Was ist Git?

IN DIESEM KAPITEL

Was ist Git?Die Geschichte von GitWas bedeutet der Name »Git«?Lizenz und BetriebssystemeAusblick

Git ist bei Weitem die am häufigsten eingesetzte Versionsverwaltung weltweit, und der Abstand zu den anderen Produkten wird mit jedem Jahr größer. Die Zahl von Softwarelösungen steigt und steigt: Smart-Cities, Smart-Products, Autos, Straßenlaternen und Küchenmaschinen … Neben dem klassischen Personal Computer und dem Smartphone werden immer mehr digitale Produkte auf den Markt gebracht, und jedes dieser Produkte basiert auf Software, deren Quellcode mit großer Wahrscheinlichkeit in einem Git-Repository liegt!

Git ist also für Entwickler das, was der Hammer für die Zimmerleute ist: ein alltägliches Werkzeug, bei dem ein effizienter und sicherer Umgang eine Selbstverständlichkeit ist.

Aber was ist denn nun dieses Git?

Git – das aktuelle Logo ist in Abbildung 1.1 zu sehen – ist eine Software zur verteilten Versionsverwaltung.

Abbildung 1.1: Das heutige Git-Logo seit 2012

Quelle: https://git-scm.com/downloads/logos Copyright: Jason Long / CC BY 3.0

Versionsverwaltung – zentral oder verteilt?

Eine Versionsverwaltung ist ein System zur Erfassung von Änderungen an Dateien. Alle Versionen werden gespeichert und können später wiederhergestellt werden. Im Unterschied zu Dokumentenmanagementsystemen, in denen Versionen nur für einzelne Dateien gelten, können sich Versionen bei Versionsverwaltungen auf mehrere Dateien beziehen (siehe Abbildung 1.2). Änderungen an mehreren Dateien werden also zu Versionen zusammengefasst und gespeichert. Die Versionen können einzeln wiederhergestellt werden.

Abbildung 1.2: Versionsverwaltung von Dateien

Systeme zur Versionsverwaltung lassen sich in zwei Kategorien einteilen: zentral und dezentral.

Bei einer zentralen Versionsverwaltung werden die Änderungen in einem zentralen Speicher – dem sogenannten Repository – abgelegt und von dort von allen Clients abgerufen. Das Abrufen der Dateien nennt man auch Checkout. Nach dem Bearbeiten werden die Änderungen dann wieder in das zentrale Repository übertragen. Dies nennt man auch Checkin (siehe Abbildung 1.3).

Abbildung 1.3: Zentrale Versionsverwaltung

Bei zentralen Repositories kann die Datei beim Checkout für andere Benutzer gesperrt werden. Dies verhindert, dass in der Zwischenzeit ein anderer Benutzer dieselbe Datei ändert. Werden Dateien nicht gesperrt, dann kann in der Zeit, in der ein Benutzer eine Datei lokal bearbeitet, ein anderer Benutzer seine Änderungen an derselben Datei im zentralen Repository speichern. In diesem Falle entsteht ein Konflikt beim späterem Checkin der Datei des ersten Benutzers. Dieser muss dann vom Benutzer vor dem Checkin gelöst werden, indem er die Änderungen erst zusammenführt – das sogenannte Mergen. Egal, für welche der beiden Optionen man sich entscheidet – sperren oder nicht sperren –, man benötigt zum Arbeiten mit der Versionsverwaltung immer eine Verbindung zum zentralen Repository. Es ist nicht möglich, offline mit Versionen zu arbeiten.

Im Gegensatz dazu werden bei einer verteilten Versionsverwaltung alle Versionen in einem lokalen Repository gespeichert. Ein Benutzer kann also komplett autark mit der Versionsverwaltung arbeiten. Die Änderungen können dann mit anderen Repositories synchronisiert werden (siehe Abbildung 1.4).

Abbildung 1.4: Verteilte Versionsverwaltung

Natürlich heißt das nicht, dass jeder Client sein Repository mit allen anderen Clients synchronisiert. Auch bei einer verteilten Versionsverwaltung sollte man ein zentrales Repository haben, mit dem alle Clients regelmäßig synchronisieren. Das zentrale Repository ist auch das, von dem sich neue Clients eine Kopie laden, um zu arbeiten, oder von dem Release-Stände für Software erstellt werden.

Um bei einem Hardwarefehler keinen Datenverlust zu erleiden, sollte möglichst regelmäßig mit diesem zentralen Repository synchronisiert werden. Alle lokalen Änderungen gingen sonst verloren.

Das zentrale Repository ist aber bei einer verteilten Versionsverwaltung nur eine Konvention. Prinzipiell kann ein Repository mit jedem beliebigen Repository synchronisiert werden.

Die Geschichte von Git

Git wurde 2005 von Linus Torvalds – dem Initiator des Linux-Kernels – ins Leben gerufen. Dies geschah nach einer Lizenzänderung von BitKeeper, einem proprietären Programm zur Versionsverwaltung, das bis dahin für die Entwicklung des Linux-Kernels genutzt wurde. Durch die Änderung konnte BitKeeper nicht weiter kostenlos für die Entwicklung verwendet werden, und so entschied sich Linus Torvalds im April 2005 sein eigenes Programm zur Versionsverwaltung zu entwickeln.

Die drei Hauptanforderungen, die das Programm erfüllen sollte, waren folgende:

verteilte Arbeitsabläufe,

Sicherheit,

Effizienz.

Es gab bereits ein existierendes Projekt namens Monotone, das die ersten beiden Kriterien erfüllte – das dritte jedoch nicht. Deshalb entschied sich Linus Torvalds, ein eigenes, neues Projekt zu erstellen. Er verwendete Ideen und Konzepte aus BitKeeper und Monotone, jedoch keinen Quellcode.

Das erste Logo von Git (siehe Abbildung 1.5) wurde im April 2007 veröffentlicht und erst 2012 durch das heutige Logo ersetzt.

Abbildung 1.5: Das originale Git-Logo von 2007 http://www.gnu.org/licenses/gpl.html

Quelle: https://commons.wikimedia.org/wiki/File:Git-logo-2007.svg Copyright: Git / GPL

Was bedeutet der Name »Git«?

Das Wort »Git« stammt aus dem britischen Englisch und bedeutet umgangssprachlich »Blödmann«, »Depp« oder »Idiot«. Linus Torvalds erklärte die Wahl des Namens folgendermaßen:

Ich bin ein egoistischer Mistkerl, und ich benenne all meine Projekte nach mir: zuerst »Linux«, jetzt eben »Git«.

Das war aber nur ein Witz. In Wirklichkeit fiel die Wahl auf das Wort, da es folgende Eigenschaften aufwies:

Es ist kurz.

Es ist einfach auszusprechen.

Es ist einfach auf einer Standardtastatur zu schreiben.

Es wurde bis dahin noch nicht verwendet.

Der Name Linux wurde anfangs nicht von Torvalds selbst propagiert und nur sehr widerwillig von ihm akzeptiert!

Lizenz und Betriebssysteme

Git ist eine freie Software und unter der GNU General Public License, Version 2, verfügbar. Der Quellcode liegt auf GitHub und jeder, der möchte, kann sich an dem Projekt beteiligen. Git ist also auch kostenlos verfügbar.

Es gibt eigentlich kein Betriebssystem, auf dem Git nicht eingesetzt werden kann. Es gibt eine Version für Linux, Windows, macOS, Solaris und andere Unix-Betriebssysteme.

Ausblick

Git hat sich am Markt der Versionsverwaltungen durchgesetzt. Sein Einsatzgebiet reicht weit über das einer reinen Quellcode-Verwaltung hinaus. Zwar gibt es noch einige Nischenprodukte, doch zeigt sich bei den Tools zur Versionsverwaltung eine klare Konsolidierung. Git ist gekommen, um zu bleiben. Gerade dass keine Firma mit kommerziellem Interesse dahintersteckt, ist ein großer Vorteil von Git. Firmen müssen keine Angst davor haben, sich von einer anderen Firma abhängig zu machen.

Wenn es also eine Quellcode-Verwaltung gibt, mit der Sie sich heute in der Tiefe auseinandersetzen sollten, dann ist das Git. Die aufgewendete Zeit ist eine sichere Investition in die Zukunft.