-
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.2 Git sur le serveur - Installation de Git sur un serveur
Installation de Git sur un serveur
Nous allons Ă prĂ©sent traiter de la configuration dâun service Git gĂ©rant ces protocoles sur votre propre serveur.
|
Note
|
Les commandes et Ă©tapes dĂ©crites ci-aprĂšs sâappliquent Ă des installations simplifiĂ©es sur un serveur Ă base de Linux, bien quâil soit aussi possible de faire fonctionner ces services sur des serveurs macOS ou Windows. La mise en place effective dâun serveur en production au sein dâune infrastructure englobera vraisemblablement des diffĂ©rences dans les mesures de sĂ©curitĂ© et les outils systĂšme, mais ceci devrait permettre de se faire une idĂ©e gĂ©nĂ©rale des besoins. |
Pour rĂ©aliser lâinstallation initiale dâun serveur Git, il faut exporter un dĂ©pĂŽt existant dans un nouveau dĂ©pĂŽt nu â un dĂ©pĂŽt qui ne contient pas de copie de rĂ©pertoire de travail.
Câest gĂ©nĂ©ralement simple Ă faire.
Pour cloner votre dĂ©pĂŽt en crĂ©ant un nouveau dĂ©pĂŽt nu, lancez la commande clone avec lâoption --bare.
Par convention, les répertoires de dépÎt nu finissent en .git, de cette maniÚre :
$ git clone --bare mon_project mon_projet.git
Clonage dans le dépÎt nu 'mon_projet.git'...
fait.Vous devriez maintenant avoir une copie des données de Git dans votre répertoire mon_project.git.
Câest grossiĂšrement Ă©quivalent Ă Â :
$ cp -Rf mon_projet/.git mon_projet.gitIl y a quelques lĂ©gĂšres diffĂ©rences dans le fichier de configuration mais pour lâutilisation envisagĂ©e, câest trĂšs proche. La commande extrait le rĂ©pertoire Git sans rĂ©pertoire de travail et crĂ©e un rĂ©pertoire spĂ©cifique pour lâaccueillir.
Copie du dépÎt nu sur un serveur
Ă prĂ©sent que vous avez une copie nue de votre dĂ©pĂŽt, il ne reste plus quâĂ la placer sur un serveur et Ă rĂ©gler les protocoles.
Supposons que vous avez mis en place un serveur nommé git.exemple.com auquel vous avez accÚs par SSH et que vous souhaitez stocker vos dépÎts Git dans le répertoire /srv/git.
En supposant que /srv/git existe, vous pouvez mettre en place votre dépÎt en copiant le dépÎt nu :
$ scp -r mon_projet.git utilisateur@git.exemple.com:/srv/gitĂ partir de maintenant, tous les autres utilisateurs disposant dâun accĂšs SSH au serveur et ayant un accĂšs en lecture seule au rĂ©pertoire /srv/git peuvent cloner votre dĂ©pĂŽt en lançant la commande :
$ git clone utilisateur@git.exemple.com:/srv/git/mon_projet.gitSi un utilisateur se connecte via SSH au serveur et a accÚs en écriture au répertoire /srv/git/mon_projet.git, il aura automatiquement accÚs pour pousser.
Git ajoutera automatiquement les droits de groupe en Ă©criture Ă un dĂ©pĂŽt si vous lancez la commande git init avec lâoption --shared.
Notez quâen lançant cette commande, vous ne dĂ©truirez pas les commits, rĂ©fĂ©rences, etc. en cours de route.
$ ssh utilisateur@git.exemple.com
$ cd /srv/git/mon_projet.git
$ git init --bare --sharedVous voyez comme il est simple de prendre un dĂ©pĂŽt Git, crĂ©er une version nue et la placer sur un serveur auquel vous et vos collaborateurs avez accĂšs en SSH. Vous voilĂ prĂȘts Ă collaborer sur le mĂȘme projet.
Il faut noter que câest littĂ©ralement tout ce dont vous avez besoin pour dĂ©marrer un serveur Git utile auquel plusieurs personnes ont accĂšs : ajoutez simplement des comptes SSH sur un serveur, et collez un dĂ©pĂŽt nu quelque part oĂč tous les utilisateurs ont accĂšs en lecture et Ă©criture. Vous ĂȘtes prĂȘts Ă travailler, vous nâavez besoin de rien dâautre.
Dans les chapitres Ă venir, nous traiterons de mises en place plus sophistiquĂ©es. Ces sujets incluront lâĂ©limination du besoin de crĂ©er un compte systĂšme pour chaque utilisateur, lâaccĂšs public aux dĂ©pĂŽts, la mise en place dâinterfaces utilisateur web, etc. NĂ©anmoins, gardez Ă lâesprit que pour collaborer avec quelques personnes sur un projet privĂ©, tout ce quâil faut, câest un serveur SSH et un dĂ©pĂŽt nu.
Petites installations
Si vous travaillez dans un petit groupe ou si vous nâĂȘtes quâen phase dâessai de Git au sein de votre sociĂ©tĂ© avec peu de dĂ©veloppeurs, les choses peuvent rester simples. Un des aspects les plus compliquĂ©s de la mise en place dâun serveur Git est la gestion des utilisateurs. Si vous souhaitez que certains dĂ©pĂŽts ne soient accessibles Ă certains utilisateurs quâen lecture seule et en lecture/Ă©criture pour dâautres, la gestion des accĂšs et des permissions peut devenir difficile Ă rĂ©gler.
AccĂšs SSH
Si vous disposez dĂ©jĂ dâun serveur auquel tous vos dĂ©veloppeurs ont un accĂšs SSH, il est gĂ©nĂ©ralement plus facile dây mettre en place votre premier dĂ©pĂŽt car vous nâaurez quasiment aucun rĂ©glage supplĂ©mentaire Ă faire (comme nous lâavons expliquĂ© dans le chapitre prĂ©cĂ©dent). Si vous souhaitez des permissions dâaccĂšs plus complexes, vous pouvez les mettre en place par le jeu des permissions standards sur le systĂšme de fichiers du systĂšme dâexploitation de votre serveur.
Si vous souhaitez placer vos dĂ©pĂŽts sur un serveur qui ne dispose pas dĂ©jĂ de comptes pour chacun des membres de votre Ă©quipe qui aurait accĂšs en Ă©criture, alors vous devrez mettre en place un accĂšs SSH pour eux. En supposant que pour vos dĂ©pĂŽts, vous disposiez dĂ©jĂ dâun serveur SSH installĂ© et auquel vous avez accĂšs.
Il y a quelques moyens de donner un accĂšs Ă tout le monde dans lâĂ©quipe.
Le premier est de crĂ©er des comptes pour tout le monde, ce qui est logique mais peut sâavĂ©rer lourd.
Vous ne souhaiteriez sûrement pas lancer adduser et entrer un mot de passe temporaire pour chaque utilisateur.
Une seconde mĂ©thode consiste Ă crĂ©er un seul utilisateur Git sur la machine, demander Ă chaque dĂ©veloppeur nĂ©cessitant un accĂšs en Ă©criture de vous envoyer une clĂ© publique SSH et dâajouter la-dite clĂ© au fichier ~/.ssh/authorized_keys de votre utilisateur Git.
Ă partir de lĂ , tout le monde sera capable dâaccĂ©der Ă la machine via lâutilisateur Git.
Cela nâaffecte en rien les donnĂ©es de commit â les informations de lâutilisateur SSH par lequel on se connecte nâaffectent pas les donnĂ©es de commit enregistrĂ©es.
Une derniĂšre mĂ©thode consiste Ă faire une authentification SSH auprĂšs dâun serveur LDAP ou tout autre systĂšme dâauthentification centralisĂ© que vous utiliseriez dĂ©jĂ . Tant que chaque utilisateur peut accĂ©der Ă un shell sur la machine, nâimporte quel schĂ©ma dâauthentification SSH devrait fonctionner.
