Git – kurz & gut E-Book

Nina Siessegger

• Herausgeber: O'Reilly
• Kategorie: Wissenschaft und neue Technologien
• Serie: kurz & gut
• Sprache: Deutsch
• Veröffentlichungsjahr: 2024

Seitenzahl: 177

Beschreibung

Das Versionierungstool Git verstehen und typische Aufgaben des Programmieralltags lösen - Verständliche Einführung in das beliebte Versionierungswerkzeug; v.a. für Einsteiger*innen und Entwickler*innen, die Git von Zeit zu Zeit nutzen - Wesentliche Begriffe und Arbeitsschritte kompakt erklärt - Praxistipps für den Programmieralltag - Neu in der 2. Auflage: Weitere Workflows, Anleitungen zu GitHub und GitLab sowie Einblicke, wie Git intern funktioniertWer heute Software entwickelt, kommt um Git nicht herum, denn Git hat sich als Werkzeug zur Versionskontrolle durchgesetzt. Es ist ein mächtiges Tool, gilt aber nicht gerade als intuitiv. Dieser Kompakteinstieg unterstützt bei den ersten Schritten mit Git und erklärt praxisnah alles Wesentliche — ob es darum geht, eigene Projekte zu versionieren, an Open-Source-Software mitzuarbeiten oder im Team zu entwickeln. Verständlich bringt das Taschenbuch zentrale Begriffe, technische Konzepte, gängige Workflows und das notwendige Wissen für den Programmieralltag auf den Punkt. Darüber hinaus inspiriert es durch Good Practices und wertvolle Tipps. Aus dem Inhalt - Versionskontrolle und die technischen Konzepte von Git - Git installieren und konfigurieren - Mit Git arbeiten: typische Arbeitsschritte und Workflows - Git-Onlinedienste wie GitHub, GitLab u.a. - Good Practices für den Programmieralltag - Häufige Fehler und Probleme - Fortgeschrittenere Kommandos, Tipps und Tricks - Git als Baustein moderner und agiler Softwareentwicklung - Git unter der Haube: die Funktionsweise von Git besser verstehen

Leseprobe

Copyright und Urheberrechte:

Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

2., erweiterte Auflage

Git

kurz & gut

Nina Siessegger

Nina Siessegger

Lektorat: Ariane Hesse

Fachliche Unterstützung: Tim Adler, Merle Baake, Julia Barthel, Daniel Grünthal, Anke Lederer

Korrektorat: Sibylle Feldmann, www.richtiger-text.de

Satz: III-satz, www.drei-satz.de

Herstellung: Stefanie Weidner

Umschlaggestaltung: Karen Montgomery, Michael Oréal, www.oreal.de

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

ISBN:

Print

978-3-96009-224-7

PDF

978-3-96010-828-3

ePub

978-3-96010-829-0

2., erweiterte Auflage 2024Copyright © 2024 dpunkt.verlag GmbHWieblinger Weg 1769123 Heidelberg

Dieses Buch erscheint in Kooperation mit O’Reilly Media, Inc. unter dem Imprint »O’Reilly«. O’Reilly ist ein Markenzeichen und eine eingetragene Marke von O’Reilly Media, Inc. und wird mit Einwilligung des Eigentümers verwendet.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen. Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen. Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autorin noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

Inhalt

Einleitung

1Grundlegende Konzepte

Was ist Versionskontrolle, und warum brauche ich sie?

Die Grundlagen von Git

2Git installieren und konfigurieren

Installation

Git konfigurieren

3Arbeiten mit Git

Hilfe finden

Das Git-Repository

Dateien ignorieren und von der Versionierung ausschließen

Commits erstellen

Änderungen synchronisieren

Mit Branches arbeiten

Änderungen zusammenführen

Änderungen temporär speichern

Änderungen nachvollziehen und betrachten

Änderungen rückgängig machen

4Git-Onlinedienste

Die Relevanz von GitHub

Ein Repository auf GitHub anlegen

Pull-Requests

Issues: Projektmanagement und Bug-Reports

Git-Onlinedienste in Unternehmen

5Typische Git-Workflows

Trunk-based: ausschließlich im Haupt-Branch arbeiten

Git-Feature-Branch-Workflow

Gitflow: der Workflow für versionierte Software

