CoGITons

Contrairement à CVS et SVN, Git ne repose pas sur un serveur centralisé.

Le principe de fonctionnement est celui d'un serveur de versions, soit suivre l'évolution du contenu d'une arborescence.

Git ne procède pas à un diff , l'intégralité de chaque source modifiée est sauvegardée.

Rassurez-vous, cette sauvegarde se fait dans un blob compressé, et la taille prise sur le disque augmente très lentement.

Git a été conçu comme un système de fichiers, et offre de très bonnes performances.

Comme tout serveur de données, on peut l'utiliser pour stocker tout type de fichiers. Voici une comparaison de Git avec Subversion et Mercurial.

Nous avons un gagnant !


Windows: bien aGITer avant emploi.

  • Je ne traite pas de l'installation Linux, car elle ne présente pas de problèmes.
    • Les utilisateurs de Linux peuvent aller directement ici : site officiel
  • Sous Windows, c'est un peu plus délicat, mais les développeurs ont quand même pensé à vous.
    • Normalement, seul Cygwin est supporté.
    • Il existe cependant un projet pour le faire tourner avec MSys.
    • Cet installeur contient un shell MSys avec tous les outils nécessaires.
    • Rien ne vous empêche de continuer à utiliser votre propre shell, en ajoutant le path bin du shell de Git.
  • Lancer l'installation.
    • Surtout ne cherchez pas à l'installer dans votre arborescence MSys si vous en avez déja une.
    • Depuis la version 1.5.5, les fins de lignes sont converties en CRLF dans le répertoire source, et en LF dans l'arbre Git. C'est une chose bonne et souhaitable, et vous ne devriez pas chercher à changer ce comportement par défaut.
    • J'ai choisi de ne pas modifier les variables d'environnement (Use Git Bash only), car pour ma part, j'ai modifié le path de mon MSys déja installé, pour inclure le répertoire bin de Msys-Git.
    • Et voila, c'est installé. Tout est linké en statique, ça prend un peu plus de 100mo. C'est mieux que les moutures précédentes qui prenaient plus de 600mo! Encore un petit effort et ça sera parfait.
  • Un peu de personnalisation
    • pour ceux qui ont déja un shell, ajouter ${msysgit}/bin dans le ${PATH} de celui-ci.
    • modifier ${msysgit}/bin/vi , et mettre gvim à la place de l'appel de vi.
  • Juste pour vérifier
~$ git --version
git version 1.5.5.1015.g9d258



Configuration

  • Utiliser git config avec les clés de configuration à modifier.
  • Emplacement des fichiers de configuration
    • La configuration générale est stockée ici: ${HOME}/.gitconfig
    • La configuration locale est stockée dans le répertoire du projet
    • Les Unixiens ont également une config pour tous les utilisateurs du système dans /etc/gitconfig
  • Une bonne idée est de donner quelques informations sur la machine et l'unité carbone qui l'utilise.
    • git config --global user.name "Jean Seb"
    • git config --global user.email "johannsebaztian@finiderire.com"
  • Pour voir la clé de configuration global
 git config --global --list


  • On veut tout voir (et rien payer)
git config --list



Commandes de base

  • Création d'un repository Git
    • se mettre dans un répertoire (peuplé ou pas), puis: git init
    • par défaut, la branche créée se nomme master.
  • Ajouter et enlever des fichiers au dépot
    • ajouter les fichier avec git add fichier (on peut utiliser des jokers)
    • pour ajouter tous les fichiers , utiliser un point : git add .
    • on peut enlever ce qui ne sert plus avec git rm fichier (on peut aussi utiliser les jokers)
    • plutot que d'ajouter en masse puis enlever les fichiers au cas par cas, on spécifiera dans exclude les fichiers à ne pas intégrer au projet.
  • Commiter
    • pour voir ce qui va être commité : git diff --cached
    • pour commiter les changements: git commit
  • Première récupération d'un repository distant
    • Git est un serveur décentralisé , on obtient donc des copies des projets.
    • je prends un projet au hasard sur gitorious.org , qui est un hébergeur gratuit de repositories Git.
    • pour créer le projet, utiliser clone : git clone git://gitorious.org/interstellar/mainline.git
  • Lister les modifications
    • tout lister : git log (ou git log -p pour avoir le diff complet pour chaque étape)
    • lister une modification particulière : git log -p XXXXX (avec XXXX le début du SHA1 correspondant à la modif.)
    • il semble que git show XXXXXX fait la même chose que la commande précédente.
  • Rechercher dans les fichiers
    • nous disposons d'un vrai grep : git grep Iirrlicht
  • Pour avoir des informations sur les commandes
    • git --help vous rappelle les principales commandes.
    • git commande --help invoque le man de la commande concernée dans votre navigateur.


Maintenance et suivi du dépôt

  • reset : en cas de pépin
    • git reset --hard
    • à réserver aux cas difficiles (problèmes de changement de branches par exemple).
  • gc : pour nettoyer et reconstruire le dépot (à faire de temps en temps sur les gros projets)
    • git gc
  • fsck : pour vérifier l'intégrité du dépôt
    • git fsck
  • count-objects : pour avoir des stats sur les objets
    • git count-objects


