Die Versionskontrolle Git wurde für die Entwicklung des Linux-Kernels erfunden und wird heute in Millionen von Projekten auf der ganzen Welt eingesetzt. [...]
Git ist eine Softwareplattform, die hauptsächlich von Computerprogrammierern für die Zusammenarbeit genutzt wird. Im Kern verfolgt Git Änderungen an Dateien und ermöglicht es mehreren Benutzern, Aktualisierungen an diesen Dateien zu koordinieren. Der häufigste Anwendungsfall für Git sind Entwickler, die an Quellcodedateien arbeiten, aber es kann auch für die Verwaltung von Aktualisierungen an Dateien aller Art verwendet werden.
Git ist auch der Versionskontrollstandard für GitHub und andere Quellcodeverwaltungssysteme und wird im Rahmen von Devops häufig zur Implementierung von CI/CD verwendet. Für Entwickler, die ihre Anwendungen auf Kubernetes oder anderen Cloud-nativen Plattformen bereitstellen und verwalten, bietet GitOps Best Practices für die Arbeit mit containerisierten Clustern und Anwendungen.
Ist Git eine Programmiersprache?
Git ist keine Programmiersprache, aber es ist für Computerprogrammierer, die in fast jeder Sprache arbeiten, unglaublich wichtig geworden. Git ist heute der De-facto-Standard für Software zur Versionskontrolle. Programmierer verwenden Versionskontrolle, um Aktualisierungen großer Codebasen zu verfolgen, bei Bedarf auf frühere Versionen zurückzugreifen und alle vorgenommenen Änderungen sowie die Personen, die sie vorgenommen haben, zu sehen. Sie ist zu einem integralen Bestandteil der agilen Softwareentwicklung geworden und ist ein zentrales Merkmal von GitOps, das die agile Devops-Philosophie auf Container-basierte Systeme ausweitet
Warum heißt es Git?
Der Name von Git ist eng mit seiner Geschichte verbunden. Git wurde von jemandem entwickelt, dessen Namen Sie mit Sicherheit kennen: Linus Torvalds, der Erfinder von Linux. Git wurde 2005 speziell dafür geschaffen, die Entwicklung des Linux-Kernels zu verwalten. Torvalds war damals mit vielen anderen Versionskontrollsystemen unzufrieden, und BitKeeper, das von einigen Kernel-Entwicklern bevorzugt wurde, war nicht Open-Source. (Es zeugt von Torvalds‘ Einfluss auf die Computerbranche, dass eine Softwareplattform, die so allgegenwärtig ist wie Git, nur sein zweitgrößter Ruhm ist)
Als die erste Version von Git auf den Markt kam, bot Torvalds frech eine Reihe von Erklärungen für den Namen an. Die wahrscheinlichste Erklärung ist, dass Git eine Kombination aus drei Buchstaben ist, die leicht auszusprechen war und nicht bereits von einem anderen Unix-Befehl verwendet wurde. Das Wort klingt auch wie get-relevant, weil man mit Git Quellcode von einem Server abrufen kann. Das Wort Git ist auch ein mildes Schimpfwort im britischen Englisch – relevant, wenn man sich über eine Software ärgert.
Wer ist der Eigentümer von Git?
Wie bereits erwähnt, wurde Git speziell als Open-Source-Alternative zu bestehender Versionskontrollsoftware entwickelt, was bedeutet, dass es von keiner einzelnen Person oder Organisation kontrolliert wird. Einige Monate nach der Gründung übergab Torvalds die Wartungsaufgaben an Junio Hamano, der bis zu diesem Zeitpunkt einen wichtigen Beitrag zum Projekt geleistet hatte. Hamano, der jetzt für Google arbeitet, ist auch heute noch der Hauptverantwortliche für Git.
Git vs. GitHub
Git bietet verteilte Versionskontrollfunktionen. Sie können Git verwenden, um Ihre eigenen privaten Programmierarbeiten auf Ihrem Computer zu verwalten, aber es wird viel häufiger für mehrere Personen auf mehreren Computern verwendet, die zusammenarbeiten möchten. Bei solchen Projekten liegt die kanonische Version des Quellcodes irgendwo auf einem Server – in der Git-Sprache ein zentrales Repository – und die einzelnen Benutzer können Aktualisierungen aus diesem Repository hoch- und herunterladen.
Mit Git können Sie Ihren eigenen Computer als zentrales Repository für andere verwenden oder ein solches an anderer Stelle einrichten, aber es gibt auch viele Dienstleister, die kommerzielle Git-Hosting-Dienste anbieten. GitHub, das 2008 gegründet und 2018 von Microsoft übernommen wurde, ist bei weitem der bekannteste und bietet nicht nur Hosting-Dienste, sondern auch eine Vielzahl anderer Funktionen. Wichtig ist jedoch, dass GitHub zwar auf die Entwicklung mit Git ausgerichtet ist, Sie GitHub jedoch nicht verwenden müssen, um Git zu nutzen.
Versionskontrolle mit Git
Nachdem wir nun einige der Grundlagen behandelt haben, wollen wir nun näher darauf eingehen, wie Git funktioniert und warum es so beliebt ist. Ein vollständiges Git-Tutorial würde den Rahmen dieses Artikels sprengen, aber wir können einen Blick auf die wichtigsten Git-Konzepte und -Terminologie werfen, um Ihnen den Einstieg zu erleichtern.
Git-Repository
Wir haben das Konzept des Repositorys bereits erwähnt. Das Repository ist der konzeptionelle Raum, in dem sich alle Teile Ihres Projekts befinden. Wenn Sie allein an einem Projekt arbeiten, benötigen Sie wahrscheinlich nur ein einziges Repository, während Sie bei einem Gemeinschaftsprojekt wahrscheinlich von einem zentralen Repository aus arbeiten werden. Das zentrale Repository wird auf einem Server oder bei einem zentralen Anbieter wie GitHub gehostet, und jeder Entwickler hat sein eigenes Repository auf seinem eigenen Computer. (Wir werden gleich besprechen, wie die Codedateien in all diesen Repositorys richtig synchronisiert werden).
Ein Git-Repository ist in zwei Bereiche unterteilt. Es gibt einen Staging-Bereich, in dem Sie Dateien hinzufügen und entfernen können, die Ihr Projekt ausmachen, und dann gibt es den Commit-Verlauf. Commits sind das Herzstück der Funktionsweise von Git, daher wollen wir sie als Nächstes besprechen.
Git-Commit
Einen Commit kann man sich am besten als Schnappschuss davon vorstellen, wie Ihr Projekt zu einem bestimmten Zeitpunkt aussieht. 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 später weitere Änderungen und neue Übertragungen vornehmen, aber Sie können immer zu einem früheren Commit zurückkehren. Sie können auch zwei Commits vergleichen, um einen schnellen Überblick über die Änderungen in Ihrem Projekt zu erhalten.
Es ist wichtig zu wissen, dass ein Commit nicht dasselbe ist wie die Übergabe des Codes an die Produktion. Mit einem Commit wird eine Version Ihrer Anwendung erstellt, die Sie testen, mit der Sie experimentieren können usw. Ein Entwicklungsteam kann schnell durch Commits iterieren, um eine Anwendung in einen produktionsfähigen Zustand zu bringen.
Git-Stash
Auch wenn Commits rückgängig gemacht werden können, stellen sie doch ein gewisses Maß an Engagement dar. Wenn Sie an Dateien in Ihrem Bereitstellungsbereich arbeiten und zu etwas anderem übergehen möchten, ohne Ihre Änderungen tatsächlich zu übertragen, können Sie den Befehl git stash verwenden, um sie für eine spätere Verwendung zu speichern.
Git Branch und Git Merge
Bisher haben Sie sich die Commits vielleicht als eine lineare Reihe von Schnappschüssen des Codes vorgestellt, die sich im Laufe der Zeit weiterentwickeln. Einer der wirklich coolen und leistungsstarken Aspekte von Git ist jedoch, dass Sie damit parallel an verschiedenen Versionen Ihrer Anwendung arbeiten können, was für die agile Softwareentwicklung entscheidend ist.
Um Git-Forks und das Zusammenführen in der Praxis zu verstehen, 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 von einer Reihe von Commits in Ihrem Repository entwickeln. Aber dann finden Sie heraus, dass CoolApp 1.0 eine ernsthafte Sicherheitslücke hat und sofort gepatcht werden muss. Sie können zu Ihrem Commit von CoolApp 1.0 zurückgehen, den Patch machen und diesen Code als CoolApp 1.1 in Produktion schicken – alles ohne die Reihe von Commits, die zu CoolApp 2.0 führen, zu stören oder zu ergänzen, die immer noch 1.0 als Elternteil haben. Die Versionen 1.1 und 2.0 befinden sich nun in getrennten Zweigen Ihrer Codebasis. Da Version 1.1 in Produktion ist, während 2.0 in Entwicklung ist, nennen wir 1.1 den Hauptzweig.
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 Forks, ist ein wichtiger Teil der Magie von Git. Git versucht, einen neuen Commit aus zwei verschiedenen „Eltern“ zu erstellen, d. h. aus den jüngsten Commits der beiden Forks. Es erstellt den neuen Commit, indem es seine Vorgänger bis zu dem Punkt vergleicht, an dem sich die beiden Forks getrennt haben, und dann alle Änderungen, die in beiden Forks vorgenommen wurden, in dem neuen, zusammengeführten Commit zusammenfasst. Wenn eine Information – z. B. ein bestimmter Codeblock – in beiden Forks auf unterschiedliche Weise geändert wurde, gibt Git die Frage, welche Version in den neuen Commit gehört, an den Entwickler zurück.
Git-Fork
Eine Fork (auch „Verzweigung/Zweig“) ist als vorübergehende Abweichung von der Hauptcodebasis gedacht, die letztendlich wieder in diese integriert wird. Ein Commit hingegen ist eine dauerhafte Abweichung. Insbesondere bei Open-Source-Projekten kommt es zu einer Abspaltung, 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 derzeitigen Projektbetreuer unterscheiden. GitHub macht es besonders einfach, von bestehenden Git-Repositories abzuspalten; mit einem einzigen Klick können Sie ein bestehendes Repository klonen und nach Ihren eigenen Vorstellungen weiterarbeiten.
Git-Checkout
Viele große Projekte haben mehrere aktive Forks, die parallel entwickelt werden. Mit dem Befehl git checkout können Sie den Forks ändern, an dem Sie gerade arbeiten. Dieser Vorgang aktualisiert die Dateien im Arbeitsverzeichnis auf die neuesten Versionen des Forks, an dem Sie interessiert sind; alle Ihre neuen Übertragungen werden dann auf diesen Fork übertragen, bis Sie einen anderen auschecken.
Git für die Zusammenarbeit nutzen
Bis jetzt haben wir darüber gesprochen, was in einem Git-Repository passiert, als ob Sie allein daran arbeiten würden. Aber Git ist vor allem als Werkzeug für die Zusammenarbeit bekannt. Als Nächstes werden wir uns ansehen, wie Git-Konzepte in kollaborativen Kontexten funktionieren.
Git-Clone
Der einfachste Weg, mit anderen an einem Projekt zusammenzuarbeiten, ist das Klonen eines Repositorys, das bereits auf einem anderen Computer existiert. Beim Klonen wird der gesamte Inhalt dieses Repositorys in ein Repository auf Ihrem eigenen Computer heruntergeladen.
Wir haben bereits über das Konzept eines zentralen Projektarchivs gesprochen. Es ist sehr üblich, dass Projekte ein solches Repository, das auf GitHub oder anderswo gehostet wird, als die kanonische „Quelle der Wahrheit“ darüber betrachten, wie die Codebasis eines Projekts aussieht. Lassen Sie uns für den Rest dieses Artikels von einem solchen Arrangement ausgehen. Beachten Sie jedoch, dass die Frage, welches Repository das zentrale ist, eine Frage der Konvention ist, auf die sich die Projektteilnehmer geeinigt haben und die nicht von Git selbst erzwungen wird. Theoretisch ist es möglich, dass verschiedene Repositorys Code austauschen, ohne dass ein einziges Repository zentral ist.
Git Pull und Git Push
Wir haben besprochen, wie Git zwei Forks von Commits auf demselben Rechner abgleichen kann. Dasselbe kann es für zwei Forks auf verschiedenen Rechnern tun, wobei es im Grunde dieselben Techniken anwendet. Der Vorgang, bei dem ein Fork zwischen zwei Rechnern verschoben wird, wird als Pull oder Push bezeichnet, je nachdem, wie er initiiert wird. Wenn Sie einen Fork von einem entfernten Server auf Ihren Rechner bringen, handelt es sich um einen Pull-Vorgang. Wenn Sie einen Fork von Ihrem Rechner zu einem anderen senden, handelt es sich um einen Push-Vorgang.
Git-Pull-Anfrage
Ihren Code auf einen anderen Rechner zu übertragen – oder auf das zentrale Repository, von dem das gesamte Projekt abhängt – mag etwas, nun ja, aufdringlich erscheinen. Ein häufigeres Szenario, das für die kollaborative Natur der Git-Entwicklung entscheidend ist, ist die Pull-Anfrage. Nehmen wir an, Sie haben den Code für eine neue Funktion fertiggestellt und möchten sie 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 ziehen.
Die Pull-Anfrage gibt den Projektmanagern nicht nur die Möglichkeit, Ihren Beitrag anzunehmen oder abzulehnen, sie schafft auch ein Mini-Diskussionsforum im zentralen Repository, in dem sich alle Projektmitglieder zu der Anfrage äußern können. Dies ist eine wichtige Möglichkeit für Entwickler, Änderungen an der Codebasis eines Projekts zu besprechen, insbesondere bei Open-Source-Projekten, bei denen Git der wichtigste Ort ist, an dem die Mitwirkenden interagieren.
Git unter Windows
Wie bereits erwähnt, wurde Git ursprünglich für die Linux-Kernel-Entwicklung entwickelt und besteht aus einer Reihe von Befehlszeilen-Dienstprogrammen. Seine Struktur und Befehlssyntax sind sehr stark an Unix angelehnt, was bedeutet, dass es mehr oder weniger nativ auf Unix-ähnlichen Betriebssystemen wie Linux und macOS läuft. Die Portierung von Git auf Windows ist etwas schwieriger und basiert auf Git bash, einem Bourne-Shell-Emulator für Windows, der in Git für Windows integriert ist.
GUI- und IDE-Integration
Natürlich sind viele Windows-Entwickler daran gewöhnt, eine grafische Benutzeroberfläche zu verwenden, weshalb Git für Windows auch eine grafische Benutzeroberfläche enthält. Aber auch macOS- und Linux-Benutzer sollten sich nicht ausgeschlossen fühlen: Es gibt eine Vielzahl von GUIs für sie. Es gibt auch plattformübergreifende GUIs, die verschiedene Funktionen bieten.
Sie können Git auch in Ihre bevorzugten IDEs integrieren, darunter Eclipse und Microsoft Visual Studio.
*Josh Fruhlinger ist Schriftsteller und Redakteur und lebt in Los Angeles.
Be the first to comment