Durch den Fork-basierten Workflow zu Open-Source-Projekten beitragen

6Good Practices

Gute Commits

Geschichte nur im Notfall neu schreiben

Den Überblick über Branches behalten

Regelmäßig aufräumen

Entwicklungsstränge häufig zusammenführen und Konflikten nicht aus dem Weg gehen

Langlebige Feature-Branches vermeiden

7Häufige Fehler und Probleme

Lokaler Stand und Remote-Stand weichen voneinander ab

Detached-HEAD-Fehlermeldung

Du hast im falschen Branch gearbeitet

Git-Diff zeigt keine Änderungen an

Keine Tracking-Information für den aktuellen Branch vorhanden

Git weigert sich, unzusammenhängende Historien zusammenzuführen

8Fortgeschrittenere Kommandos, Tipps und Tricks

Im Reflog merkt sich Git fast alles

Kürzel für Git-Befehle erstellen

Pre- und Post-Commit-Hooks

9Git als Baustein moderner und agiler Softwareentwicklung

DevOps-Kultur

Kontinuierlich integrieren und ausliefern mit Git

Infrastructure as Code

10Git unter der Haube

Git-Objekte und das Datenmodell

Packdateien

Der Index

Referenzen

Was sich sonst noch im versteckten .git-Ordner befindet

Branches und Merges

Fazit

11Die wichtigsten Kommandos zum Nachschlagen

12Glossar

Index

Einleitung

Wer heute professionell Software entwickelt, nutzt Git, das sich als Standardwerkzeug etabliert hat. Das Tool ermöglicht Versionskontrolle und erleichtert kollaboratives Arbeiten an Softwareprojekten. Vorher gängige Alternativen wie Subversion oder Mercurial hat Git weitgehend verdrängt. Entwickelt wurde Git 2005 von den Entwicklerinnen und Entwicklern des Linux-Kernels als Versionsverwaltung für ihr eigenes Projekt.

Warum hat sich Git durchgesetzt? Das liegt zum einen an der dezentralen Architektur von Git und der Möglichkeit, Änderungen lokal und offline durchzuführen und sie erst anschließend mit anderen zu teilen. Zum anderen hat Git das kollaborative Arbeiten erleichtert. Das Konzept von Branches gab es zwar bereits zuvor, Git hat aber die Möglichkeit, an parallelen Entwicklungssträngen unabhängig voneinander zu arbeiten und sie später wieder zusammenzuführen, enorm vereinfacht.

Ein wichtiger Faktor ist sicher auch das Aufkommen von Git-Onlinediensten wie z.B. GitHub, GitLab oder Bitbucket. Diese Services nutzen im Kern die Funktionalität von Git und erweitern diese um einige nützliche Dinge. So erleichtern sie die Zusammenarbeit in Teams durch die Einführung von Konzepten wie Pull-Requests. Diese erlauben es, Änderungsvorschläge für den Haupt-Branch zu machen und diese Änderungen von anderen im Rahmen eines Code-Reviews überprüfen zu lassen. Außerdem sind die Weboberflächen dieser Dienste für viele sicher ein Pluspunkt, denn so wird der Zugang deutlich niedrigschwelliger. Git selbst funktioniert ausschließlich auf der Kommandozeile. Es gibt jedoch auch eine große Zahl an grafischen Oberflächen.

Es lässt sich festhalten: Wer heute Software entwickelt, kommt um Git nicht herum. Der Einstieg kann jedoch eine Herausforderung sein, denn Git ist ein mächtiges Tool. Dieses Buch soll allen, die gerade ihre ersten Schritte in der Softwareentwicklung oder mit Git machen, den Anfang erleichtern. Es bietet eine schnelle Einführung in die Verwendung und Funktionsweise von Git und kann gleichzeitig als nützliches Nachschlagewerk dienen.

