Si vous souhaitez configurer le contrôle de code source pour un projet, mais préférez ne pas l'héberger sur un service tel que GitHub, vous pouvez exécuter votre propre serveur git sur un VPS pour stocker votre code et servir de référentiel maître pour tous les collaborateurs.
Pourquoi exécuter votre propre serveur ?
Avec le nombre de fournisseurs git hébergés gratuitement, tels que GitHub, GitLab et Bitbucket, cela n'a pas beaucoup de sens de le faire vous-même. Mais, il y a quelques situations où c'est une solution viable.
Tout d'abord, l'exécution de votre propre serveur est beaucoup plus privée, surtout si vous travaillez sur du code que vous préférez ne pas stocker sur le cloud de quelqu'un d'autre. Cela ne veut pas dire que les fournisseurs comme GitLab ne sont pas sécurisés, mais tout héberger vous-même peut donner à certaines personnes plus de tranquillité d'esprit.
De plus, si vous utilisez un tiers- service de fête, il existe des restrictions sur la taille du fichier qui peuvent ne pas être idéales. GitHub n'autorise pas les fichiers de plus de 100 Mo, ce qui peut être un problème majeur pour les projets avec de gros fichiers binaires. L'utilisation de votre propre serveur supprime cette limite, en supposant que vous puissiez payer pour plus d'espace disque.
Quel que soit votre cas d'utilisation, vous pouvez probablement faire mieux que git barebones. L'édition communautaire de GitLab est gratuite et open source, et est facile à configurer sur votre propre serveur. Cela vous donne tous les avantages de l'héberger vous-même avec une très belle interface Web et de nombreux outils CI/CD. Nous vous recommandons fortement d'utiliser GitLab si vous avez de l'espace serveur disponible. (Il nécessite environ 3 Go de RAM.) Vous pouvez lire notre guide d'installation et de configuration pour en savoir plus.
Publicité
Mais, si vous ne voulez pas toutes les cloches et les sifflets, et que vous voulez juste exécuter une simple télécommande git, vous pouvez continuer à lire.
Les télécommandes Git ne sont que le référentiel de quelqu'un d'autre
La première chose à noter à propos de git est que l'hébergement d'un serveur n'est pas vraiment très compliqué. Git utilise un modèle de contrôle de source distribué ; votre clone local d'un référentiel ne se connecte pas du tout à tous vos collègues, mais il se connecte à un “distant,” généralement sur un serveur ou un service central externe. Lorsque vous poussez et tirez, vous apportez des modifications à la copie principale officielle de la télécommande. Lorsque vos collègues récupèrent à partir de la télécommande, ils téléchargent vos commits.
Vous pouvez techniquement exécuter git en tant que service complètement décentralisé. Si vous aviez deux personnes, elles tireraient chacune des mises à jour l'une de l'autre. (Il n'est pas conseillé de pousser vers des référentiels non-serveurs dans cette configuration.) Ce n'est pas vraiment utilisable dans la pratique, à moins que les deux parties aient des adresses IP statiques et soient toujours en ligne, donc la plupart des gens optent pour le serveur-client modèle.
Donc, tout ce qu'est un serveur git n'est alors qu'un référentiel ordinaire qui est configuré en tant que copie principale et ouvert sur Internet. C'est étonnamment simple à configurer. Tout d'abord, nous devrons créer un nouvel utilisateur. Git utilise SSH pour l'authentification et tout le trafic entre les serveurs et les clients, nous aurons donc besoin d'un utilisateur de service pour gérer le référentiel.
sudo useradd git
Ensuite, passez à l'utilisateur git pour le reste de la configuration :
su git
Vous devrez ajouter vos clés SSH au fichier “authorized_keys” de l'utilisateur git :
nano ~/.ssh/authorized_keys Publicité
C'est un domaine où des services comme GitHub et GitLab ont une ligne de commande Git beat. La gestion des accès n'est pas facile à gérer de cette façon, car vous devrez donner à tout le monde l'accès au même utilisateur de service, ce qui n'est pas idéal, ou vous devrez configurer des utilisateurs distincts pour chaque personne, ce qui n'est pas non plus idéal. Dans tous les cas, les commits s'afficheront avec le nom d'utilisateur et l'adresse e-mail que l'utilisateur final a configurés dans ses paramètres git.
Quoi qu'il en soit, pour créer le référentiel réel, exécutez simplement git init dans la maison de l'utilisateur git répertoire :
git init –bare repository.git
L'option –bare est nécessaire ici. Habituellement, lorsque vous clonez un référentiel, git stocke tous les fichiers qu'il utilise pour gérer les versions dans le dossier caché .git, et il conserve une version utilisable de l'endroit où se trouve votre HEAD actuellement extrait. Cela rend généralement votre dossier de dépôt environ deux fois plus volumineux qu'il ne le serait sans git, bien qu'il puisse être plus volumineux si vous avez de gros fichiers binaires et de nombreux changements au fil du temps.
Un référentiel nu est simplement un référentiel sans les versions utilisables des fichiers actuellement extraits. Au lieu de cela, le dossier du référentiel n'est que le contenu de ce qui serait le dossier .git. Cela économise de l'espace de stockage et configure le référentiel en tant que serveur maître. Comme il n'y a pas de contenu local, il n'y aura pas de conflit avec la branche HEAD. C'est une convention de nommer les dépôts nus avec l'extension de fichier .git, mais ce n'est pas explicitement requis.
C'est tout ce qui est requis côté serveur. Depuis votre machine locale, vous devrez cloner le référentiel ou ajouter une nouvelle télécommande :
git remote add origin git@example.com:repository.git
L'URL commence par git@ car elle&# 8217;s se connectant via SSH en tant qu'utilisateur git. Le :repository.git à la fin est en fait un nom de chemin, pas seulement un identifiant. Le chemin est relatif au répertoire personnel de l'utilisateur git, donc si vous avez placé le dépôt ailleurs, vous voudrez le déplacer ici ou utiliser le nom de chemin complet.
Publicité
Une fois que vous avez connecté votre référentiel local, vous devriez avoir un accès complet au push et au pull comme d'habitude. Gardez à l'esprit que git par défaut n'a pas de système d'autorisations intégré, donc rien n'empêche quiconque ayant accès à l'utilisateur git d'avoir un contrôle total sur votre référentiel maître.