Siessegger Git – kurz & gut

2. Auflage 2024
ISBN: 978-3-96010-829-0
Verlag: dpunkt.verlag
Format: EPUB
Kopierschutz: 6 - ePub Watermark

E-Book, Deutsch, 184 Seiten

Reihe: kurz & gut

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

Autoren/Hrsg.

Siessegger, Nina

Fachgebiete

• Mathematik | Informatik EDV | Informatik Programmierung | Softwareentwicklung Programmierung: Methoden und Allgemeines
• Mathematik | Informatik EDV | Informatik Programmierung | Softwareentwicklung Software Engineering

Leseproben

KAPITEL 3
Arbeiten mit Git
Hilfe finden
Die Dokumentation von Git ist sehr gut und teilweise auch auf Deutsch verfügbar. Fragen zur Benutzung von Git gehören sicher zu den meistgesuchten im Netz, und es gibt hierzu wahnsinnig viele gute Antworten und Beiträge. Natürlich hat Git auch auf der Kommandozeile eine Hilfe integriert, git help listet die meistverwendeten Kommandos auf und bietet die Möglichkeit, sich die Dokumentation zu einzelnen Kommandos anzeigen zu lassen. Bei der täglichen Arbeit ist das Kommando git status extrem hilfreich. Es liefert nicht nur Informationen darüber, was gerade passiert, es bietet auch Hilfestellung an, wenn es darum geht, wie die nächsten Schritte aussehen könnten. Wenn du mal nicht weiterweißt, schau, ob dir die Ausgabe von git status weiterhilft. Im Abschnitt »Was hat sich lokal geändert?« auf Seite 42 schauen wir uns git status noch einmal detaillierter an. Viele Git-Aktionen kannst du auch wieder abbrechen. Wenn du also merkst, dass etwas nicht so läuft wie gedacht, solltest du prüfen, ob du das entsprechende Kommando abbrechen kannst. Möglich ist das z.B. beim Merge oder beim Rebase. Das bereits ausgeführte Kommando wird hierzu noch einmal mit dem Flag abort aufgerufen. Dies ist ein Beispiel, in dem das Merge-Kommando abgebrochen wird: $ git merge --abort Wenn du das abort-Flag verwendest, ist dein lokaler Stand wieder der gleiche wie vor der Ausführung des Merge-Kommandos. Das Git-Repository
Das Git-Repository ist die Grundlage allen Arbeitens mit Git. Es ist das Projektverzeichnis, in dem alle Projektdaten sowie die von Git gespeicherten Änderungen abgelegt werden. Am Anfang der Arbeit mit Git steht deshalb immer das Erstellen oder das Herunterladen eines Repositorys. Git-Kommandos lassen sich in der Regel nur in einem Git-Repository ausführen. Wer es außerhalb eines Repositorys versucht, wird eine Fehlermeldung erhalten mit dem Hinweis, dass es sich beim aktuellen Ordner nicht um ein Git-Repository handelt. fatal: not a git repository (or any of the parent directories): .git Lokal initialisieren Um aus einem gewöhnlichen Ordner ein Git-Repository zu machen und fortan Änderungen zu verfolgen, wird im betreffenden Ordner folgender Befehl aufgerufen: $ git init Mit Remote-Repositories arbeiten In aller Regel wird Git genutzt, um gemeinsam mit anderen an einer Codebasis zusammenzuarbeiten. Hier kommen Remote-Repositories ins Spiel. Was sind Remote-Repositories? Ein lokales Repository ist durch die Konfigurationsoption remote mit einer Quelle verbunden. Diese Quelle ist ein geteiltes Repository, das heute häufig auf Onlineservices wie GitHub gehostet ist. Es kann aber auch ein Server sein, auf dem Git installiert ist und auf dem das Repository liegt. Obwohl Git einen dezentralen Ansatz verfolgt, wird in den meisten Fällen das Remote-Repository zum »zentralen« Repository. Du kannst dir die Remote-Repositories eines Git-Repositorys über den Befehl git remote anzeigen lassen. Das Kommando git remote -v zeigt zusätzlich die URLs der Remote-Repositories an. Üblicherweise heißt das Haupt-Remote-Repository origin. Das ist aber nur eine Konvention, und es ist auch möglich, mehrere Remote-Repositories zu verwenden. In der Regel wird aber nur ein Remote-Repository verwendet, und dieses wird origin genannt. Abbildung 3-1: Ein Team arbeitet mit einem zentralen Repository. Exkurs: Mehrere Remote-Repositories In den meisten Fällen arbeitet ein Entwicklungsteam mit einem Remote-Repository. Eine Ausnahme bildet der Fork-basierte Workflow, der häufig bei der Zusammenarbeit an Open-Source-Projekten eingesetzt wird. Nicht alle, die an einem Open-Source-Projekt mitarbeiten, haben und erhalten Schreibzugriff auf das online bei GitHub oder GitLab gehostete Repository. Beim Fork-basierten Workflow können die Maintainer immer entscheiden, welche Änderungen übernommen werden, und haben die volle Kontrolle. Zudem wäre das User- und Rechtemanagement schlicht viel zu viel Aufwand für die häufig ehrenamtlich betriebenen Projekte. Wichtig zu wissen: Das Forken ist ein Feature von Git-Onlinediensten wie GitHub. Fork heißt auf Deutsch Gabel oder Verzweigung. Wenn du einen Fork erstellst, kopierst du ein bestehendes Repository in deinen persönlichen GitHub-Account. In dieser Kopie des Repositorys kannst du Änderungen durchführen und diese in dein eigenes Remote-Repository pushen. Das geschieht völlig isoliert vom ursprünglichen Projekt. Änderungen, die im ursprünglichen Repository passieren, kannst du durch die Konfiguration eines zweiten Remote-Repositorys weiterhin abrufen. Wenn alles fertig ist, erstellst du aus dem Fork heraus einen Änderungsvorschlag für das Repository des Open-Source-Projekts. Ein solcher Änderungsvorschlag wird in der GitHub-Terminologie Pull-Request genannt. Die folgende Grafik illustriert die Verwendung der beiden Remote-Repositories. Wir schauen uns in Kapitel 5, »Typische Git-Workflows«, noch einmal genauer an, wie das Arbeiten mit einem Fork in der Praxis funktioniert. Abbildung 3-2: Beim Fork-basierten Workflow gibt es zwei Remote-Repositories: das Original-Repository und den Fork – also die Kopie – in deinem GitHub-Account. Ein Repository kopieren Um ein existierendes Repository zum ersten Mal auf den eigenen Rechner zu kopieren, wird das Kommando git clone verwendet. Es kopiert das Repository in einen neuen Ordner, der von Git erstellt wird und den Namen des Repositorys hat. Das Kommando git clone versieht das Repository außerdem mit einer spezifischen Konfigurationseinstellung, die auf das Quell-Repository zeigt. Diese Konfiguration wird remote genannt. Eine Remote-Konfiguration wird immer mit einer Kurzbezeichnung versehen. Falls es mehrere Remote-Konfigurationen gibt, kannst du sie so leichter auseinanderhalten. Per Default verwendet Git die Kurzbezeichnung origin. Das Herunter- und Hochladen eines Repositorys ist grundsätzlich durch die Protokolle git, SSH, HTTP und HTTPS möglich. Die meisten Onlinedienste wie GitHub oder GitLab unterstützen die sichereren Protokolle HTTPS und SSH. HTTPS ist einfach zu benutzen, und die durch das Protokoll verwendeten Ports werden in der Regel nicht durch Firewalls blockiert. Im folgenden Beispiel wird ein Repository, das auf GitHub gehostet ist, geklont. $ git clone https://github.com//.git Bei den gängigen Git-Onlinediensten findest du die URL, um das Repository zu klonen, in der Regel unter dem Menüpunkt Code oder Download. Arbeitest du mit weiteren Entwickler*innen zusammen an einem gemeinsamen Repository, laden diese ständig Änderungen in das Repository hoch. Diese Änderungen musst du dir immer wieder mit dem Befehl git pull herunterladen. Wir schauen uns das Kommando später noch genauer an. Wichtig ist jetzt: Bei jedem Herunterladen musst du dich immer erneut authentifizieren. Wird das Repository bei GitHub gehostet und hast du HTTPS verwendet, musst du stets deinen Benutzernamen und dein Passwort neu angeben. So wird sichergestellt, dass du wirklich die Berechtigung hast, das Repository herunterzuladen. Auch wenn du Änderungen in ein Repository hochlädst, ist das der Fall. In einigen Firmen und Projekten ist die Verwendung einer Zwei-Faktor-Authentifizierung Pflicht. Das wird ebenfalls von den Onlinediensten angeboten. Bei GitHub ist es dann z.B. notwendig, für die Authentifizierung einen Personal Access Token im Profil zu generieren und diesen für die Authentifizierung zu verwenden. Alternativ zur Verwendung von HTTPS kann ein Repository per SSH geklont werden. $ git clone [e-mail]:/.git Da SSH auf einem Public-Key-Verschlüsselungsverfahren beruht, benötigst du ein Schlüsselpaar, um SSH zu nutzen. Dieses Schlüsselpaar besteht aus einem privaten und einem öffentlichen Schlüssel. Der private Schlüssel ist geheim und wird mit niemandem geteilt. Der öffentliche Schlüssel wird auf einem Server oder bei einem Service wie GitHub hinterlegt, und du kannst dich dann mit deinem privaten Schlüssel authentifizieren. Welche Schritte hierzu nötig sind, beschreibt der folgende Hinweis »SSH-Key erstellen und bei GitHub hinterlegen«. SSH-Key erstellen und bei GitHub...

Über Autor(innen)

Nina Siessegger ist studierte Historikerin, entdeckte jedoch schon bald ihre Leidenschaft fürs Programmieren. Sie hat für verschiedene Start-ups gearbeitet und war für die IT-Beratung ThoughtWorks als Entwicklerin und Tech-Lead tätig. Einige Jahre war sie freiberuflich als Softwareentwicklerin tätig. Inzwischen liegt ihr Schwerpunkt auf agiler Organisationsberatung und Konfliktmanagement. Sie begleitet Teams und Organisationen in Veränderungsprozessen und unterstützt sie dabei, kontinuierlich zu lernen und sich weiterzuentwickeln.