In Kapitel 1 geht es zunächst um die grundlegenden Konzepte von Git. Anschließend machen wir uns an die praktische Arbeit mit Git und schauen uns die gängigen Kommandos an. Ich gehe davon aus, dass die meisten von euch Git als kollaboratives Tool einsetzen und über einen Onlinedienst wie GitHub mit anderen zusammenarbeiten wollen. Deshalb widmet sich das Kapitel 4 den Grundlagen von Git-Onlinediensten. Sowohl Git als auch die Onlinedienste können auf unterschiedliche Weise verwendet werden. Jedes Projekt und jedes Team sollte sich deshalb auf einen Workflow bei der Zusammenarbeit mit Git einigen. Das Kapitel 5, »Typische Git-Workflows«, stellt die gängigen Varianten vor. Besonders am Herzen liegt mir das Kapitel 6, »Good Practices«, es versammelt Tipps und Empfehlungen für die Arbeit mit Git. Ein Tool wie Git bietet viele Möglichkeiten – im Laufe der letzten Jahre haben sich einige Praktiken herauskristallisiert und bewährt.

Im Kapitel 7, »Häufige Fehler und Probleme«, schauen wir uns stets wiederkehrende Fehlermeldungen an und natürlich Strategien, mit diesen Problemen umzugehen. Im Anschluss geht es um fortgeschrittenere Konfigurationen, Kommandos und Tools. Im Kapitel 9, »Git als Baustein moderner und agiler Softwareentwicklung«, geht es um die Frage, was DevOps sowie Continuous Integration und Delivery sind und was das im Zusammenhang mit Git praktisch bedeuten kann. Gegen Ende des Buchs, in Kapitel 10, »Git unter der Haube«, schauen wir uns an, wie Git intern funktioniert.

Als ich meine ersten Schritte mit Git machte, rauchte mir der Kopf. Viele Begriffe waren neu, und ich habe eine Weile gebraucht, bis ich ins Thema hineingefunden hatte. Ich vermute, einigen von euch geht es ähnlich. Aus diesem Grund gibt es am Ende des Buchs ein Glossar, in dem du die wichtigsten Begriffe nachschlagen kannst.

Sind die Grundlagen verstanden, kann der Band als Nachschlagewerk dienen und munter quergelesen werden.

Ich setze voraus, dass du die Kommandozeile benutzen kannst. Für Git gibt es zwar verschiedene grafische Oberflächen, diese können aber nur einen Bruchteil des Funktionsumfangs abbilden. Hinzu kommt, dass sich die Dokumentation, die zahlreichen Tutorials im Netz und auch die Fragen und Antworten bei Stack Overflow in aller Regel auf die Kommandozeile beziehen. Daher empfehle ich, bei der Arbeit mit Git auf jeden Fall in die Kommandozeile einzusteigen.

Dieses Buch erhebt keinerlei Anspruch auf Vollständigkeit, es umfasst all jene Kommandos, die die meisten Entwicklerinnen und Entwickler benötigen werden, um im Arbeitsalltag klarzukommen. Wer ein umfassenderes Werk sucht, dem sei das Buch »Git: Dezentrale Versionsverwaltung im Team – Grundlagen und Workflows« von René Preißel und Bjørn Stachmann (dpunkt.verlag) ans Herz gelegt.

In diesem Buch genutzte Konventionen

Die folgenden typografischen Konventionen werden in diesem Buch genutzt:

Kursiv

Für neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen.

Nichtproportionalschrift

Für Codebeispiele, Ausgaben, aber auch für Befehle o.Ä. im Fließtext.

Dieses Symbol steht für einen Hinweis oder Tipp.

Dieses Symbol steht für eine Warnung.

Danksagung

Auf die Idee, ein Buch zu schreiben, wäre ich alleine nicht gekommen. Deshalb möchte ich mich zuallererst ganz herzlich bei meiner Lektorin Ariane Hesse bedanken, die mich erst auf den Gedanken gebracht hat. Daneben hat mich Ariane durch den Schreibprozess mit vielen Tipps, Anregungen und ganz viel konstruktivem Feedback begleitet.

Allein hätte ich dieses Buch auch nicht schreiben können. Pablo Zimdahl hat mit mir die erste Fassung der Gliederung diskutiert und wichtige Hinweise und Denkanstöße gegeben. Eine große Hilfe waren mir die Reviews von Anke Lederer, Daniel Grünthal, Julia Barthel und Merle Baake. Christoph Lohse hat das Manuskript gelesen und mich auch in Zeiten, in denen ich so gar nicht mehr schreiben wollte, unterstützt und motiviert. Ein großes Dankeschön euch allen dafür, dass ihr euch die Zeit genommen habt und mich so konstruktiv unterstützt habt.

