“Pour apprendre il faut pratiquer, pour comprendre il faut expliquer” ça ne doit pas être la citation exacte mais l’idée est là et s’applique parfaitement à GIT. Il n’y a qu’à voir le nombre de blog de geek qui éprouve l’envie irrésistible de faire un billet sur ce sujet. Je n’échappe pas à la règle, après quelques mois de pratique de ce DVCS.
Même si certain recommande de tout oublier de svn avant de se mettre à git je préfère pour ma part démarrer par une comparaison des concepts
Les concepts de SVN
Un repository svn ne gère que 3 types d’objets:
- répertoire
- fichier (ou plutôt la différence d’une version à une autre)
- revision
Les revisions sont numérotées de 1 à n, elles se suivent de manière linéaire. Chaque révision pointe vers un arbre décrivant l’état du projet. Les branches et les tags n’existent pas dans un repository svn. Ce ne sont que des répertoires désignés comme branche ou tag uniquement PAR CONVENTION.
Voir bubble up method pour approfondir
Les concepts de GIT
Un repository git gère 4 types d’objets
- tree (répertoire en svn)
- blob (fichier en svn)
- commit (revision en svn)
- tags
Et en plus des références qui sont utilisées pour désigner les branches On distingue les références des objets car ceux-ci sont immuables alors que les références sont volatiles (i.e.: HEAD est une référence qui peut pointer sur n’importe quel commit alors qu’un objet sera toujours identifié par le hash SHA-1 de son contenu).
Le stockage de cette structure est si bien optimisé que tout l’historique d’un gros et vieux projet ne prend pas plus de place qu’un seul checkout svn.
Mais surtout cet historique n’est pas linéaire comme celui de svn. Les commit sont stockés dans une structure en graphe (un DAG pour être précis). Un commit peut avoir un ou plusieurs parents (commit avec plusieurs parents == commit de merge). Cette structure en graphe reflète de manière fidèle la notion de branche.
Voir getting git pour appronfondir
Workflow de SVN
Svn est extrêmement simple, il y a le repository central et des checkouts partiels en local. Les seules commandes à connaitre pour débuter sont les suivantes:
# copier une révision du projet en local
svn checkout http://monprojet/trunk
# génèrer une nouvelle révision sur le serveur dont l'identifiant sera incrémenté de 1 par rapport à la revision précédente
# Par exemple: touch newFile.txt
svn commit
# mettre à jour son projet en local
svn update
La structure et le workflow simplistes de svn font qu’une bonne pratique est d’utiliser le moins de branches possible, tout simplement car les merges sont longs et risqués.
Workflow de GIT
GIT est un DVCS, donc distribué: il peut y avoir plusieurs repository égaux entre eux. Mais de manière pratique on désigne souvent par convention un repository comme central. On a donc
- un repository central
- des repositories locaux (contient les mêmes infos que le central)
- des workspace locaux (contient un checkout d’un commit du repo local)
- des index (contient les prochaines modifications à commiter)
- des stash
Une utilisation classique de git est donc la suivante
#dupliquer un repository en local
git clone
#Création d'un branche (MonDevAmoi = nom de ma nouvelle branche, créée à partir de la branche nommée BrancheDeReference)
git checkout -b MonDevAmoi BrancheDeReference
#Ajout des modifications dans l'index
git add ...
#commit de l'index dans le repo local
git commit ...
#récupération d'éventuelles modifications sur le repository central
git fetch
#merge de ces modifications avec notre branche
git merge
#Partage des modifications locales avec le repository central
git push
Avantages de git
Après cette présentation on se rend surtout compte que git est plus complexe. Quels avantages apporte cette complexité?
Rapidité
Toutes les opérations se font en local, git est plus rapide de plusieurs ordres de grandeur.
Merges rapide et facile
La structure de données de git a été pensée pour répondre à ce besoin, git est bien plus intelligent que svn sur ce point. Il devient possible de faire des feature branch et d’envisager des workflows évolués
Un historique propre
C’est tout de même la fonctionnalité principale d’un système de gestion de code: conserver l’historique. Conserver l’historique c’est bien, avoir un historique propre et utile c’est mieux. Combien de repository svn sont pollués par des commits du type “oups erreur lors du merge” ou “oublié de commiter un fichier” ?
Git ne résout pas ce problème de manière magique mais il donne les outils pour améliorer la situation
L’index est l’espace où l’on ajoute les modifications que l’on va commiter, il formalise une bonne pratique qui consiste à préparer et valider un commit avant de le faire réellement.
- La modification d’un commit:
Mais même avec l’index, il reste difficile de faire des commits “parfait”. Un fois un commit créé il est impossible de le modifier (signé avec un SHA-1) par contre il est tout à fait possible de le supprimer pour le remplacer par un autre tant que l’on a pas “pusher” ses commit vers un repo distant. C’est le git commit amend qui permet de modifier un commit existant.
- La revision de l’historique:
Et si ce n’est pas suffisant git squash et rebase permettent de manipuler l’historique lorsque l’on merge des branches.
Par exemple une feature branch qui contient des dizaines de commit peut se transformer en un seul commit lorsqu’on la merge dans la branche principale.
Il faut l’essayer pour comprendre. La fonction phare de github est la pull request qui exploite à merveille les capacités de merge de git. La pull request est aussi le moment idéal pour faire un code review.
Inconvénients de git
La courbe d’apprentissage: il faut investir en formation pour bénéficier pleinement de git.
L’outillage, par encore aussi mature que ce qui est disponible pour svn mais ça viendra, pour l’heure la ligne de commande est ton amie.
Git Flow VS pull request
Git permet de mettre en oeuvre de nombreux modèles de développement. Deux en particulier ont émergé: Git Flow et github pull request. Le premier est plus orienté workflow d’entreprise aux release régulières mais espacées, le deuxième est adapté aux projets open source, de nombreux contributeurs et un nombre restreint de “committers” qui valident les développements.
Mais rien n’empêche d’utiliser les deux: On peut très bien pusher vers github les features branchs de git flow. Et faire une pull request sur celle-ci pour les merger sur develop.
C’est la grande force de git on peut imaginer et mettre en oeuvre toute sorte de workflow, un autre exemple pour la route.
Pour aller plus loin
UPDATE: Think like (a) git est de loin le meilleur tuto sur git
Je maintien une liste de délicieux liens à propos de git mais la meilleure façon de se documenter sur Git est probablement de googler Scott Shacon, employé de github c’est l’évangéliste n°1 de git il a entre autre commis:
Mais si vous en avez assez de la théorie voici pour la pratique
