Avant-propos
J’ai initié la rédaction de ce billet le 11 juin 2014 ! Le 18 décembre 2014, j’annonçais d’ailleurs sa publication à venir. Depuis quatre années, il traîne donc lamentablement dans mes brouillons. À plusieurs reprises, j’ai tenté de le finaliser mais, de l’eau ayant coulé sous les ponts, je me posais des questions sur la pertinence d’un tel billet « outdated« . Vu qu’il était en grande partie écrit et même s’il pourra paraître trop simpliste, j’ai tout de même décidé de le publier. Il s’agit plus d’un billet de présentation des bases de git que d’un tuto à suivre au pied de la lettre mais peut-être que ces quelques lignes vous permettront de mettre le pied à l’étrier. Bien entendu, si vous avez des questions, n’hésitez pas à les poser en commentaire ou via le formulaire de contact.
Prérequis
Bien entendu, je pars du principe votre stack de développement est en place et que git et ssh sont opérationnels.
Grille de lecture
- sur fond bleu, le code à taper dans votre invite de commande local
- sur fond vert, le code à taper dans l’invite de commande sur le serveur distant
Serveur local | Serveur distant |
C’est parti ! ^^
Initialisation du dépôt
Tout d’abord, placez vous dans le dossier de votre projet existant (à sa racine).
cd /www/monProjet | On se place à la racine du projet |
git init | Initialisation du dépôt git |
git add . | Ajout de tous les fichiers existants du projet |
git commit -m "Premier commit" | Commit : soumission des modifications |
Nous allons maintenant procéder à la création du dépôt distant.
On se place dans le dossier qui va contenir les données git du projet | cd /chemin/repo/ |
Création du répertoire qui va contenir les données git : le dépôt | mkdir nomDuProjet.git |
On se place dans le répertoire nouvellement créé | cd nomDuProjet.git |
Initialisation de git, sans création du dossier .git | git init --bare |
Association des dépôts (local et distant)
Nous pouvons maintenant associer les deux dépôts git créés (celui en local, et celui sur le serveur distant)
git remote add origin ssh://user@server/chemin/repo/nomDuProjet.git | On ajoute le dépôt distant (nommé par convention origin) |
git push origin master | On envoie les modifications du dernier commit sur le serveur distant |
Attention, pour l’instant, seul les données de versionning sont envoyées. Les sources (code) de votre projet ne sont pas encore déployée sur le serveur distant.
Déploiement des sources
Pour déployer les sources sur le serveur distant, nous allons tout d’abord « cloner » les sources (ici dans le répertoire /www) :
On vérifie que le dépôt est en place et que le dernier commit a bien été « poussé » | git log |
On se place dans le répertoire qui accueillera les sources | cd /www/ |
Clone du projet | git clone /chemin/repo/nomDuProjet.git |
Automatisation du déploiement des sources
Pour déployer les sources sans avoir à passer par un pull depuis le serveur à chaque modification, nous allons automatiser la procédure grâce aux hooks.
Pour automatiser les déploiements sur les serveurs de recette et de production, il faut créer ou modifier le fichier post-update dans le répertoire /hooks.
On se place dans le répertoire « hooks » du projet | cd /chemin/repo/nomDuProjet.git/hooks |
On édite le fichier | vi post-update |
N.B. : Dans cet exemple simple de configuration du hook, les sources de production et de recette sont localisées sur le même serveur que le dépôt git.
Contenu à ajouter dans le fichier post-update :
#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transport
#
# To enable this hook, make this file executable by "chmod +x post-update".
echo " ***** PRODUCTION ***** "
cd /www/nomDuProjet
unset GIT_DIR
git pull origin master
echo " ***** RECETTE ***** "
cd /www/nomDuProjetRecette
unset GIT_DIR
git pull origin dev
exec git-update-server-info
Une fois le fichier complété et enregistré :
On modifie les permissions du fichier | chmod +x post-update |
Ces modifications permettront de pull automatiquement les sources sur le serveur à chaque push lancé depuis votre poste de travail. Le répertoire impacté (recette ou production) dépendra de la branche utilisée lors du push.
Travailler avec des branches
Comme vous l’avez constaté, nous avons prévu deux scénarios lors de l’automatisation du déploiement. La branche de développement « dev » va permettre de créer, modifier et tester ses sources sans incidence sur le serveur de production.
git branch dev | On créé la branche « dev » |
git checkout dev | On se positionne sur la branche « dev » |
git pull origin dev | On pull sur la branche « dev » pour vérifier qu’un autre développeur n’a pas ajouté de code |
git push origin dev | On push sur la branche « dev » |
Une fois les développement testés et validés sur le serveur de recette, on fusionne la branche dev avec la branche master et on lance un push. Cela aura pour effet de publier les modifications sur le serveur de production.
git checkout master | On se positionne sur la branche « master » |
git merge dev | On fusionne les branches « master » et « dev » |
git push origin master | On push sur la branche « master » |
git checkout dev | On revient sur la branche « dev » pour développer |
Pour finir
Comme indiqué dans l’avant-propos, je présente ici un workflow excessivement simplifié avec git : sources (recette et production) et dépôts sur le même serveur. Il s’agit ici d’une « mise en bouche » des fonctionnalités de git. À vous d’adapter la configuration à votre architecture et à vos besoins.