PRÉSENTATION
gestion de versions décentralisé
Créer par Linus Torvalds
Ce projet est sous licence GPL et est principalement développé en C avec également un peu de Shell et de Perl.
Un peu d'histoire
Git n'était pas, au départ, à proprement parler un logiciel de gestion de versions.
par bien des aspects, vous pouvez considérer Git comme un système de fichiers : il permet un adressage associatif, et possède la notion de versionnage, mais surtout, a été conçu en résolvant le problème du point de vue d'un spécialiste des systèmes de fichiers. Il n'y avait donc aucun intérêt à créer un système de gestion de version traditionnelLinus Torvalds
VERSIONING
Le Versioning chez les Autres
CVS, Subversion, Perforce, Bazaar et autres.
Gestion d'une liste de fichiers et de leurs modifications dans le temps.
L'autre Vision du versioning
Git pense ses données plus comme un instantané d'un mini système de fichiers.
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é.
(PRESQUE)
TOUTES LES OPÉRATIONS SONT LOCALES
La plupart des opérations de Git ne nécessite que des fichiers et ressources locaux.
L'historique complet du projet est localement sur votre disque dur.
Les échanges réseau limités au maximun
Cela signifie aussi qu'il y a très peu de choses que vous ne puissiez réaliser si vous n'êtes pas connecté
GESTION DE L'INTÉGRITÉ
Tout est vérifié par une somme de contrôle avant d'être stocké.
Par la suite cette somme de contrôle, signature unique, sert de référence.
Il est impossible de modifier le contenu d'un fichier ou d'un répertoire sans que Git ne s'en aperçoive.
Mecanisme de controle
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
Philosophie de l'ajout
Presque toutes les actions sont des ajouts.
Presque toutes les actions sont réversibles.
Limitations des impacts d'erreurs de manipulations.
On peut expérimenter sans danger de casser définitivement son projet.
Dans quel état j'erre...
Trois états
validé, modifié et indexé
Modifié signifie que vous avez modifié le fichier mais qu'il n'a pas encore été validé en base.
Indexé signifie que vous avez marqué un fichier modifié dans sa version actuelle pour qu'il fasse partie du prochain instantané du projet.
- vous modifiez des fichiers dans votre répertoire de travail ;
- vous indexez les fichiers modifiés, ce qui ajoute des instantanés de ces fichiers dans la zone d'index ;
- vous validez, 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.
Avantages de GIT
- Le dépôt, puisque local et autonome, est toujours accessible et extrêmement rapide, même lorsque déconnecté du réseau.
- Git ne stocke pas les fichiers, mais les différences entre les fichiers : ce principe lui permet de disposer d'un des mécanismes de fusion les plus efficaces.
- Contrôle total sur le dépôt : on ne dépend plus d'une entité externe. Avec une solution centralisée.
- Un système de branchage extrêmement efficace.
Fonctionnement
Structure du repository
3 Type d'objets
- Les blobs : qui représente en réalité un fichier, ou plutôt une version bien précise d'un fichier.
- Les trees : qui sont en fait des répertoires, contenant des objets blobs, comme dans tout système de fichiers.
- Les commits : le nom parle de lui même.
- Les tags : un tag peut être associé à un commit, afin de l'identifier plus simplement.
Le répertoire .git
-
config/ :
contient des fichiers relatifs à la configuration de l'environnement git, comme par exemple des informations sur le développeur (son nom, son email ...).
-
objects/* :
Répertoire où sont stockés tous les objets git (commits, tags, trees, blobs).
-
ref/heads/* :
contient les informations sur les branches locales du repository.
-
logs/* :
contient les messages de logs.
-
refs/remotes/* :
Contient les informations relatives aux branches distante.
-
index :
Fichier contenant des informations sur l'état du prochain commit.
-
HEAD :
Fichier contenant des informations sur la branche actuelle de l'utilisateur.
Utilisation
Création d'un repository git
2 méthodes
From scratch
cd monprojet/
git-init
git-add .
git-commit
Clonning
git-clone remote_url
Enregistrer des modifications dans le dépôt
Vérifier l'état des fichiers
git status
Placer de nouveaux fichiers sous suivi de version
git add LISEZMOI
Indexer des fichiers modifiés
Si un fichier est modifié mais pas indexé il ne sera pas commité !
$ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: LISEZMOI # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # # modified: benchmarks.rb
#
Il faut donc l'indexer.
$ git add benchmarks.rbOn contôle.
$ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: LISEZMOI # modified: benchmarks.rb #
On est joueur ! On modifie une nouvelle fois le fichier !
$ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: LISEZMOI # modified: benchmarks.rb # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # # modified: benchmarks.rb
Indexé et non indexé ? WTF !
Attention :
Git indexe un fichier dans son état au moment où la commande d'ajout est lancée.
Ignorer des fichiers
Le fichier ".gitignore" contient toute les règles d'exclusions.
# un commentaire, cette ligne est ignorée # pas de fichier .a *.a # mais suivre lib.a malgré la règle précédente !lib.a # ignorer uniquement le fichier TODO à la racine du projet /TODO # ignorer tous les fichiers dans le répertoire build build/ # ignorer doc/notes.txt, mais pas doc/server/arch.txt doc/*.txt
Inspecter les modifications indexées et non indexées
$ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: LISEZMOI # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # # modified: benchmarks.rb #
$ git diff
diff --git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..da65585 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
@commit.parents[0].parents[0].parents[0]
end
+ run_code(x, 'commits 1') do
+ git.commits.size
+ end
+
run_code(x, 'commits 2') do
log = git.commits('master', 15)
log.size
Cette commande compare le contenu du répertoire de travail avec la zone d'index. Le résultat vous indique les modifications réalisées mais non indexées.Comparer les fichiers indexés avec le dernier instantané.
git diff --cached (avec les versions 1.6.1 et supérieures de Git, vous pouvez aussi utiliser git diff --staged, qui est plus mnémotechnique).
$ git diff --cached diff --git a/LISEZMOI b/LISEZMOI new file mode 100644 index 0000000..03902a1 --- /dev/null +++ b/LISEZMOI2 @@ -0,0 +1,5 @@ +grit + by Tom Preston-Werner, Chris Wanstrath + http://github.com/mojombo/grit + +Grit is a Ruby library for extracting information from a Git repositor
Valider vos modifications
$ git commit
Éliminer la phase d'indexation
git commit -a
Mettre un commentaire
git commit -a -m 'added new benchmarks'
Resultat
$ git commit -m "Story 182: Fix benchmarks for speed" [master]: created 463dc4f: "Fix benchmarks for speed" 2 files changed, 3 insertions(+), 0 deletions(-) create mode 100644 LISEZMOI
Visualiser l'historique des validations
$ git log
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number
commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon <schacon@gee-mail.com>
Date: Sat Mar 15 16:40:33 2008 -0700
removed unnecessary test code
commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon <schacon@gee-mail.com>
Date: Sat Mar 15 10:31:28 2008 -0700
first commit
Gestion des TAGS
Lister vos tags
$ git tag v0.1
Créer des tags
$ git tag -a v1.4 -m 'my version 1.4' $ git tag v0.1 v1.4
Contenu d'un tag
$ git show v1.4
tag v1.4
Tagger: Scott Chacon <schacon@gee-mail.com>
Date: Mon Feb 9 14:45:11 2009 -0800
my version 1.4
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <schacon@gee-mail.com>
Date: Sun Feb 8 19:02:46 2009 -0800
Merge branch 'experiment'
LEs Branches
Une branche de base : "master"
Une branche est en fait un commit nommé.
Données d'un commit unique.
Données et objets Git pour des validations multiples.
Branche pointant sur le dernier commit. (trunk)
Création d'une Branche
$ git branch test
Le pointeur HEAD
Changer de branche
$ git checkout test
On modifie ensuite un fichier et on commit.
La branche sur laquelle HEAD pointe avance avec chaque nouveau commit.
On revient a la branche initial et on remplace les fichiers de la copie de travail.
$ git checkout master
On modifie ensuite un fichier sur master et on commit.
et paf !
On avait les branches maintenant on à l'arbre !
Pour Git, une branche n'est en fait qu'un simple fichier contenant les 40 caractères de la somme de contrôle SHA-1 du commit sur lequel elle pointe, les branches ne coûtent rien à créer et détruire. Créer une branche est aussi rapide qu'écrire un fichier de 41 caractères (40 caractères plus un retour chariot).Scott Chacon
LE MERGE
Lors d'un merge de branches, on peut être confronté à deux situations :
Le cas simple, sans conflit, appelé "fast-forward".
Le cas avec conflits, qui nécessite une étape de résolution de ces derniers, puis commit des corrections.
On merge toujours sur la branche principal !
(master dans la majorité des cas)
Le FAST FORWARD
$ git checkout master $ git merge my_branch Updating f42c576..3a0874c Fast forward LISEZMOI | 1 - 1 files changed, 0 insertions(+), 1 deletions(-)
LES CONFLITS
$ git merge my_branch Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.Les ennuis commencent...
Voir les conflits
[master*]$ git status index.html: needs merge # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # unmerged: index.html #
<<<<<<< HEAD:index.html <div id="footer">contact : email.support@github.com</div> ======= <div id="footer"> please contact us at support@github.com </div> >>>>>>> my_branch:index.htmlUn fois le(s) fichier(s) corrigé(s), on oublie pas d'indexer.
Le REBASE
Dans Git, il y a deux façons d'intégrer les modifications d'une branche dans une autre : en fusionnant (merge) et en rebasant (rebase).
Le rebase, consiste à ré-écrire l'historique de la branche, de manière à ce qu'il s'adapte à la dernière version de la branche sur laquelle on veut la merger.
Une fois l'historique ré-écrit, nous pouvons merger la branche, et aucun conflit ne peut alors intervenir, puisque le rebase aura fait en sorte, au préalable, de s'adapter à la dernière version de la branche destination.
On rebase toujours sur la branche secondaire !
$ git checkout my_branch $ git rebase master First, rewinding head to replay your work on top of it... Applying: added staged commandAprès gestions des conflits voila le résultat :
Une fois le rebase terminer on merge normalement.
Dans ce cas on se retrouve dans un cas de FAST FORWARD.
$ git checkout master $ git merge my_branch
Après merge standard :
Après un rebase et un merge :
Références
PRO GIT
Git, gestionnaire de version décentralisée
http://www-igm.univ-mlv.fr/~dr/XPOSE2008/git/gestionnaires.html
Site du Zero
Gérez vos codes source avec Git
Un petit jeu
Maintenant foncés !
Le chef est déjà prêt !
git
By nafresne
