Git est un logiciel de gestion de versions de code source. Il est aujourd’hui utilisé par la Direction Technique de Key Consulting comme principal outil de gestion de sources. Si on retrouve les principes généraux de gestion de versions de ses prédécesseurs (CVS, SVN), il se distingue principalement par sa gestion décentralisée.
Ce dossier va essayer de présenter les bases et faire la lumière sur ce mode de fonctionnement.
Généralités
Un projet Subversion possède un dépôt central qui contient l’ensemble de l’historique. Chaque développeur possède une copie locale des sources (checkout) sur laquelle travailler. Les modifications locales sont reportées sur le dépôt central (commit) et les modifications des autres récupérées (update) via ce même dépôt.
Avec un projet Git, chacun dispose de son propre dépôt local. Git fonctionne ensuite par synchronisations entre les dépôts (push et pull). En pratique, la plupart des projets vont désigner l’un des dépôts comme étant le dépôt officiel et l’utiliser comme un dépôt central Subversion.
Démarrer avec Git
Deux solutions pour commencer à travailler, créer un nouveau dépôt local vide ou rapatrier un projet existant (local ou distant).
Les actions ci-dessous sont appliquées sur le répertoire courant.
Création d’un nouveau dépôt (vide) :
git initCopie d’un dépôt distant :
git clone username@host:/path/to/repository
Flux de travail
Le dépôt local est composé de trois arbres maintenus par Git. Le premier est le répertoire de travail qui contient les fichiers. Le deuxième est l’index qui est une sorte de zone de transit. Le troisième appelé head pointe sur le dernier commit effectué dans la branche courante.
Ajout et validation dans le dépôt local
Après modification du code source dans le répertoire de travail, le développeur propose ses changements (ajout dans l’index) :
git add <nom_du_fichier>
git add *Pour supprimer un fichier :
git rm <nom_du_fichier>
C’est la première étape du flux de travail avec Git. Pour valider les modifications il faut effectuer un commit :
git commit -m « commentaires »
Les modifications sont alors validés dans le dépôt local (HEAD), mais pas dans le dépôt distant.
Pousser les modifications sur le dépôt distant
Après avoir validé les modifications dans le dépôt local, il faut maintenant envoyer ces modifications dans le dépôt distant :
git push origin master
Ici « master » correspond à la branche par défaut de Git, il est possible de pousser les modifications sur une branche précise en indiquant son nom (voir les branches plus loin).
Dans le cas où le dépôt local n’aurait pas été connecté à un dépôt distant (via un clone), il est toujours possible de le faire après :
git remote add origin <serveur>
Gestion des branches
Les branches permettent de développer des fonctionnalités isolées les unes des autres. Il existe une branche par défaut appelée « master ».
Création et utilisation d’une nouvelle branche appelée « feature_x » :
git checkout -b feature_xRetour à la branche principale :
git checkout masterSuppression de la branche :
git branch -d feature_x
Une branche n’est accessible aux autres que si elle a été poussée sur le dépôt distant :
git push origin feature_x
Mises à jour et fusion (merge)
Pour mettre à jour son dépôt local avec les dernières mises à jour du dépôt distant :
git pull
L’exécution du pull va récupérer les changements et les fusionner localement.
Pour effectuer une fusion depuis une branche donnée (par exemple feature_x) vers la branche active (celle pour laquelle nous avons fait un checkout dans le répertoire de travail) :
git merge feature_x
Dans les deux cas Git va essayer de fusionner les sources automatiquement. Les fichiers posant des problèmes (conflits) seront affichés par Git. Il faudra les fusionner manuellement et les ajouter à nouveau pour les marquer comme fusionnés :
git add <nom_du_fichier>
Attention, le résultat de la fusion est local, il faudra donc pousser les modifications sur le dépôt distant.
Avant d’effectuer une fusion, on peut visualiser les modifications entre 2 branches à l’aide de la commande diff :
git diff -w <branche_source> <branche_destination>
Gestion des tag
Là où Subversion utilise un numéro de révision qui est incrémenté de 1 à chaque commit, Git utilise un identifiant unique de 40 caractères (hash SHA-1). Pour s’y retrouver plus facilement il est possible de donner un alias à un commit donné.
Placer un tag sur l’état Git courant :
git tag -a <nom_du_tag>Placer un tag sur l’id d’un commit précis :
git tag <nom_du_tag> <id>Pour récupérer l’id d’un commit :
git log
En cas de problèmes
Pour restaurer un fichier (de HEAD vers le répertoire de travail) :
git checkout — <nom_du_fichier>
Pour annuler le dernier commit sur la branche en cours (ne sert à rien si on a déjà fait un push) :
git reset –hard HEAD^
Pour abandonner toutes les modifications locales et retrouver la dernière version présente sur le dépôt distant :
git fetch origin
git reset –hard origin/master
Clients Git
L’idéal est d’utiliser le client Linux (même sous windows, avec éventuellement avec une VM Linux sur son poste qui possède les accès en lecture/écriture sur le système hôte).
Sous Windows, la solution la plus légère est d’utiliser msysgit qui offre une console Git qui permet d’exécuter l’ensemble des commandes.
Il est également possible de passer par Cygwin, mais attention aux problèmes d’encodages de caractères, en particulier lors de l’édition de patch à envoyer à des tiers.
Même s’il est toujours intéressant de disposer d’une version CLI en parallèle pour résoudre les problèmes, les plugins des IDE peuvent être utilisés au quotidien :
- EGit pour Eclipse
- Git scc provider pour Visual Studio
A noter : la commande « gitk –all » permet de visualiser et parcourir l’arbre git complet.
Pour aller plus loin, les sources utilisées pour réaliser ce dossier :
- http://rogerdudler.github.com/git-guide/
- https://git.wiki.kernel.org/index.html
- Le site officiel : http://git-scm.com/
- git help
Une excellente « Git cheat sheet » à imprimer :
Directeur Technique - Groupe Key Consulting
Laisser un commentaire