Ein herzliches Dankeschön gilt aber auch all den Kolleginnen und Kollegen, die mir beim Einstieg in Git geholfen haben, mit denen ich mir im Laufe der letzten Jahre die Haare über Merge-Konflikte gerauft habe und mit denen ich tolle Git-Features entdeckt habe. Und last, but not least gebührt all denjenigen Dank, die dieses wunderbare Tool entwickeln.

Danksagung zur zweiten Auflage

Zuerst möchte ich mich ganz herzlich bei Tim Adler bedanken, der mir nicht nur Feedback zu den Texten gegeben hat, sondern auch weite Teile des Abschnitts »Git-Onlinedienste in Unternehmen« auf Seite 102 beigesteuert hat.

Wertvolles Feedback haben mir außerdem Lisa Junger, Christoph Klünter, Martin Wohlrab und Christoph Lohse gegeben. Vielen Dank! Und natürlich geht ein großes Dankeschön an die aufmerksamen Leser und Leserinnen, die mir Rückmeldungen und Hinweise zur ersten Ausgabe gegeben haben. Ariane Hesse hat auch die Arbeit an der zweiten Auflage als Lektorin begleitet. Ihr gilt ebenfalls mein Dank.

Verwendete Git-Version

Für die aktualisierte Auflage habe ich die Git-Version 2.42.0 verwendet. Grundsätzlich hat sich seit der letzten Auflage bezüglich der Funktionalität nicht wahnsinnig viel getan. Es sind ein paar neue Optionen hinzugekommen, und an einigen Stellen haben sich die Konsolenausgaben geändert. Ich habe versucht, die Änderungen im gesamten Text zu berücksichtigen.

Es gibt ebenfalls eine deutsche Lokalisierung von Git, d.h., die Konsolenausgaben können auch auf Deutsch angezeigt werden. Ich persönlich verwende die englischsprachige Ausgabe von Git, und diese wird auch in diesem Buch für Beispiele verwendet. Meiner Erfahrung nach ist dies gerade in Problemfällen hilfreich. Viele hilfreiche Beiträge sind online auch nur auf Englisch verfügbar, und die Verwendung der englischen Git-Ausgabemeldungen erleichtert die Suche ungemein.

KAPITEL 1

Grundlegende Konzepte

Was ist Versionskontrolle, und warum brauche ich sie?

Wie der Name bereits deutlich macht, geht es bei der Versionskontrolle darum, unterschiedliche Versionen von Projekten oder Dateien zu verwalten. Das Hinzufügen, Ändern oder Löschen von Inhalten muss dafür mitprotokolliert und festgehalten werden.

Diese Anforderung lässt sich an einem einfachen Beispiel illustrieren. Nehmen wir an, Alice schreibt ein Programm und schickt die Datei an Bob. Der wiederum nimmt einige Änderungen vor und schickt die Datei zurück an Alice – zusammen mit Erläuterungen zu seinen Änderungen. Und so geht das eine Weile hin und her.

Abbildung 1-1: Einfache Versionskontrolle durch Dateinamen

Ähnliche selbst gestrickte Systeme zur Versionskontrolle haben vermutlich die meisten von uns schon einmal benutzt. Diese Variante hat jedoch ein paar Nachteile: Sie funktioniert nur mit einer begrenzten Zahl von Menschen, Absprachen sind erforderlich, und irgendwann wird es unübersichtlich. Außerdem ist es schwer nachzuvollziehen, wer was geändert hat und vor allem mit welcher Motivation. Auch der Vergleich zweier Entwicklungsversionen ist kaum möglich.

Versionskontrollsysteme – auf Englisch Version Control Systems (VCS) – gestalten diese Abläufe systematisch und effizient. Sie erlauben Teams, gemeinsam an Dateien oder ganzen Projekten zu arbeiten und Änderungen transparent nachzuvollziehen. Gerade bei großen Projekten mit einer Laufzeit von mehreren Jahren ist diese Nachvollziehbarkeit elementar. Sie erleichtert das Verständnis von Code und dokumentiert Entscheidungen für eine bestimmte Lösung oder Implementierung. Selbst für eine einzelne Person kann Versionskontrolle wahnsinnig nützlich sein. So nutze ich die Versionskontrolle auch gern für mein künftiges Ich. Häufig habe ich einige Monate, nachdem ich ein Stück Code geschrieben habe, nicht mehr alle Details vor Augen und ziehe dann die Historie zurate. Oder ich habe einen Fehler gemacht und möchte ein bestimmtes Set von Änderungen rückgängig machen. Hier ist Versionskontrolle meine Rettung.

