-
1. Erste Schritte
- 1.1 Über Versionskontrolle
- 1.2 Eine kurze Geschichte von Git
- 1.3 Was ist Git?
- 1.4 Die Kommandozeile
- 1.5 Git installieren
- 1.6 Erstmalige Git-Einrichtung
- 1.7 Hilfe bekommen
- 1.8 Zusammenfassung
-
2. Git Grundlagen
-
3. Git Branching
- 3.1 Branches im Überblick
- 3.2 Grundlegendes Branching und Merging
- 3.3 Branch-Management
- 3.4 Branching-Workflows
- 3.5 Remote-Branches
- 3.6 Rebasing
- 3.7 Zusammenfassung
-
4. Git auf dem Server
- 4.1 Die Protokolle
- 4.2 Git auf einem Server einrichten
- 4.3 Generieren Ihres SSH-Public-Keys
- 4.4 Einrichten des Servers
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Drittanbieter-Hosting-Optionen
- 4.10 Zusammenfassung
-
5. Verteiltes Git
-
6. GitHub
-
7. Git-Werkzeuge
- 7.1 Revisionsauswahl
- 7.2 Interaktives Staging
- 7.3 Stashing und Bereinigen
- 7.4 Ihre Arbeit signieren
- 7.5 Suchen
- 7.6 Historie umschreiben
- 7.7 Reset entmystifiziert
- 7.8 Fortgeschrittenes Merging
- 7.9 Rerere
- 7.10 Debugging mit Git
- 7.11 Submodule
- 7.12 Bundling
- 7.13 Ersetzen
- 7.14 Credential-Speicher
- 7.15 Zusammenfassung
-
8. Git anpassen
-
9. Git und andere Systeme
- 9.1 Git als Client
- 9.2 Migration zu Git
- 9.3 Zusammenfassung
-
10. Git-Interna
- 10.1 Plumbing und Porcelain
- 10.2 Git-Objekte
- 10.3 Git-Referenzen
- 10.4 Packfiles
- 10.5 Die Refspec
- 10.6 Übertragungsprotokolle
- 10.7 Wartung und Datenwiederherstellung
- 10.8 Umgebungsvariablen
- 10.9 Zusammenfassung
-
Anhang A: Git in anderen Umgebungen
- A1.1 Grafische Oberflächen
- A1.2 Git in Visual Studio
- A1.3 Git in Visual Studio Code
- A1.4 Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git in Sublime Text
- A1.6 Git in Bash
- A1.7 Git in Zsh
- A1.8 Git in PowerShell
- A1.9 Zusammenfassung
-
Anhang B: Git in Ihre Anwendungen einbetten
- A2.1 Kommandozeilen-Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
Anhang C: Git-Befehle
- A3.1 Einrichtung und Konfiguration
- A3.2 Projekte abrufen und erstellen
- A3.3 Grundlegendes Snapshotting
- A3.4 Branching und Merging
- A3.5 Projekte teilen und aktualisieren
- A3.6 Inspektion und Vergleich
- A3.7 Debugging
- A3.8 Patching
- A3.9 E-Mail
- A3.10 Externe Systeme
- A3.11 Administration
- A3.12 Plumbing-Befehle
4.8 Git auf dem Server - GitLab
GitLab
GitWeb ist allerdings ziemlich simpel. Wenn Sie einen modernen, voll ausgestatteten Git-Server suchen, gibt es mehrere Open-Source-Lösungen, die Sie stattdessen installieren können. Da GitLab eine der beliebten ist, werden wir die Installation und Verwendung als Beispiel behandeln. Dies ist schwieriger als die GitWeb-Option und erfordert mehr Wartung, aber es ist eine voll ausgestattete Option.
Installation
GitLab ist eine datenbankgestützte Webanwendung, daher ist die Installation aufwendiger als bei einigen anderen Git-Servern. Glücklicherweise ist dieser Prozess gut dokumentiert und unterstützt. GitLab empfiehlt dringend die Installation von GitLab auf Ihrem Server über das offizielle Omnibus GitLab-Paket.
Die anderen Installationsoptionen sind
-
GitLab Helm Chart für die Verwendung mit Kubernetes.
-
Dockerisierte GitLab-Pakete für die Verwendung mit Docker.
-
Aus den Quelldateien.
-
Cloud-Anbieter wie AWS, Google Cloud Platform, Azure, OpenShift und Digital Ocean.
Weitere Informationen finden Sie in der README-Datei der GitLab Community Edition (CE).
Administration
Auf die Administrationsschnittstelle von GitLab wird über das Web zugegriffen. Rufen Sie einfach die Homepage oder die IP-Adresse, auf der GitLab installiert ist, in Ihrem Browser auf und melden Sie sich als root-Benutzer an. Das Passwort hängt von Ihrem Installationstyp ab, aber standardmäßig generiert Omnibus GitLab automatisch ein Passwort und speichert es mindestens 24 Stunden lang in /etc/gitlab/initial_root_password. Befolgen Sie die Dokumentation für weitere Details. Nach der Anmeldung klicken Sie auf das Symbol "Admin-Bereich" im Menü oben rechts.
Benutzer
Jeder, der Ihren GitLab-Server nutzt, muss ein Benutzerkonto haben. Benutzerkonten sind recht einfach, sie enthalten hauptsächlich persönliche Informationen, die mit Anmeldedaten verknüpft sind. Jedes Benutzerkonto hat einen **Namespace**, eine logische Gruppierung von Projekten, die zu diesem Benutzer gehören. Wenn der Benutzer jane ein Projekt namens project hätte, wäre die URL dieses Projekts http://server/jane/project.
Sie können ein Benutzerkonto auf zwei Arten entfernen: Ein Benutzer "blockieren" verhindert, dass er sich bei der GitLab-Instanz anmelden kann, aber alle Daten unter dem Namespace des Benutzers bleiben erhalten, und mit der E-Mail-Adresse des Benutzers signierte Commits verweisen weiterhin auf sein Profil.
Ein Benutzer hingegen wird "zerstört", d. h. vollständig aus der Datenbank und dem Dateisystem entfernt. Alle Projekte und Daten in seinem Namespace werden entfernt, und alle Gruppen, die ihm gehören, werden ebenfalls entfernt. Dies ist offensichtlich eine viel permanentere und destruktivere Aktion, und Sie werden sie selten benötigen.
Gruppen
Eine GitLab-Gruppe ist eine Sammlung von Projekten zusammen mit Daten darüber, wie Benutzer auf diese Projekte zugreifen können. Jede Gruppe hat einen Projekt-Namespace (genau wie Benutzer), sodass, wenn die Gruppe training ein Projekt materials hat, seine URL http://server/training/materials wäre.
Jeder Gruppe sind eine Reihe von Benutzern zugeordnet, von denen jeder eine Berechtigungsstufe für die Projekte der Gruppe und die Gruppe selbst hat. Diese reichen von "Gast" (nur Issues und Chat) bis "Owner" (volle Kontrolle über die Gruppe, ihre Mitglieder und ihre Projekte). Die Arten von Berechtigungen sind zu zahlreich, um sie hier aufzulisten, aber GitLab hat einen hilfreichen Link auf dem Administrationsbildschirm.
Projekte
Ein GitLab-Projekt entspricht ungefähr einem einzelnen Git-Repository. Jedes Projekt gehört zu einem einzigen Namespace, entweder einem Benutzer oder einer Gruppe. Wenn das Projekt zu einem Benutzer gehört, hat der Eigentümer des Projekts direkte Kontrolle darüber, wer Zugriff auf das Projekt hat; wenn das Projekt zu einer Gruppe gehört, werden die Benutzerberechtigungen der Gruppe wirksam.
Jedes Projekt hat eine Sichtbarkeitsstufe, die steuert, wer Lesezugriff auf die Seiten und das Repository dieses Projekts hat. Wenn ein Projekt *Privat* ist, muss der Eigentümer des Projekts explizit Benutzern Zugriff gewähren. Ein *Internes* Projekt ist für jeden angemeldeten Benutzer sichtbar, und ein *Öffentliches* Projekt ist für jeden sichtbar. Beachten Sie, dass dies sowohl den git fetch-Zugriff als auch den Zugriff auf die Web-UI für dieses Projekt steuert.
Hooks
GitLab bietet Unterstützung für Hooks, sowohl auf Projekt- als auch auf Systemebene. Für beides führt der GitLab-Server bei Eintritt relevanter Ereignisse einen HTTP POST mit einem beschreibenden JSON durch. Dies ist eine großartige Möglichkeit, Ihre Git-Repositories und Ihre GitLab-Instanz mit dem Rest Ihrer Entwicklungsautomatisierung zu verbinden, wie z. B. CI-Servern, Chaträumen oder Deployment-Tools.
Grundlegende Nutzung
Das Erste, was Sie mit GitLab tun möchten, ist die Erstellung eines neuen Projekts. Dies können Sie tun, indem Sie auf das "+"-Symbol in der Symbolleiste klicken. Sie werden nach dem Namen des Projekts, dem Namespace, zu dem es gehören soll, und der Sichtbarkeitsstufe gefragt. Die meisten der hier angegebenen Informationen sind nicht permanent und können später über die Einstellungsansicht geändert werden. Klicken Sie auf "Projekt erstellen" und Sie sind fertig.
Sobald das Projekt existiert, möchten Sie es wahrscheinlich mit einem lokalen Git-Repository verbinden. Jedes Projekt ist über HTTPS oder SSH zugänglich, beides kann zur Konfiguration eines Git-Remotes verwendet werden. Die URLs sind oben auf der Homepage des Projekts sichtbar. Für ein vorhandenes lokales Repository erstellt dieser Befehl ein Remote namens gitlab zum gehosteten Speicherort
$ git remote add gitlab https://server/namespace/project.git
Wenn Sie keine lokale Kopie des Repositorys haben, können Sie einfach Folgendes tun
$ git clone https://server/namespace/project.git
Die Web-UI bietet Zugriff auf mehrere nützliche Ansichten des Repositorys selbst. Die Homepage jedes Projekts zeigt die jüngsten Aktivitäten, und Links oben führen Sie zu Ansichten der Projektdateien und des Commit-Logs.
Gemeinsam arbeiten
Die einfachste Art der Zusammenarbeit an einem GitLab-Projekt ist die direkte Push-Berechtigung für das Git-Repository für jeden Benutzer. Sie können einen Benutzer zu einem Projekt hinzufügen, indem Sie zum Abschnitt "Mitglieder" der Einstellungen dieses Projekts gehen und den neuen Benutzer mit einer Zugriffsebene verknüpfen (die verschiedenen Zugriffsebenen werden in Gruppen kurz erläutert). Indem Sie einem Benutzer die Zugriffsebene "Entwickler" oder höher geben, kann dieser Benutzer Commits und Branches direkt in das Repository pushen.
Eine andere, entkoppelte Art der Zusammenarbeit ist die Verwendung von Merge-Anfragen. Diese Funktion ermöglicht es jedem Benutzer, der ein Projekt sehen kann, auf kontrollierte Weise dazu beizutragen. Benutzer mit direktem Zugriff können einfach einen Branch erstellen, Commits darauf pushen und eine Merge-Anfrage von ihrem Branch zurück zu master oder einem anderen Branch öffnen. Benutzer, die keine Push-Berechtigungen für ein Repository haben, können es "forken", um ihre eigene Kopie zu erstellen, Commits auf *ihre* Kopie pushen und eine Merge-Anfrage von ihrem Fork zurück zum Hauptprojekt öffnen. Dieses Modell ermöglicht es dem Eigentümer, die volle Kontrolle darüber zu behalten, was wann in das Repository aufgenommen wird, und gleichzeitig Beiträge von nicht vertrauenswürdigen Benutzern zu ermöglichen.
Merge-Anfragen und Issues sind die wichtigsten Einheiten für längerfristige Diskussionen in GitLab. Jede Merge-Anfrage ermöglicht eine zeilenweise Diskussion der vorgeschlagenen Änderung (die eine leichte Art von Code-Review unterstützt) sowie einen allgemeinen Diskussionsfaden. Beide können Benutzern zugewiesen oder in Meilensteine organisiert werden.
Dieser Abschnitt konzentriert sich hauptsächlich auf die Git-bezogenen Funktionen von GitLab, aber als reifes Projekt bietet es viele andere Funktionen, die Ihrem Team bei der Zusammenarbeit helfen, wie z. B. Projekt-Wikis und Systemwartungswerkzeuge. Ein Vorteil von GitLab ist, dass Sie, sobald der Server eingerichtet und läuft, selten eine Konfigurationsdatei bearbeiten oder über SSH auf den Server zugreifen müssen. Die meiste Administration und allgemeine Nutzung kann über die browserbasierte Oberfläche erfolgen.