Git wurde ursprünglich erfunden, um den Linux-Kernel zu entwickeln. Die Softwareplattform wird hauptsächlich von Entwicklern zu Collaboration-Zwecken verwendet.
Git - Definition
Im Kern verfolgt das Versionskontrollsystem Git Änderungen an Dateien und ermöglicht es mehreren Benutzern, Aktualisierungen an diesen Dateien zu koordinieren. Der gängigste Anwendungsfall für Git: mehrere Entwickler, die an Quellcode-Dateien arbeiten. Darüber hinaus kann Git aber auch genutzt werden, um Dateiaktualisierungen jeder Art zu managen, ist der Versionskontrollstandard für GitHub und andere Source-Code-Management-Systeme und wird im Rahmen von DevOps-Initiativen häufig verwendet, um CI/CD zu implementieren.
Git ist keine Programmiersprache - für Softwareentwickler allerdings ähnlich wichtig geworden, weil es den heutigen De-Facto-Standard für Versionskontrollsoftware darstellt. Programmierer verwenden sie, um:
Aktualisierungen innerhalb großer Codebasen nachzuverfolgen,
bei Bedarf auf frühere Versionen zurückzugreifen und
Einblick in alle vorgenommenen Änderungen zu bekommen und die Personen zu identifizieren, die sie vorgenommen haben.
Git ist zudem integraler Bestandteil der agilen Softwareentwicklung geworden und ein zentrales Merkmal von GitOps, das den DevOps-Ansatz auf Container-basierte Systeme erweitert.
Git - Historie
Git wurde von Linus Torvalds, seines Zeichens Erfinder von Linux, im Jahr 2005 entwickelt, um das Management der Linux-Kernel-Entwicklung zu erleichtern. Torvalds war damals mit vielen anderen Versionskontrollsystemen unzufrieden und wollte auch nicht auf proprietäre Lösungen wie BitKeeper zurückgreifen. Was die Nomenklatur angeht, lieferte Torvalds verschiedene Erklärungsansätze.
Da Git als Open-Source-Alternative zu bestehender Versionskontrollsoftware entwickelt wurde, wird die Softwareplattform auch nicht von einzelnen Person oder Entitäten kontrolliert. Einige Monate nach der Gründung übergab Torvalds die Wartungsaufgaben an Junio Hamano, der bis zu diesem Zeitpunkt einer der wichtigsten Git-Kontributoren war und auch noch heute hauptverantwortlich für die Wartung ist, auch wenn er inzwischen für Google arbeitet.
Git vs. GitHub
Git bietet verteilte Versionskontrollfunktionen. Sie können die Plattform verwenden, um Ihre eigenen privaten Programmierarbeiten auf Ihrem Rechner zu verwalten - in der Regel kommt Git aber - wie eingangs erwähnt - für kollaborative Zwecke zum Einsatz. Bei solchen Projekten liegt die kanonische Version des Quellcodes irgendwo auf einem Server (in der Git-Sprache ein zentrales Repository) während die Benutzer Aktualisierungen down- und uploaden können.
Mit Git können Sie Ihren eigenen Rechner auch in ein zentrales Repository verwandeln. Es gibt jedoch auch diverse Dienstleister, die kommerzielle Git-Hosting-Dienste offerieren. Der mit Abstand bekannteste dieser Services (der auch eine Vielzahl weiterer Funktionen bietet) heißt GitHub, wurde 2008 gegründet und im Jahr 2018 von Microsoft übernommen. Das Wichtigste dazu in aller Kürze: GitHub ist zwar für die Entwicklung mit Git konzipiert - um Git zu nutzen, müssen Sie aber nicht GitHub verwenden. Mehr zum Thema GitHub erfahren Sie bei unserer US-Schwesterpublikation InfoWorld.
Versionskontrolle mit Git - Grundlagen
Ein vollständiges Git-Tutorial würde den Rahmen dieses Artikels sprengen. Aber wir werfen einen Blick auf die wichtigsten Konzepte und Terminologien, um Ihnen den Einstieg zu erleichtern.
Git-Repository
Wir haben das Konzept des Repositorys bereits erwähnt. Es handeln sich um den konzeptionellen Raum, in dem sich alle Teile Ihres Projekts befinden. Wenn Sie alleine an einem Projekt arbeiten, benötigen Sie wahrscheinlich nur ihr eigenes Repository, während Sie bei einem Gemeinschaftsprojekt wahrscheinlich mit einem zentralen Repository arbeiten werden. Dieses zentrale Repository wird auf einem Server oder bei einem Anbieter wie GitHub gehostet. Das eigene Repository haben Entwickler dagegen auf ihren eigenen Rechnern.
Ein Git-Repository ist in zwei Bereiche unterteilt: Es gibt einen Staging-Bereich, um Dateien hinzuzufügen und zu entfernen, und die Commit History. Commits sind das Herzstück von Git.
Git-Commit
Einen Commit kann man sich am besten als Snapshot vorstellen, der den Status eines Projekts zu einem bestimmten Zeitpunkt abbildet. Wenn Sie mit den Dateien, die Sie in Ihrem Staging-Bereich abgelegt haben, zufrieden sind, geben Sie den Befehl git commit
aus, der den aktuellen Zustand dieser Dateien für die Zukunft festhält. Sie können weitere Änderungen und neue Commits vornehmen, dabei aber jederzeit zu früheren zurückkehren. Um einen schnellen Überblick über die Änderungen im Projekt zu erhalten, können Sie auch verschiedene Commits miteinander vergleichen.
Wichtig ist dabei, dass ein Git-Commit nichts damit zu tun hat, Code in die Produktion zu überführen. Mit einem Commit wird eine Version Ihrer Anwendung erstellt, mit der Sie beispielsweise testen und experimentieren können. Mit Hilfe von Commits können Entwicklungsteams Applikationen schnell und iterativ in einen produktionsfähigen Zustand bringen.
Git Stash
Auch wenn Commits rückgängig gemacht werden können, stellen sie doch ein gewisses Maß an Commitment dar. Wenn Sie an Dateien im Staging-Bereich arbeiten und zu etwas anderem übergehen möchten, ohne Ihre Änderungen tatsächlich zu übertragen, können Sie sie mit dem Befehl Git Stash
speichern, um sie später zu verwenden.
Git Branch und Git Merge
Bis jetzt haben Sie sich Commits wahrscheinlich als eine lineare Reihe von Code-Snapshots vorgestellt, die sich im Laufe der Zeit weiterentwickeln. Was Git jedoch zum mächtigen Werkzeug macht, ist die Fähigkeit, damit parallel an verschiedenen Versionen Ihrer Anwendung arbeiten zu können. Das wiederum ist für eine agile Softwareentwicklung essenziell.
Um Git-Branches und -Merging praktisch verstehen zu können, stellen Sie sich vor, Sie haben eine Anwendung namens CoolApp mit der Version 1.0 in Produktion. Sie arbeiten ständig an CoolApp 2.0, mit allerlei interessanten neuen Funktionen, die Sie in Form einer Reihe von Commits in Ihrem Repository entwickeln. Aber dann finden Sie heraus, dass CoolApp 1.0 eine ernsthafte Sicherheitslücke beinhaltet, die sofort gepatcht werden muss. Sie können nun zu Ihrem Commit von CoolApp 1.0 zurückkehren, patchen und diesen Code als CoolApp 1.1 in die Produktion überführen. Und zwar ohne dabei die Commits, die zu CoolApp 2.0 führen (und immer noch 1.0 als "Elternteil" haben), durcheinanderzubringen oder ergänzen zu müssen. Die Versionen 1.1 und 2.0 befinden sich nun in getrennten Zweigen (Branches) Ihrer Codebasis. Da Version 1.1 in Produktion ist, während 2.0 noch in Entwicklung ist, wird 1.1 zum Main Branch.
Sobald CoolApp 2.0 einsatzbereit ist, müssen Sie den neuen Code und die neuen Funktionen mit dem Sicherheitsupdate von Version 1.1 kombinieren. Dieser Prozess, das Zusammenführen der beiden Branches, ist essenzieller Teil der "Magie" von Git. Die Plattform versucht, einen neuen Commit aus zwei verschiedenen "Elternteilen" zu erstellen - genauer gesagt aus den jüngsten Commits der beiden Branches. Dazu vergleicht sie die jeweiligen Vorgänger bis zu dem Punkt, an dem sich die Branches getrennt haben und überführt alle Änderungen in einen neuen, konsolidierten Commit. Wenn dabei bestimmte Informationen - beispielsweise ein bestimmter Codeblock - in beiden Branches auf unterschiedliche Art und Weise verändert wurde, gibt Git die Frage, welche Version in den neuen Commit gehört, an den Entwickler zurück.
Git-Checkout
Viele große Projekte haben mehrere aktive Branches, die parallel entwickelt werden. Mit dem Befehl git checkout
können Sie Änderungen an dem Branch vornehmen, an dem Sie gerade arbeiten. Dieser Vorgang aktualisiert die Dateien im Arbeitsverzeichnis auf die neueste Version des betreffenden Branches. Alle neuen Commits werden dann auf diesen Branch übertragen, bis Sie einen anderen auschecken.
Collaboration mit Git - Grundlagen
Da Git vor allem als Collaboration-Werkzeug gedacht ist, beschäftigen wir uns im Folgenden damit, wie Git-Konzepte in kollaborativen Kontexten funktionieren.
Git Clone
Der einfachste Weg, mit anderen an einem Projekt zusammenzuarbeiten, besteht darin, ein Repository, das bereits auf einem anderen Computer existiert, zu klonen. Dabei wird der gesamte Repository-Inhalt in ein Repository auf dem eigenen Rechner heruntergeladen.
Es ist üblich, dass Projekte ein zentrales Repository, das auf GitHub oder anderswo gehostet wird, als die kanonische "Source of Truth" betrachten, wenn es darum geht, wie die Codebasis eines Projekts aussieht. Darüber, welches Repository das zentrale ist, bestimmt nicht Git, sondern die Projektteilnehmer. Theoretisch ist es auch möglich, dass verschiedene Repositories Code austauschen, ohne dass eines davon zentral ist.
Git Pull und Git Push
Wir haben beschrieben, wie Git zwei Branches mit Commits auf demselben Rechner abgleichen kann. Das geht auch mit zwei Branches auf verschiedenen Rechnern, wobei im Grunde dieselbe Technik angewendet wird.
Der Vorgang, bei dem ein Branch zwischen zwei Rechnern verschoben wird, wird als Pull oder Push bezeichnet - je nachdem, wie er initiiert wird. Wenn Sie einen Branch von einem Remote Server auf Ihren Rechner bringen, handelt es sich um einen Pull-Vorgang. Wenn Sie einen Branch von Ihrem Rechner an einen anderen senden, handelt es sich um einen Push-Vorgang.
Git Pull Request
Ihren Code auf einen anderen Rechner zu übertragen - oder auf das zentrale Repository, von dem das gesamte Projekt abhängt - kann unter Umständen ein wenig "pushy" erscheinen. Ein gängigeres Szenario bei der kollaborativen Entwicklung mit Git, ist der Pull Request. Nehmen wir an, Sie haben den Code für eine neue Funktion fertiggestellt und möchten diesen in die Codebasis Ihres Projekts integrieren. Sie stellen eine Pull-Anfrage, mit der Sie die Projektmanager formell bitten, Ihren neuen Code in das zentrale Repository zu übertragen.
Der Pull Request gibt den Projektmanagern nicht nur die Möglichkeit, Ihren Beitrag anzunehmen oder abzulehnen, er schafft auch ein Mini-Diskussionsforum im zentralen Repository, in dem sich alle Projektmitglieder zu der Anfrage äußern können. Das ermöglicht Entwicklern, Änderungen an der Codebasis eines Projekts zu diskutieren. Insbesondere bei Open-Source-Projekten ist die Funktion zentral, weil die Mitwirkenden häufig vor allem über Git interagieren.
Git Fork
Ein Branch ist als vorübergehende Abweichung von der Haupt-Codebasis gedacht, die am Ende wieder in diese integriert wird. Eine Fork stellt hingegen eine dauerhafte Abweichung dar.
Zu einer Fork kommt es (insbesondere bei Open-Source-Projekten), wenn ein Entwickler beschließt, eine bestehende Open-Source-Codebasis zu übernehmen und sie für seine eigenen Ziele weiterzuentwickeln, die sich möglicherweise von denen der Projektverantwortlichen unterscheiden. Eine solche Abspaltung gestaltet sich mit GitHub besonders einfach: Ein Klick genügt, um ein bestehendes Repository zu klonen und es - unter Ihren eigenen Bedingungen - zu bearbeiten.
Git - unter Windows
Die Struktur und Befehlssyntax von Git sind sehr stark an Unix angelehnt. Auf Unix-ähnlichen Betriebssystemen wie Linux und macOS läuft die Softwareplattform also mehr oder weniger nativ. Git auf Windows zu portieren, ist etwas schwieriger und erfordert Git bash, einen Bourne-Shell-Emulator, der Teil von Git for Windows ist.
GUI- und IDE-Integration
Viele Windows-Entwickler sind es gewohnt, eine grafische Benutzeroberfläche zu verwenden. Deshalb enthält auch Git for Windows eine solche. Auch macOS- und Linux-Benutzer müssen sich nicht ausgeschlossen fühlen: Für sie steht ebenfalls eine Vielzahl grafischer Benutzeroberflächen zur Auswahl.
Darüber hinaus können Sie Git auch in Ihre bevorzugten IDEs integrieren, darunter Eclipse und Microsoft Visual Studio.
Git - Tutorial
Wenn Sie nach tiefgehendem Wissen über die Verwendung von Git und Git-Befehlen dürsten, empfehlen wir für den Anfang das umfassende und leicht verständliche Tutorial von Atlassian. Dabei sollten Sie im Hinterkopf behalten, dass Atlassian dieses Tutorial in Kooperation mit Bitbucket, dem Hauptkonkurrenten von GitHub, zur Verfügung stellt. Nichtsdestotrotz bietet es eine hervorragende Einführung in die Grundlagen von Git.
Weitere Ressourcen zum Thema:
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.