Die Tools der ersten Generation zur Versionskontrolle konnten Änderungen an einzelnen Dateien verfolgen, und Dateien konnten jeweils nur von einer Benutzerin lokal bearbeitet werden. Sie basierten auf der Annahme, dass sich alle Benutzer mit ihrem eigenen Konto bei demselben gemeinsamen Unix-Host anmelden würden.

Die zweite Generation waren zentralisierte Systeme zur Versionskontrolle – ein Beispiel hierfür ist Subversion. Sie brachten Vernetzung und zentrale Repositories. Nun war es mehreren Nutzerinnen und Nutzern möglich, den Code gleichzeitig auszuchecken und zu bearbeiten, wobei sie jedoch alle im zentralen Repository arbeiteten. Um Code zu bearbeiten und Änderungen vorzunehmen, musste sich eine Entwicklerin über einen Client mit dem Server verbinden. Dieser Ansatz hat den entscheidenden Nachteil, dass die Arbeit komplett lahmgelegt ist, sobald es Netzwerkprobleme gibt oder der Server nicht verfügbar ist.

Die dritte Generation sind die dezentralen Systeme, von denen Git inzwischen der bekannteste Vertreter ist. In einem verteilten VCS sind alle Kopien des Repositorys gleichgestellt – es gibt keine zentrale Kopie des Repositorys. Dies öffnet den Weg für Commits, Branches und Merges, die lokal ohne Netzwerkzugang erstellt und bei Bedarf an andere Repositories weitergegeben werden können. Dieser Punkt ist besonders für Menschen, die vorher mit zentralisierten Systemen gearbeitet haben, zunächst verwirrend. Bei Git müssen Änderungen immer erst an den Server geschickt – gepusht – werden, um für alle verfügbar zu sein. Durch diese Architektur ist Git sehr schnell und zuverlässig. Es erlaubt, auch ohne permanente Netzwerkverbindung zu arbeiten, bei einem Serverausfall kann weitergearbeitet werden, und es gibt nicht nur eine zentrale Kopie, sondern immer mehrere »Sicherungskopien«. Schließlich hat jede Person, die mit einem über Git verwalteten Projekt arbeitet, eine komplette Kopie des Codes auf ihrer Festplatte.

Die Grundlagen von Git

Im Folgenden schauen wir uns an, auf welchen Konzepten Git basiert. Wie werden Änderungen gespeichert, und was ist eigentlich ein Repository oder ein Commit? Ein Verständnis dieser Grundlagen ist die Basis für die Nutzung von Git in der Praxis.

Aus Schnappschüssen wird Geschichte gemacht

Die Kernfunktion von Git besteht darin, nachvollziehbar zu machen, was von wem und zu welchem Zeitpunkt geändert wurde. Um Änderungen nachzuvollziehen, speichert Git Schnappschüsse, in denen der aktuelle Stand des gesamten Projektverzeichnisses zu einem bestimmten Zeitpunkt festgehalten wird. Ein solcher Schnappschuss wird immer dann erstellt, wenn du Git ein Paket mit Änderungen übergibst. Diese Pakete werden Commits genannt, und wir schauen sie uns gleich noch genauer an.

Selbst wenn es sich dabei nur um eine kleine Änderung handelt, wird die gesamte neue Version der Datei gespeichert. Das heißt, es wird nicht nur das Delta, also die Differenz zwischen zwei Versionen gespeichert, sondern immer wieder auch der aktuelle Stand des Projektverzeichnisses. Dieses Prinzip kostet natürlich Platz auf der Festplatte. Git geht mit dem Speicherplatz aber sehr effizient um. Wenn eine Datei unverändert bleibt, wird ein Verweis auf die bereits vorhandene Datei – auch Blob genannt – erstellt. Diese Art, Dateien und Änderungen zu verwalten, unterscheidet Git von fast allen anderen Versionskontrollsystemen. Die folgende Grafik illustriert dieses Prinzip.

