3. Pourquoi un nouvel Outil de Gestion de Source ?
SVN est un outil des années 2000, mais repose sur
des concepts des années 80
SVN a été écrit pour améliorer les insuffisances de CVS
CVS a été écrit en 86
Lui-même une réécriture de RCS (1982), et de SCCS (72)
7. GIT : Key Facts
Clés/Exemple de succès
Ecrit par Linus Torvald !
Héberge ses propres
sources au bout de 5 jours
• 1 an pour SVN
GitHub qui héberge 5
millions de repository
8. GIT : Philosophie
GIT a été réécrit avec la philosophie suivante
Supporter un workflow distribué
Développement non linéaire
Intégrité : gros support de sécurité sur la
corruption de données, et les accidents. GIT est
robuste
Performance ! (Héberge le noyau Linux, et les
dizaines de milliers de patchs)
• Quasiment toutes les opérations sont locales
Prendre en exemple CVS et SVN ce qu’il ne faut
pas faire. En cas de doute, prendre la décision
opposée
Rôle de Développeur et de Mergeur (2
informations différentes)
9. Inside GIT : SHA-1 (Algorithme de hachage)
SHA-1 assure l’unicité des objets
2 SHA-1 identiques => Fichiers identiques
Probabilité de collision :
• 50% : si 6.5 milliards d’humains committent toutes les secondes
pendant 5 ans l’ensemble de l’historique du noyau linux (1 million
d’objets)
• Autrement dit, il est plus probable que tous les développeurs
d’une équipe soient attaqués et tués par des loup-garou la même
nuit dans des circonstances différentes …
10. Inside GIT : Stockage interne (1)
Stocké sous
forme de DAG
(Direct Acyclic
Graph)
14. Enjeux
Inverser la logique
Avec SVN, on cale nos processus par rapport aux possibilités
de l’outil
En GIT, tous les workflows sont quasiment possibles, on utilise
l’outil tel qu’on souhaite suivre le processus (et notamment
TFS).
• PAS UNE RAISON POUR MONTER UNE USINE A GAZ !
• Et surtout beaucoup de nouvelles possibilités …
15. Enjeux
Exemple d’écueil qu’on souhaite éviter
Performance : switch / checkout trop long
Merges compliqués
Déplacement /renommage de dossiers
successifs (erreurs fréquentes svn)
Problèmes des Changes Set et des relectures
dans le support
Phase de freeze de code
Committer souvent (bonne pratique)
implique d’être connecté
On est obligé d’être connecté pour travailler
16. Problème résolus (1)
Performance : Switch / Checkout de Branche
Le switch de branche est long et nécessite d’être connecté :
• Ex: ITS :trunk -> R2Dx_AzureFederation
(+516 fichiers, - 282 fichiers, <> 335 fichiers)
- SVN : 24 secondes (réseau interne)
- GIT : 1 seconde (déconnecté)
Recherche d’historique sur 1 an
• Ex : ITS : trunk : TestErrorController.cs
- SVN : 4 minutes
- GIT : 1 seconde
• Le risque est alors de changer de
workflow classique et de travailler
sur le tronc directement ….
17. Problème résolus (2)
Merges compliqués
En SVN, uniquement mode « merge »
En GIT, « merge » ou « rebase »
• nombreuses options qui sauvent la vie
• Le merge est équivalent à svn merge
• Le rebase permet de faire comme si on
réappliquait le développement de la
branche au fur et à mesure (update).
18. Renommage successifs
Git ne fonctionne pas par différence comme svn, mais par snapshot
Il n’essaie pas de tracer les renommages successifs, mais travaille plutôt sur le
contenu pour tracker les renommages. Cela le rend beaucoup plus robuste que svn
sur ce point.
SVN GIT
Problème résolus (3)
19. Problème résolus (4)
Problème des changeSets
Remplacé par des petites branches
La relecture de code devient asynchrone
et peut être faite sans merger
directement sur la branche ou sans
switcher de branches
Il n’y a plus de ChangeSets, l’opération
de création de branche de livraison et
de merge est tellement rapide qu’elle ne
justifie pas de sortir du worklow
standard
20. Problème résolus (5)
Freeze de code / stabilisation
Essentiellement lié au manque
d’espace intermédiaire d’un espace
d’intégration.
L’utilisation de repository
intermédiaire permet de résoudre le
problème (voir slide Workflow
proposé).
24. Manipulation Graphique et Commandes GIT
Toutes les commandes (sauf options très spécifiques) ont
un équivalent dans les outils suivants:
TFS
Tortoise GIT
GIT Extensions
Xcode
Autres clients …
Dans la suite de la présentation, par souci de concision, nous
préciserons les commandes « Dos »
Parfois effectue plusieurs commandes en 1 seule
• Sélection des fichiers + Commit par exemple
• Fetch + rebase = pull rebase
25. Git : clone (opération distante)
REMOTE origin/master
origin/master
Image « locale »
de la branche
distante
Branche
distante
A B C
master
A B C
origin/master
git clone git://github.com/dummy
LOCAL
26. Git : commit (opération locale)
REMOTE origin/master
origin/master
master
Image « locale »
de la branche
distante
Branche locale
Branche
distante
AVANT
APRES
LOCAL
A B C
master
A B C
origin/master
A B C
mastergit commit -m « message de commit »
A B C
master
D
27. Git : fetch (opération distante)
REMOTE origin/master
origin/master
master
Image « locale »
de la branche
distante
Branche locale
Branche
distante A B C
master
A B
A
AVANT
B
APRES A B C
origin/master
origin/master
git fetch origin
master
LOCAL
28. Git : push (opération distante)
REMOTE origin/master
origin/master
master
Image « locale »
de la branche distante
Branche locale
Branche
distante
A BAVANT
APRES A B C
master
master
git push origin master
A B C
origin/master
A B C
master
LOCAL
29. Git : merge (opération locale)
AVANT A B C
D E
G H
master
experiment
A B C
On a démarré une branche d’expérimentation
à partir de « C », entre temps, des modifications
ont eu lieu sur la branche master. On souhaite faire
apparaître qu’il y a eu un merge depuis experiment
vers master
APRES
G H
experiment
D E
master
I
« I » est un nouveau commit appelé
« commit de merge »
git merge master
30. Git : rebase (opération locale)
AVANT A B C
D E
G H
master
experiment
A B C D E G’ H’
master experiment
On a démarré une branche d’expérimentation
à partir de « C », entre temps, des modifications
ont eu lieu sur la branche master. Idéalement,
on souhaiterait faire « comme si » on avait
démarré la branche expérimentation à partir de « E »»
Le rebase va « linéariser le développement »
Les commit « G » et « H » se transforment
en G’ et H’, Il y a réécriture de l’historique
APRES
git rebase master
31. Le rebase en mode fast-forward va faire
comme si on était reparti de « H » pour faire
la branche d’expérimentation. Les commit
ne sont pas modifiés. C’est un simple déplacement
de référence.
Git : rebase/merge : Cas du Fast Forward
AVANT A B C
G H
experiment
master
A B C G H
master
experiment
On a démarré une branche d’expérimentation
à partir de « C », entre temps, des modifications
ont eu lieu sur la branche master. Aucun commit
n’a été fait sur la branche experiment
git rebase master
32. Ressources utiles
Livres
Progit : http://git-scm.com/book (gratuit)
GIT en général
http://fr.wikipedia.org/wiki/Git
http://en.wikipedia.org/wiki/GitHub
http://git-scm.com/
http://youtu.be/4XpnKHJAok8?t=22m0s : Tech Talk : Linus Torvalds on git
Vidéos au JUG :
• http://parleys.com/play/514892280364bc17fc56c1f8
• http://parleys.com/play/514892280364bc17fc56c1fa
PluralSight : 2 présentations de 3h sur GIT
Git et SVN
https://git.wiki.kernel.org/index.php/SvnMigration
http://git.or.cz/course/svn.html