Les branches

  • pour voir la branche dans laquelle on se trouve: git branch
  • pour créer une branche : git branch nouvelle_branche
  • pour voir toutes les branches : git branch -r (donnera: origin/HEAD et origin/master)
  • pour changer de branche, utiliser checkout : git checkout bidule
    • quand on change de branche, les fichiers sont modifiés en rapport (si un fichier n'est pas utilisé dans la nouvelle branche, il disparaitra).
    • un changement réussi de branche se solde par un Switched to branch nom_de_la_branche
    • pour retourner dans une branche précédente, utiliser une nouvelle fois checkout : git checkout ancienne_branche
  • pour fusionner deux branches: merge
    • Si on se trouve dans main et que l'on veut fusionner le contenu de experimental : git merge experimental
  • pour effacer une branche : branch -d experimental
    • la commande précédente vérifie que les changements faits dans la branche experimental ont été intégrés. Pour forcer la destruction : branch -D experimental
  • avec checkout, on peut récupérer la dernière version commitée d'un fichier (si on regrette ses modifications)
    • on peut également restaurer le fichier depuis un commit antérieur, ou depuis une autre branche.
  • un dépôt n'est jamais modifiable, sauf en ajout. On ne peut pas modifier un fichier commité (il faut refaire un commit, et donc ajouter une couche).
    • pour annuler un commit, le seul moyen est donc de faire soi-même les modifications inverses sur les objets, puis de commiter à nouveau.


commit , fetch , pull , push

  • Le commit est local.
    • Avant un commit, Git demande d'ajouter un commentaire. La première ligne est le résumé des modifications. Toutes les lignes commençant par un dièse sont ignorées, et il faut obligatoirement une ligne qui ne commence pas par un dièse.
    • On peut aussi rentrer directement la description : git commit -m "Cette fois, ça va marcher!"
  • Le pull (download) permet de récupérer des modifications distantes et d'appliquer la fusion (merge) des objets.
    • récupérer la branche master du dépôt project :
git pull /home/toto/project master


  • Le fetch est un simple download, sans la fusion des objets (il faut faire soi-même un git merge ... )
$~ git remote add fred /home/fred/project
$~ git fetch fred
$~ git log -p master..fred/master
$~ git merge fred/master


  • Le push (upload) permet d'envoyer des fichiers à distance. Il permet également d'envoyer des modifications dans une autre branche.
git push git://serveur.git.org/projet.git



Cas pratique

L'intêret de Git est de supprimer le côté centralisé de CVS et SVN. Mais encore ?

  • Soit deux utilisateurs: jseb et fred.
  • Ces deux utilisateurs utilisent chacun un repository, plus deux repositories publics (hébergés chez fred) pour partager leurs modifications.
    • Il y a donc deux dépôts privés (un chez jseb, un chez fred) et deux dépôts public (hébergés chez fred, mais ils pourraient être n'importe où).
    • Les modifications de jseb et fred ne vont toucher que leurs dépôts publics respectifs (principe de décentralisation de Git, que n'ont pas SVN ou CVS). Il appartient à jseb et à fred de faire le pull qui ramènera les modifications publiques vers leur dépôt privé.
  • Côté fred :
    • création d'un alias vers son dépôt public : git remote add fred git://publicgit.domaine.org/jseb.git
    • création d'un alias vers le dépôt public de jseb : git remote add jseb git://publicgit.domaine.org/jseb.git
    • git remote add ne fait qu'ajouter un alias dans .git/config et n'a pas d'autre effet que de simplifier les opérations ultérieures.
    • fred récupère les données du dépôt public (pour l'instant vide) vers son dépôt privé : git pull jseb
    • la commande précédente est équivalente à git pull git://publicgit.domaine.org/jseb.git
  • Côté jseb :
    • jseb veut envoyer les données de son dépôt irrlicht dans le repository public jseb (celui-ci a été créé sur le serveur par fred qui est l'hébergeur).
    • fred a créé le dépôt public fred.git où il placera ses modifications, afin que jseb puisse y accéder
    • jseb va donc créer un alias fred.git pour récupérer les modifications de fred : git remote add fred git://publicgit.domaine.org/jseb.git
    • jseb va également créer un alias jseb pour pouvoir envoyer les données modifiées vers son dépôt public.
  • jseb envoie ses sources dans le dépôt public (ici, décomposé en deux temps pour la démonstration)
  • 1er temps: partie accès local
    • git init
    • git add . . Notez le point pour tout envoyer, sauf ce qui est défini dans .git/info/exclude (objets et les préfixes d'exécutables)
    • git commit
  • 2ème temps: partie accès vers le serveur public distant
    • git remote add jseb git://publicgit.domaine.org/jseb.git
    • git push jseb
    • ( note: pour un premier envoi de jseb dans la branche master : git push git://publicgit.domaine.org/jseb.git/ master )
  • fred récupère sur son dépôt privé les modifications de jseb
    • git clone git://publicgit.domaine.org/jseb.git irrlicht-jseb (l'argument irrlicht-jseb est le nom à donner au répertoire)
    • fred fait ensuite quelques modifs dans les sources.
  • jseb peut récupérer les modifications de fred
    • git pull fred
  • le processus se répète indéfiniment jusqu'à satisfaction des deux parties, grosse fête, banquet, clameurs de liesse et couronnement des champions.


Bonus : l'interface Tk

  • Pour suivre une arborescence bien compliquée, rien ne vaut un petit dessin.
  • Git est livré avec deux interfaces Tcl/Tk
  • gitk : interface canal historique.
    • Placez vous dans un repository.
    • gitk
    • si la commande précédente ne fonctionne pas: $~ wish $(type -p gitk)
    • pour voir toutes les branches : $~ wish $(type -p gitk) --all
  • git-gui : interface simplifiée pour les opérations courantes.
    • lancer git-gui (si ça ne fonctionne pas, même remarque que pour gitk).


Trouver un GITe


Liens divers


L'aGITé du bocal

  • En anglais, git signifie connard.
  • L. Torvalds dit avoir choisi le nom en assumant son côté d'incurable égocentrique: je nomme tous mes projets d'après ma personne. D'abord Linux, maintenant Git.