Abbildung 1-2: Wie Git mit veränderten und unveränderten Dateien in Schnappschüssen umgeht

Das Git-Repository

Das Git-Repository ist der Dreh- und Angelpunkt allen Arbeitens mit Git. Im Prinzip ist es ein einfacher Ordner. Dieser enthält alle Projektdateien – also den zu verwaltenden Code selbst – sowie einen versteckten Ordner .git. In Letzterem befinden sich alle internen Verwaltungsdaten, die Git erstellt. Das sind z.B. alle Änderungen, alle Branches und alle Commit-Nachrichten.

Im versteckten .git-Ordner stöbern

Es lohnt sich, einmal in dem versteckten .git-Ordner zu stöbern und sich anzuschauen, welche Verwaltungsdaten Git darin ablegt. Gehe einfach in ein Git-Repository und schau dich innerhalb des Ordners um: ls -l .git.

Im Unterverzeichnis objects befinden sich die Objekte, die Git erstellt hat, also z.B. Commits. Im Kapitel 10, »Git unter der Haube«, schauen wir uns den versteckten .git-Ordner genauer an.

$ ls -l .git

total 64

drwxr-xr-x 14 sssggr staff 448 Nov 25 09:19 .

drwxr-xr-x 14 sssggr staff 448 Oct 23 14:57 ..

-rw-r--r-- 1 sssggr staff 9 Oct 29 15:36 COMMIT_EDITMSG

-rw-r--r-- 1 sssggr staff 105 Nov 25 09:15 FETCH_HEAD

-rw-r--r-- 1 sssggr staff 21 Oct 10 09:35 HEAD

-rw-r--r-- 1 sssggr staff 41 Oct 10 09:05 ORIG_HEAD

-rw-r--r-- 1 sssggr staff 319 Aug 2 17:00 config

drwxr-xr-x 10 sssggr staff 320 Apr 2 2021 hooks

-rw-r--r-- 1 sssggr staff 5059 Oct 29 15:36 index

drwxr-xr-x 3 sssggr staff 96 Apr 2 2021 info

drwxr-xr-x 4 sssggr staff 128 Apr 2 2021 logs

drwxr-xr-x 253 sssggr staff 8096 Nov 25 09:15 objects

-rw-r--r-- 1 sssggr staff 46 Oct 10 09:35 packed-refs

drwxr-xr-x 5 sssggr staff 160 Oct 10 09:07 refs

Ein Repository kann lokal auf einem Computer liegen, Git kann aber auch auf einem Server installiert werden. In der Theorie der dezentralen Architektur sind alle Repositories gleichwertig, und Änderungen lassen sich auch von jedem Repository auf ein anderes Repository übertragen. In der Praxis einigen sich Teams oder Mitarbeitende an Open-Source-Projekten jedoch darauf, ein Repository als zentral zu definieren. Sonst ist schlicht und einfach unklar, in welchem Repository sich der gerade gültige Stand befindet. Das zentrale Repository unterscheidet sich in keiner Weise von den anderen Repositories. Die Definition als zentral ist lediglich eine Vereinbarung im Entwicklungsteam, das sich, wie in der folgenden Grafik dargestellt, darauf geeinigt hat, keine Synchronisation zwischen ihren persönlichen Repositories per push und pull durchzuführen, sondern immer den Weg über das zentrale Repository zu gehen.

Abbildung 1-3: Theoretisch könnten Bob und Alice auch Änderungen zwischen den beiden Repositories auf ihren Computern austauschen. Sie haben sich aber darauf verständigt, ein bei GitHub gehostetes Repository als zentrales Repository zu definieren.

Dieses zentrale oder geteilte Repository liegt häufig auf einem Server oder bei einem Git-Onlineservice wie GitHub oder GitLab, sodass alle jederzeit darauf Zugriff haben. Es bildet immer den aktuellen Stand des Projekts ab. Aus dem zentralen Repository laden Teammitglieder den aktuellen Code mithilfe des Befehls pull herunter. Änderungen, die mit dem Team geteilt werden sollen, müssen über das push-Kommando hochgeladen werden.

Commits: Änderungspakete schnüren

