Introduction

Les outils de versionning ont pour mission de gérer la modification de fichiers. Ils mémorisent, pour chaque fichier un historique de versions, le nom du développeur et les dates et heures de modification: les anciennes données peuvent à tout moment être chargées et/ou restaurées. Un des buts est de déterminer l’identité de l’utilisateur qui a procédé à des modifications à un instant t. Les objectifs d’un tel système sont, d’un côté, de coordonner l’accès commun de plusieurs utilisateurs à des fichiers et, de l’autre, de permettre le développement simultané de plusieurs branches (en définissant une “branching strategy”).

Par exemple, pour un projet de développement “classique” avec plusieurs développeurs:

- Une branche « master » (stable),

- Une branche par “release”,

- Une branche par feature (et donc par développeur).

git versus svn

SVN est un système centralisé de gestion de sources: Un seul répertoire existe sur un serveur pour stocker les fichiers.

Un fichier ne peut pas être modifié par deux développeurs différents simultanément car les modifications ne peuvent pas être fusionnées simplement.

SVN gère les fichiers et les arborescences de répertoires.

!Système de gestion de sources centralisé

GIT est un système décentralisé, chaque utilisateur travaille en réalité sur sa propre branche en local (copiée/ créée à partir d’un repository distant) puis transfère ses modifications sur le repository distant où elles sont fusionnées à celles des autres développeurs.

Chaque utilisateur dispose donc d’un repository local (qui est une sauvegarde personnelle du repository distant augmentée des modifications locales).

! Système de gestion de sources décentralisé

Brièvement :

SVN Git

Versionning Centralisé Décentralisé

DépôtUn dépôt central dans lequel les copies de travail sont créées

Des copies de dépôt, présentes localement, dans lesquelles il est possible de travailler

Droit d’accès Basé sur le chemin P o u r l e r é p e r t o i r e complet

Suivi des modifications Enregistre des données Enregistre des données

Journal de modifications des données

Complet seulement dans le dépôt. Les copies de travail ne cont iennent que la version la plus récente.

Le dépôt et les copies de t r a v a i l c o n t i e n n e n t l’historique complet.

Connectivité au réseau Pour tous les accès

Nécessaire seulement p o u r r é a l i s e r u n e synchronisation

Principes

Git gère des snapshots (instantanés d’un repository), pas des différences entre fichiers.

La différence majeure entre GIT et SVN réside dans la manière dont GIT considère les données.

Au niveau conceptuel, SVN gère l'information comme une liste de modifications de fichiers. L'information maintenue est une liste de fichiers et les modifications effectuées sur chaque fichier dans le temps.

! SVN

GIT pense ses données plus comme un instantané d'un « système de fichiers ». À chaque commit, GIT prend une photographie du contenu de votre espace de travail à ce moment (et enregistre une référence de cet instantané). Pour être efficace, si les fichiers n'ont pas changé, Git ne stocke pas le fichier à nouveau, juste une référence vers le fichier original qui n'a pas été modifié.

!

GIT

Git est un véritable système de fichiers avec des outils incroyablement puissants construits au-dessus, plutôt qu'un simple système de gestion de sources.

Les commandes utilisateur passées depuis Git sont locales

La plupart des opérations de Git ne nécessitent que des fichiers et ressources locales.

➔ Gain de vitesse (la plupart des commandes semblent instantanées),

➔ Possibilité de travailler même hors connexion au réseau.

Git assure l’intégrité des données

Une hash (somme de contrôle) est générée pour chaque commit et sert de référence unique et non modifiable pour chaque commit (indépendamment de la notion de branche : la somme de contrôle se réfère à un repository et pas à une branche). Cela signifie qu'il est impossible de modifier le contenu d'un fichier ou d'un répertoire sans que Git ne s'en aperçoive : on ne peut pas perdre de données en cours de transfert ou corrompre un fichier sans que Git ne puisse le détecter.

Remarque : Le mécanisme que Git utilise pour réaliser les sommes de contrôle est appelé une empreinte SHA-1. C'est une chaîne de caractères composée de 40 caractères hexadécimaux (de ‘0' à ‘9' et de ‘a' à ‘f') calculée en fonction du contenu du fichier ou de la structure du répertoire considéré.

Une empreinte SHA-1 ressemble à ceci :24b9da6552252987aa493b52f8696cd6d3b00373

Chaque commit possède une somme de contrôle. Elle est générée localement.

Pour chaque opération GIT ne fait qu’ajouter des données

Quand on exécute des commandes Git, elles ne font qu'ajouter des données dans le repository local. Il est très difficile de réaliser des actions irréversibles. Dès lors qu’une modification est commitée, elle est sauvegardée localement. Le commit local fréquent est une bonne pratique : il permet d’expérimenter sans risque de « casser » le projet.

Principe des trois états

Git gère trois états pour les fichiers qu’il stocke:

Modifié: les données sont modifiées mais pas encore commité en base.

Indexé: des fichiers modifiés sont marqués pour faire partie du prochain commit.

Commité: les données sont stockées en sécurité dans votre base de données locale.

Structure d’un projet Git

Le répertoire Git est l'endroit où Git stocke les méta-données et la base de données des objets de votre projet. C'est la partie la plus importante de Git, et c'est ce qui est copié lorsque vous clonez un dépôt depuis un autre ordinateur. (répertoire .git)

Le répertoire de travail est une extraction unique d'une version du projet. Ces fichiers sont extraits depuis la base de données compressée dans le répertoire Git et placés sur le disque pour pouvoir être utilisés ou modifiés.

La zone d'index est un simple fichier, généralement situé dans le répertoire Git, qui stocke les informations concernant ce qui fera partie du prochain instantané.

