-
1. Démarrage rapide
-
2. Les bases de Git
-
3. Les branches avec Git
-
4. Git sur le serveur
- 4.1 Protocoles
- 4.2 Installation de Git sur un serveur
- 4.3 Génération des clés publiques SSH
- 4.4 Mise en place du serveur
- 4.5 Démon (Daemon) Git
- 4.6 HTTP intelligent
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Git hébergé
- 4.10 Résumé
-
5. Git distribué
-
6. GitHub
-
7. Utilitaires Git
- 7.1 Sélection des versions
- 7.2 Indexation interactive
- 7.3 Remisage et nettoyage
- 7.4 Signer votre travail
- 7.5 Recherche
- 7.6 Réécrire l’historique
- 7.7 Reset démystifié
- 7.8 Fusion avancée
- 7.9 Rerere
- 7.10 Déboguer avec Git
- 7.11 Sous-modules
- 7.12 Empaquetage (bundling)
- 7.13 Replace
- 7.14 Stockage des identifiants
- 7.15 Résumé
-
8. Personnalisation de Git
- 8.1 Configuration de Git
- 8.2 Attributs Git
- 8.3 Crochets Git
- 8.4 Exemple de politique gérée par Git
- 8.5 Résumé
-
9. Git et les autres systèmes
- 9.1 Git comme client
- 9.2 Migration vers Git
- 9.3 Résumé
-
10. Les tripes de Git
- 10.1 Plomberie et porcelaine
- 10.2 Les objets de Git
- 10.3 Références Git
- 10.4 Fichiers groupés
- 10.5 La refspec
- 10.6 Les protocoles de transfert
- 10.7 Maintenance et récupération de données
- 10.8 Les variables d’environnement
- 10.9 Résumé
-
A1. Annexe A: Git dans d’autres environnements
- A1.1 Interfaces graphiques
- A1.2 Git dans Visual Studio
- A1.3 Git dans Visual Studio Code
- A1.4 Git dans IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git dans Sublime Text
- A1.6 Git dans Bash
- A1.7 Git dans Zsh
- A1.8 Git dans PowerShell
- A1.9 Résumé
-
A2. Annexe B: Embarquer Git dans vos applications
- A2.1 Git en ligne de commande
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Commandes Git
- A3.1 Installation et configuration
- A3.2 Obtention et création des projets
- A3.3 Capture d’instantané basique
- A3.4 Création de branches et fusion
- A3.5 Partage et mise à jour de projets
- A3.6 Inspection et comparaison
- A3.7 Débogage
- A3.8 Patchs
- A3.9 Courriel
- A3.10 Systèmes externes
- A3.11 Administration
- A3.12 Commandes de plomberie
4.4 Git sur le serveur - Mise en place du serveur
Mise en place du serveur
Parcourons les étapes de la mise en place d’un accès SSH côté serveur.
Dans cet exemple, vous utiliserez la méthode des authorized_keys
pour authentifier vos utilisateurs.
Nous supposerons également que vous utilisez une distribution Linux standard telle qu’Ubuntu.
Note
|
Une bonne partie de ce qui est décrit ici peut être automatisé en utilisant la commande |
Premièrement, créez un utilisateur 'git' et un répertoire .ssh
pour cet utilisateur.
$ sudo adduser git
$ su git
$ cd
$ mkdir .ssh && chmod 700 .ssh
$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
Ensuite, vous devez ajouter la clé publique d’un développeur au fichier authorized_keys
de l’utilisateur Git.
Supposons que vous avez reçu quelques clés par courriel et les avez sauvées dans des fichiers temporaires.
Pour rappel, une clé publique ressemble à ceci :
$ cat /tmp/id_rsa.john.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
dAv8JggJICUvax2T9va5 gsg-keypair
Il suffit de les ajouter au fichier authorized_keys
de l’utilisateur git
dans son répertoire .ssh
:
$ 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
Maintenant, vous pouvez créer un dépôt vide nu en lançant la commande git init
avec l’option --bare
, ce qui initialise un dépôt sans répertoire de travail :
$ cd /opt/git
$ mkdir project.git
$ cd project.git
$ git init --bare
Initialized empty Git repository in /opt/git/project.git/
Alors, John, Josie ou Jessica peuvent pousser la première version de leur projet vers ce dépôt en l’ajoutant en tant que dépôt distant et en lui poussant une branche.
Notons que quelqu’un doit se connecter par shell au serveur et créer un dépôt nu pour chaque ajout de projet.
Supposons que le nom du serveur soit gitserveur
.
Si vous l’hébergez en interne et avez réglé le DNS pour faire pointer gitserveur
sur ce serveur, alors vous pouvez utiliser les commandes suivantes telles quelles (en supposant que monprojet
est un projet existant et comprenant des fichiers) :
# Sur l'ordinateur de John
$ cd monproject
$ git init
$ git add .
$ git commit -m 'première validation'
$ git remote add origin git@gitserveur:/opt/git/projet.git
$ git push origin master
À présent, les autres utilisateurs peuvent cloner le dépôt et y pousser leurs modifications aussi simplement :
$ git clone git@gitserveur:/opt/git/projet.git
$ cd projet
$ vim LISEZMOI
$ git commit -am 'correction du fichier LISEZMOI'
$ git push origin master
De cette manière, vous pouvez rapidement mettre en place un serveur Git en lecture/écriture pour une poignée de développeurs.
Il faut aussi noter que pour l’instant tous ces utilisateurs peuvent aussi se connecter au serveur et obtenir un shell en tant qu’utilisateur « git ».
Si vous souhaitez restreindre ces droits, il faudra changer le shell pour quelque chose d’autre dans le fichier passwd
.
Vous pouvez simplement restreindre l’utilisateur 'git' à des actions Git avec un shell limité appelé git-shell
qui est fourni avec Git.
Si vous configurez ce shell comme shell de login de l’utilisateur 'git', l’utilisateur 'git' ne peut pas avoir de shell normal sur ce serveur.
Pour utiliser cette fonction, spécifiez git-shell
en lieu et place de bash ou csh pour shell de l’utilisateur.
Pour faire cela, vous devez d’abord ajouter git-shell
à /etc/shells
s’il n’y est pas déjà :
$ cat /etc/shells # voir si `git-shell` est déjà déclaré. Sinon...
$ which git-shell # s'assurer que git-shell est installé sur le système
$ sudo vim /etc/shells # et ajouter le chemin complet vers git-shell
Maintenant, vous pouvez éditer le shell de l’utilisateur en utilisant chsh <utilisateur> -s <shell>
:
$ sudo chsh git -s $(which git-shell)
À présent, l’utilisateur 'git' ne peut plus utiliser la connexion SSH que pour pousser et tirer sur des dépôts Git, il ne peut plus ouvrir un shell. Si vous essayez, vous verrez un rejet de login :
$ ssh git@gitserveur
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
Connection to gitserveur closed.
Ici, les utilisateurs peuvent encore utiliser le transfert de port de SSH pour accéder à n’importe quel hôte que le serveur git est capable d’accéder.
Si vous voulez l’empêcher, vous pouvez éditer le fichier authorized_keys
et préfixer les options suivantes à toutes les clé que vous souhaitez restreindre :
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
Le résultat devrait ressembler à ceci :
$ 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...
Maintenant, les commandes réseau Git continueront de fonctionner correctement mais les utilisateurs ne pourront plus obtenir de shell.
Comme la sortie l’indique, vous pouvez aussi configurer un répertoire dans le répertoire personnel de l’utilisateur « git » qui va personnaliser légèrement le git-shell
.
Par exemple, vous pouvez restreindre les commandes Git que le serveur accepte ou vous pouvez personnaliser le message que les utilisateurs verront s’ils essaient de se connecter en SSH comme ci-dessus.
Lancer git help shell
pour plus d’informations sur la personnalisation du shell.