Wie kommen Änderungen in das Repository? Änderungsschritte werden in Commits zusammengefasst und so dem Repository hinzugefügt. Das Erstellen eines Commits ist ein mehrstufiger Prozess und lässt sich gut mit dem Packen und Versenden eines Pakets illustrieren. Wenn du ein Paket verschicken möchtest, überlegst du dir zunächst, was in das Paket hineinkommen soll. Dann wird es gepackt und verschnürt. Im nächsten Schritt wird es mit Empfängerin und Absender versehen. Da wir ins Ausland versenden, erhält es außerdem eine Inhaltsbeschreibung für den Zoll. Anschließend bringst du das Paket zur Post, die es der Empfängerin zustellt.

Abbildung 1-4: Das Erstellen eines Commits lässt sich mit dem Packen und Versenden eines Pakets vergleichen.

Dein Projektverzeichnis ist der Tisch, auf dem du dein Paket packst. Du hast auf deinem Rechner an deinem Code gearbeitet und Dateien verändert. Deine Änderungen befinden sich nun in deinem Arbeitsverzeichnis lokal auf deinem Rechner. Im nächsten Schritt musst du überlegen, welche der Änderungen in deinem Commit-Paket landen sollen. Diese Änderungen fügst du dem Staging- bzw. Indexbereich hinzu, d.h., du merkst sie für den nächsten Commit vor. In unserer Paketanalogie befinden sich deine Änderungen nun in einem offenen Paket. Im nächsten Schritt erstellst du den Commit. Der Commit lässt sich mit dem Adresslabel und der Inhaltsbeschreibung für den Zoll bei einem Paket vergleichen. Mit dem Commit wird ein Schnappschuss des Repositorys erstellt. Der Commit enthält außerdem die Information darüber, wer die Änderung durchgeführt hat, sowie eine Commit-Nachricht, in der die Änderungen zusammenfassend beschrieben sind. Wie dein Paket liegt der Commit jetzt bei dir zu Hause herum. Arbeitest du mit anderen zusammen, musst du den Commit nun noch in das zentrale Repository bei GitHub, einem anderen Onlinedienst oder auf einen Server hochladen, sodass andere sich die Änderungen herunterladen können. Mit diesem Schritt bringst du dein Paket also zur Post.

Mit einem Commit wird eine Momentaufnahme vom Zustand des Repositorys erstellt. In dieser Momentaufnahme wird der Inhalt jeder Datei so gespeichert, wie er sich zum Zeitpunkt des Commits im Repository darstellt. Darüber hinaus enthält ein Commit einige Metadaten:

vorangegangene Commit(s),

Autor*innen und/oder Committer und ihre E-Mail-Adressen,

eine Commit-Message, also eine Beschreibung der Änderungen,

den Zeitstempel sowie

den Hash-Wert, der den Commit eindeutig erkennbar macht und dafür sorgt, dass Inhalte nicht manipuliert werden können.

Mithilfe der Liste der Commits lassen sich die Entwicklungsschritte eines Projekts nachvollziehen. Alle können sehen, wer wann was geändert hat. Idealerweise verrät mir die Commit-Nachricht außerdem, warum die Änderung erfolgt ist.

Prüfsummen sorgen für Integrität

Git sorgt dafür, dass Änderungen nachvollzogen werden können. Damit das zuverlässig funktioniert, ist es wichtig, dass Daten nicht nachträglich manipuliert und verändert werden können. Dies wird durch Prüfsummen gewährleistet. Legt Git ein Objekt an, z.B. einen Commit, wird eine Prüfsumme generiert.

commit a315762ac84a2a6c7159c35494a89d647d6c1e44 (HEAD -> main)

# Prüfsumme

Author: Nina Siessegger <[email protected]>

Date: Sun Jul 4 17:14:18 2021 +0200

Add README

Die Prüfsumme des Commits wird später dafür genutzt, den Commit wieder aufzufinden. Im Kern ist Git ein Key-Value-Store, also eine Datenbank mit zwei Spalten. In der einen Spalte findet sich der Wert – im Fall von Git kann dieser Wert jede Art von Inhalt sein –, in der zweiten Spalte befindet sich ein eindeutiges Identifikationsmerkmal. Das ist im Fall von Git die berechnete Prüfsumme.

Schwerer Abschied vom veralteten SHA-1-Hash

Git verwendet derzeit per Default den Secure Hash Algorithm 1