1. Git
ou
le renouveau
du contrôle de version
Raphaël Rougeron
Conférence PHPQuébec 2009
2. A propos de moi
Raphaël Rougeron <goldoraf@gmail.com>
depuis... bien longtemps !
Expert technologies web chez
Contributeur d'
Framework Stato
http://stato-framework.org
http://raphael-rougeron.com
3. De quoi est-il question ?
Pas seulement de Git...
Mais du contrôle de version décentralisé :
Darcs
Mercurial
Bazaar
Et bien sûr Git !
4. Historique
Créé par Linus Torvalds en remplacement de
BitKeeper pour le noyau Linux
Pas un SCV à la base, mais un système de
gestion de l'évolution du contenu d'une
arborescence (locale)
A évolué depuis pour devenir un SCV à part
entière
Aujourd'hui maintenu par Junio Hamano
5. Grands utilisateurs
Noyau Linux
Perl
Samba
X.org Server
Qt
Rails
VLC
Android
6. Caractéristiques
Distribué : un quot;checkoutquot; récupère l'intégralité
de l'historique du dépôt
Support efficace du développement non-
linéaire (branching-merging)
Très rapide (confirmé par benchmarks)
Fiable : une corruption est facile à détecter
grâce à l'authentification cryptographique de
l'historique
7. Architecture
Ensemble de scripts bas-niveau (codés en C)
gitinit
gitupdatecache
gitwritetree
gitcommittree
Ensemble de commandes haut-niveau
git init
git add
git commit
Le dépôt est un dossier .git à la racine du projet
8. Git et Windows
Méthode quot;officiellequot; : Cygwin (pas simple)
Il existe cependant un fork de Git pour
Windows : msysGit
(http://code.google.com/p/msysgit/)
En cours d'intégration dans le dépôt Git officiel
10. Dépôt
Le dépôt (repository) est l'endroit où le SCV
stocke l'historique des changements du code
Dans les SCVs classiques, le dépôt est sur un
serveur (dépôt centralisé) : pour examiner
l'historique, il faut pouvoir y accéder
Avec git, le dépôt est local, dans un dossier .git
à la racine du projet
Chaque développeur envoie (push) ses
changements au dépôt principal
11. Arbre de travail
Votre vue sur une version spécifique du code
Les SCVs classiques appelent ça la copie de
travail (working copy)
2 possibilités pour l'obtenir :
Initialiser un dépôt en local
Cloner un dépôt existant : git va copier l'intégralité
du dépôt et faire un check out de sa branche
principale (master)
12. Workflow
Changements dans le code, exécution des
tests unitaires ;)
Commit des changements : création d'une
nouvelle version dans le dépôt avec un
message expliquant les changements
Envoi (push) des changements au dépôt
central
Sans oublier de régulièrement récupérer (pull)
les changements faits par les autres devs
13. Branches et tags
Les tags sont un cliché de l'état du code à un
instant donné (ex : les releases 1.0, 1.1, etc...)
Les branches sont des histoires alternatives du
code : elles marquent un point où les fichiers de
code divergent (ex : branches 1.x, 2.x, etc...)
Il est possible de fusionner (merge) les
changements faits d'une branche dans une
autre
19. Hashes
Les numéros de révision n'ont pas de sens
avec les SCVs décentralisés
Git utilise donc des hashes SHA-1 pour
identifier les commits (40 caractères)
Les hashes sont générés à partir de métadatas,
d'infos nominatives et du timestamp
Probabilité de collision : 1 / 263
On utilise en général seulement les 8 premiers
caractères
20. L'index ou quot;staging areaquot;
Etape intermédiaire entre la modification du
code et le commit
Permet une sélection fine des changements à
commiter
21. L'index ou quot;staging areaquot;
raphael@pygargue ~/code/notifier $ git status
# On branch master
# Changed but not updated:
# (use quot;git add <file>...quot; to update what will be committed)
#
# modified: public/index.html
# modified: public/index.php
#
no changes added to commit (use quot;git addquot; and/or quot;git commit aquot;)
raphael@pygargue ~/code/notifier $ git add public/index.php
raphael@pygargue ~/code/notifier $ git status
# On branch master
# Changes to be committed:
# (use quot;git reset HEAD <file>...quot; to unstage)
#
# modified: public/index.php
#
# Changed but not updated:
# (use quot;git add <file>...quot; to update what will be committed)
#
# modified: public/index.html
22. L'index ou quot;staging areaquot;
raphael@pygargue ~/code/notifier $ git add patch
diff git a/public/index.html b/public/index.html
index 88d0e04..4ee0dc2 100755
a/public/index.html
+++ b/public/index.html
@@ 2,7 +2,7 @@
<!DOCTYPE html PUBLIC quot;//W3C//DTD XHTML 1.0 Strict//ENquot; quot;http://
www.w3.org/TR/xhtml1/DTD/xhtml1strict.dtdquot;>
<html xmlns=quot;http://www.w3.org/1999/xhtmlquot; xml:lang=quot;enquot;
lang=quot;enquot;>
<head>
<title>Notifier : test de l'API</title>
+ <title>Notifier</title>
<script src=quot;js/jquery1.2.3.jsquot;
type=quot;text/javascriptquot;></script>
<script src=quot;js/notifier.jsquot; type=quot;text/javascriptquot;></script>
<script src=quot;js/wsse.jsquot; type=quot;text/javascriptquot;></script>
Stage this hunk [y/n/a/d/?]?
34. Cheap local branching
Tout est traité comme une branche avec git
Créer une branche est donc quot;bon marchéquot;
On peut donc créer une branche temporaire
dans de nombreux cas :
Expérimentations
Nouvelles fonctionnalités
Bug fixes
35. Merging
Action de combiner l'historique de 2 branches
3 types :
Straight merges : tentative de combiner les 2
historiques
Squashed commits : compresse l'historique d'une
branche dans un commit appliqué sur une autre
branche
Cherry-picking : extrait un commit d'une branche et
l'applique à la branche courante
39. Particularités de git-diff
Détection des renommages, copies,
suppressions
Permissions
Liens symboliques
Contenu des binaires
etc...
40. Rebase
git-rebase permet d'incorporer l'historique d'une
branche dans une autre en rejouant les
commits
Les commits rejoués apparaitront donc comme
s'ils avaient toujours fait partie de la branche
git-rebase -i permet de réécrire l'histoire :
Changer l'ordre des commits
Fusionner des commits
Scinder un commit en plusieurs !
43. Ressources
git.or.cz
Manuel
http://www.kernel.org/pub/software/scm/git/docs
#git sur Freenode
Pragmatic Version Control using Git
par Travis Swicegood