1. Vous modifiez des fichiers dans votre répertoire de travail 2. Vous indexez les fichiers modifiés, ce qui ajoute des instantanés

de ces fichiers dans la zone d'index 3. Vous réalisez un commit, ce qui a pour effet de basculer les

instantanés des fichiers de l'index dans la base de données du répertoire Git.

Gestion des branches Imaginons 3 fichiers ajoutés à un projet Git

Le cycle de vie des fichiers est Modification: ajout/modifications de fichiers Indexation: git add <fichiers> Commit git commit

Si ce cycle ce répète trois fois, nous avons:

Les commits chainent les instantanés (du plus récent au plus ancien):

C’est une branche !!!

Si rien n’est fait, Git appelle cette branche master

À partir du dernier commit sur master, on peut créer la branche testing

git branch testing

Nous avons maintenant 2 branches !!!

SI rien n’est fait, par défaut Git laisse le HEAD sur la branche master, ce qui signifie que c’est la branche Master que l’on modifie.

On peut déplacer le HEAD sur la branche testing, ce qui signifie que c’est la branche testing qui est utilisée.

git checkout testing

Un nouveau commit déplace le HEAD de 1 sur la branche testing.La branche master reste inchangée, la branche testing dérive de la branche Master.

git add <fichers> git commit

On repositionne le HEAD sur la branche master

git checkout master

Un nouveau commit sur la branche Master implique que les 2 branches ont divergé.

Un merge est nécéssaire pour rétablir la situation. git merge testing

Aide mémoire

Configuration générale

(Configurer son client Git)

git config --global user.name "Vos Nom Prénom"git config --global user.email "toto@hotmail.com"git config --global core.editor vimgit config --global merge.tool vimdiffgit config --global core.autocrlf falsegit config --global core.filemode false # pour voir ce qui est configuré dans un repogit config --list

# pour voir ce qui est configuré "system wide"git config --list --globalgit ignore globalPour ignorer de façon globale des fichiers dans git, on peut utiliser la méthode suivante :# définir ~/.gitignore_global comme fichier d'exclusiongit config --global core.excludesfile ~/.gitignore_global

# dans le fichier .gitignore_global, on a des lignes comme dans un gitignore normal..idea/

Liste de fichiers modifiés entre 2 commits

# Liste de fichiers modifiés entre 2 commitsgit diff --name-only 9960f0a18dfaa3c60a03fb5830b84a20e0deff68 HEAD

Jouer avec les remotes

Les remotes sont les "répository" d'autres machines, c'est à dire pas votre répository.

On prend ici le cas où vous avez les droits sur le remote principal (origin).# récupérer un repository distant chez soigit clone <url projet> # note, on est alors sur le remote "origin" et la branche "master" # mettre à jour son repository local en fonction du remote "origin"git pull # pour envoyer ses données sur un remote# git add, git commit, git push, allez voir Google…

Créer une branche et l'envoyer sur le remote

On suppose qu'on part de l'état suivant :

• Vous venez de cloner un repository remote◦ origin pointe sur ce remote◦ master est la branche par défaut que vous avez récupéré

 # créer une branche locale "dev"git branch dev # crée la branchegit checkout dev # bascule sur cette branche # raccourcis en une commandegit checkout -b dev # voir la liste des branchesgit branch -a # une branche peut avoir un nom plus complexegit checkout -b kit-maps/dev

git branch -a # envoyer la branche locale vers le remote origingit push origin kit-maps/dev

Défaire des choses, récupérer des choses, git checkoutOn a un peu l'impression que "git checkout" est une fonction fourre-tout qui sert à des choses différentes :

• Changer de branche• Faire un revert• Récupérer d'anciennes versions

En fait c'est lié au fonctionnement général de GIT :

git checkout <un_commit> <un_fichier>

• <un_commit> est soit un nom SHA1 de commit (ex : 5f6848f7943057d9414991eead4770c96bb85e6c) soit un pointeur vers un commit (master, head, nom de branche,…),

• <un_fichier> : est un nom de fichier. La commande concerne tout le repository si le nom de fichier est vide, sinon elle concerne un fichier en particulier,

• On se retrouve après le checkout avec le fichier (ou le repository) dans l'état du commit donné en 1er paramètre.

Quelques exemples d'utilisation :# passer sur une branche "dev"git checkout dev# pas de 2 paramètre => tout le repository# "dev" pointe sur le dernier commit de la branche dev,# c'est pour ça que notre repository change de branche. # faire un "revert" (comme dans svn)git checkout /www/index.php# le nom du commit n'est pas mentionné => il prend HEAD par défaut# le fichier bascule dans l'état où il était dans le# repository dans le HEAD, ça fait donc

# l'équivalent d'un svn revert. # revenir à une ancienne version d'un fichiergit log # affiche les dernier commits avec leur SHA1git checkout ff02a4fd8f09 /www/index.php# le fichier bascule dans l'état du commit# donné en 1e paramètre (le code SHA1)

Récupérer en local une branche créée sur le remote# récupérer les codes remotesgit fetch origin # si une branche remote "maBranche" vient d être créée# pour la rapatrier chez soi :git branch --track maBranche remotes/origin/maBranche # voir où on en est :git branch -a

Petites commandes pratiques# un fichier a été ajouté par erreur dans GIT ?# pour le sortir de GIT sans l effacer :git rm --cached <file>

# pour n'ajouter que certaines modifications d'un fichier dans un commitgit stage --patch# ensuite pour chaque modif du fichier, git vous demande si vous voulez# ajouter la modif

Créer des tags# lister les tags d'un repogit tag

# create a taggit tag -a v1.0.0 -m "first stable version"

# push tag to the repogit push origin v1.0.0