-
1. Erste Schritte
-
2. Git Grundlagen
-
3. Git Branching
- 3.1 Branches auf einen Blick
- 3.2 Einfaches 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 Erstellung eines SSH-Public-Keys
- 4.4 Einrichten des Servers
- 4.5 Git-Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Von Drittanbietern gehostete Optionen
- 4.10 Zusammenfassung
-
5. Verteiltes Git
-
6. GitHub
-
7. Git Tools
- 7.1 Revisions-Auswahl
- 7.2 Interaktives Stagen
- 7.3 Stashen und Bereinigen
- 7.4 Deine Arbeit signieren
- 7.5 Suchen
- 7.6 Den Verlauf umschreiben
- 7.7 Reset entzaubert
- 7.8 Fortgeschrittenes Merging
- 7.9 Rerere
- 7.10 Debuggen mit Git
- 7.11 Submodule
- 7.12 Bundling
- 7.13 Replace (Ersetzen)
- 7.14 Anmeldeinformationen speichern
- 7.15 Zusammenfassung
-
8. Git einrichten
- 8.1 Git Konfiguration
- 8.2 Git-Attribute
- 8.3 Git Hooks
- 8.4 Beispiel für Git-forcierte Regeln
- 8.5 Zusammenfassung
-
9. Git und andere VCS-Systeme
- 9.1 Git als Client
- 9.2 Migration zu Git
- 9.3 Zusammenfassung
-
10. Git Interna
-
A1. Anhang A: Git in anderen Umgebungen
- A1.1 Grafische Schnittstellen
- 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
-
A2. Anhang B: Git in Ihre Anwendungen einbetten
- A2.1 Die Git-Kommandozeile
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Anhang C: Git Kommandos
- A3.1 Setup und Konfiguration
- A3.2 Projekte importieren und erstellen
- A3.3 Einfache Snapshot-Funktionen
- A3.4 Branching und Merging
- A3.5 Projekte gemeinsam nutzen und aktualisieren
- A3.6 Kontrollieren und Vergleichen
- A3.7 Debugging
- A3.8 Patchen bzw. Fehlerkorrektur
- A3.9 E-mails
- A3.10 Externe Systeme
- A3.11 Administration
- A3.12 Basisbefehle
4.4 Git auf dem Server - Einrichten des Servers
Einrichten des Servers
Lass uns nun durch die Einrichtung des SSH-Zugriffs auf der Serverseite gehen.
In diesem Beispiel verwendest du die Methode authorized_keys
zur Authentifizierung deiner Benutzer.
Wir nehmen an, dass du eine Standard-Linux-Distribution wie Ubuntu verwendest.
Anmerkung
|
Viele der hier beschriebenen Vorgänge können mit dem Befehl |
Zuerst erstellst du ein git
Benutzerkonto und ein .ssh
Verzeichnis für diesen Benutzer:
$ sudo adduser git
$ su git
$ cd
$ mkdir .ssh && chmod 700 .ssh
$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
Als nächstes mmusst du einige öffentliche SSH-Schlüssel für Entwickler zur authorized_keys
Datei für den git
User hinzufügen.
Nehmen wir an, du hast einige vertrauenswürdige öffentliche Schlüssel und hast sie in temporären Dateien gespeichert.
Auch hier sehen die öffentlichen Schlüssel in etwa so aus:
$ cat /tmp/id_rsa.john.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
dAv8JggJICUvax2T9va5 gsg-keypair
Du fügst sie einfach an die Datei authorized_keys
des git
Benutzers in dessen .ssh
Verzeichnis an:
$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
Nun kannst du ein leeres Repository für sie einrichten, indem du git init
mit der Option --bare
ausführst, die das Repository ohne Arbeitsverzeichnis initialisiert:
$ cd /srv/git
$ mkdir project.git
$ cd project.git
$ git init --bare
Initialized empty Git repository in /srv/git/project.git/
Dann können John, Josie oder Jessica die erste Version ihres Projekts in dieses Repository pushen, indem sie es als Remote hinzufügen und dann einen Branch pushen.
Beachte, dass jemand auf der Maschine eine Shell ausführen muss und jedes Mal, wenn du ein Projekt hinzufügen möchtest, ein Bare-Repository erstellen muss.
Lass uns gitserver
als Hostname für den Server verwenden, auf dem du deinen git
Benutzer und dein Repository eingerichtet hast.
Wenn du den Server in einem internen Netzwerk betreibst und DNS so einrichtest, dass gitserver
auf diesen Server zeigt, dann kannst du folgende Befehle verwenden (vorausgesetzt, dass myproject
ein bestehendes Git-Projekt ist):
# on John's computer
$ cd myproject
$ git init
$ git add .
$ git commit -m 'Initial commit'
$ git remote add origin git@gitserver:/srv/git/project.git
$ git push origin master
Jetzt können die anderen es klonen und Änderungen genauso einfach wieder pushen:
$ git clone git@gitserver:/srv/git/project.git
$ cd project
$ vim README
$ git commit -am 'Fix for README file'
$ git push origin master
Mit dieser Methode kannst du kurzfristig einen Read/Write Git-Server für eine Handvoll Entwickler in Betrieb nehmen.
Du solltest beachten, dass sich derzeit alle diese Benutzer auch am Server anmelden und eine Shell als git
Benutzer erhalten können.
Wenn du das einschränken willst, musst du die Shell zu etwas anderem in der Datei /etc/passwd
ändern.
Du kannst das git
Benutzerkonto mit einem in Git enthaltenen Shell-Tool mit dem Namen git-shell
ganz einfach auf Git-bezogene Aktivitäten beschränken.
Wenn du diese Option als Anmeldeshell des git
Benutzerkontos festlegst, hat dieses Konto keinen normalen Shell-Zugriff auf deinen Server.
Um das einzurichten, gib git-shell
anstelle von bash
oder csh
für die Login-Shell dieses Kontos an.
Um das zu erreichen, musst du zuerst den vollständigen Pfadnamen des git-shell
Befehls zu /etc/shells
hinzufügen, falls er nicht bereits vorhanden ist:
$ cat /etc/shells # prüfe ob git-shell bereits vorhanden ist. Wenn nicht...
$ which git-shell # prüfe, ob git-shell auf deinem System installiert ist.
$ sudo -e /etc/shells # füge den pfad zu git-shell aus deinem letzten Kommando hinzu
Jetzt kannst du die Shell für einen Benutzer mit chsh <username> -s <shell>
bearbeiten:
$ sudo chsh git -s $(which git-shell)
Nun kann der git
Benutzer die SSH-Verbindung weiterhin zum Pushen und Pullen von Git-Repositorys verwenden, aber sich sonst nicht mehr auf der Maschine bewegen.
Wenn du es versuchst, siehst du eine entsprechende Meldung:
$ ssh git@gitserver
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
Connection to gitserver closed.
An dieser Stelle könnten Benutzer noch SSH-Portforwarding verwenden, um auf jeden Host zuzugreifen, den der Git-Server erreichen kann.
Wenn du das verhindern möchtest, kannst du die Datei authorized_keys
bearbeiten und jedem Schlüssel, den du einschränken möchtest, die folgenden Optionen voranstellen:
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
Das Ergebnis sollte so aussehen:
$ cat ~/.ssh/authorized_keys
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4LojG6rs6h
PB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4kYjh6541N
YsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9EzSdfd8AcC
IicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myivO7TCUSBd
LQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPqdAv8JggJ
ICUvax2T9va5 gsg-keypair
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDEwENNMomTboYI+LJieaAY16qiXiH3wuvENhBG...
Jetzt funktionieren die Git-Netzwerkbefehle weiterhin einwandfrei, aber die Benutzer können keine Shell nutzen.
Wie oben zu sehen, kannst du auch ein Verzeichnis im Home-Verzeichnis des git
Benutzers einrichten, das den git-shell
Befehl ein wenig anpasst.
Du kannst beispielsweise die vom Server akzeptierten Git-Befehle einschränken oder die Nachricht anpassen, die Benutzer sehen, wenn sie versuchen, SSH auf diese Weise auszuführen.
Führe git help shell
aus, um weitere Informationen zum Anpassen der Shell zu erhalten.