Git est l’outil par excellence que tout développeur doit maîtriser. C’est 36 millions d’utilisateurs et 90% de part de marché. Si t’es pas parfaitement au point sur cette merveille, ça vaut le coup d’investir sept minutes de ton temps.
Il était une fois
Nous sommes en avril 2005 et la légende vivante Linus Torvald travaille énormément sur son bébé : Linux. Il bosse dessus depuis 1991 et tu l’imagines : le projet est énorme. Y’a beaucoup de code. Y’a encore plus de monde qui travaille sur ce code. Pour gérer tout ce bordel, Linus était partie sur le système de gestion de versions BitKeeper.
Le problème avec BitKeeper c’est que c’est d’abord un logiciel propriétaire. Déjà, ça énerve une partie de la communauté open source autour de Linux. En plus, la version gratuite vient avec des contraintes très pénibles. Comme si ça suffisait pas, du jour au lendemain, la version gratuite de BitKeeper est retirée.
Immédiatement, Linux Torvald rage et décide de carrément coder son propre système de versionning. Le développement ÉCLAIR de Git était sur le point de commencer.
Le 3 avril 2005 Linus commence à bosser sur Git. Le 6 avril 2005 il envoie un mail rempli de rage où il annonce qu’il travaille sur une solution de remplacement. Le 18 avril 2005 les premiers merges de branches fonctionnent ! Le 29 avril 2005, Git commence à être utilisé dans certaines parties de Linux. Le 16 juin 2005 Git gérait entièrement la version 2.6.12 de Linux.
Peu de temps après, Linus décida de filer les clefs à Junio Hamano qui en fit une version 1.0 déployée le 21 décembre 2005. Aujourd’hui, Git est absolument partout.
C’est quoi Git ?
Git est un système de contrôle de version open source. Concrètement, c’est un outil qui te permet de traquer tous les fichiers de ton projet. Chaque modification de fichier est alors détectée par Git et versionnée dans une version instantanée. Un historique de modification va être disponible sur ton projet. Tu vas pouvoir le consulter et pourquoi pas même revenir en arrière dans le temps !
Git est un outil qui va te permettre de savoir qui a touché à quel fichier, quand et comment. Imagine, t’as 2000 fichiers et 5 développeurs qui travaillent en équipe dessus.
- Comment tu sais qui a fait quoi et quand ? Le versioning de Git va te permettre de le savoir.
- Comment t’es sûr que les développeurs ne se gênent pas en touchant les mêmes fichiers en même temps ? Encore une fois, Git à la rescousse avec son système de branches.
Chaque développeur va pouvoir travailler en parallèle avec leur propre copie du projet sur une branche personnelle. Une fois leur travail fini, les copies de travail seront fusionnées !
En plus de ça, contrairement à certains de ces concurrents, Git est décentralisé. Ça veut dire que l’historique des fichiers est présent dans chacune des machines où se trouve le projet. Ce qui diffère d’une architecture centralisée où tu peux pas faire grand-chose sans un seul serveur qui gère tout.
Bon, c’est peut-être pas encore tout à fait clair, regardons comment ça marche !
Comment ça marche ?
La première chose à comprendre avec le fonctionnement de Git c’est qu’il fait des instantanés (snapshots en anglais) de ton projet pour le versionner. Là où les autres systèmes de versioning comme Subversion et Perforce vont faire des diffs sur chaque fichier. Cette différence est importante. Elle va permettre à Git de se distinguer côté performance et travail de développeur en parallèle via les branches !
Secondes choses à bien comprendre avec Git : les zones de travail. Il y a plusieurs zones où les fichiers de ton projet vont vivre dans Git. C’est super important de comprendre cette partie pour ne pas être perdu.
On trouve trois zones bien distinctes en local sur ton poste de travail.
- Zone de travail (Working Directory) : c’est là où ton dépôt git est initialisé et que tes fichiers vivent. C’est dans cette zone que tu touches à tous tes fichiers pendant que tu bosses. Une fois que tu veux versionner une version de ton projet, tu vas alors taper la commande « git add <fichier> » pour passer un fichier à la zone suivante.
- Zone de transit (Staging Area) : la zone de transit est un endroit pour désigner les fichiers que tu veux versionner. Tu peux voir la commande « git add » comme une manière de mettre des objets dans un carton. Une fois que tu as désigné tout ce que tu voulais mettre dans ce carton, il sera prêt à être envoyé au dépôt avec la commande « git commit ».
- Dépôt local (Local Repository) : la zone de dépôt c’est là que les fameux instantanés de ton projet sont versionnés et stockés. Le truc important à comprendre c’est qu’une référence de version est créée pour chaque commit que tu fais. Chaque commit est donc une version de ton projet unique qui va vivre dans le dépôt et que tu pourras consulter/comparer quand tu voudras !
Et pour le moment on est resté sur ton poste de travail. Une fois que t’as versionné comme tu le voulais tu vas pouvoir partager ton travail en le poussant sur le dépôt remote via un « git push ». Avant de t’expliquer tous ces trucs de fifou, dessin !
Ce sont les quatre commandes que tu vas utiliser tout le temps et c’est le flow que tu vas avoir en permanence. Maintenant, tu vas forcément bosser avec d’autres développeurs. Pour bien gérer ça, il va falloir que tu utilises les branches.
Fais voir les commandes
Pour installer Git, tu trouveras ton bonheur ici. Pour la petite démo, on va imaginer un scénario. Ça va pas être dur à imaginer : c’est ce qui va t’arriver en permanence.
- 1 : Mettre à jour la branche principale
- 2 : Faire une branche pour bosser dans ton coin
- 3 : Faire plusieurs commits
- 4 : Réduire ces commits en un seul commit
- 5 : Pousser tes changements sur le dépôt remote
Je pars du principe que tu as déjà un dépôt Git en local que tu as cloné d’un dépôt distant via la commande git clone. Commençons par mettre à jour la branche principale. Au moment où j’écris ces lignes, par défaut, git nomme sa branche principale master. Dans le futur, ça va surement changer. Pour que tu sois pas perdu la première fois, j’utilise le nom par défaut.
git pull origin master
On utilise la commande git pull pour mettre à jour notre dépôt local avec les updates du dépôt distant. Ensuite, on crée une branche.
#version longue git branch feature/learn-git git checkout feature/learn-git #version courte git checkout -b feature/learn-git
Grâce à la commande git checkout -b on va créer une branche (une copie de la branche principale) et se placer dessus automatiquement. J’utilise le nom feature/learn-git ici. Le fait de mettre le suffixe « feature/ » dans le nom est une bonne pratique que tu devrais prendre quand tu crées une branche pour faire une feature.
Quand tu bosses avec Git il est également conseillé de commit fréquemment. C’est ce qu’on va faire ici.
# t'es censé bosser sur des fichiers ici git add . git commit -m "I'm learning git !" # t'es censé bosser sur des fichiers ici git add . git commit -m "WIP" # t'es censé bosser sur des fichiers ici git add . git commit -m "WIP"
Avant de pousser sur le dépôt distant, on va clarifier notre travail en réduisant le tout à un commit avec un message clair.
git rebase -i HEAD~3
git rebase va te permettre de réécrire l’historique des commits de ta branche. Le flag -i te permet de le faire de façon interactive. HEAD~3 te permet de le faire sur les trois derniers commits.
Ça va t’ouvrir une fenêtre dans laquelle tu vas indiquer que tu veux « squasher » les deux derniers commits dans le premier. Puis, une seconde fenêtre où tu vas redéfinir le message du commit final. C’est un peu compliqué alors je t’ai fait une démo via un Gif !
Enfin, il ne reste plus qu’à pousser ta branche toute propre sur le dépôt distant !
git push origin feature/learn-git
Et voilà ! Tu as les bases pour utiliser Git partout !
Épilogue
Comme d’habitude, cinq minutes c’est trop court du coup on est passé à sept minutes aujourd’hui. J’espère t’avoir donné envie d’en apprendre plus sûr cet outil fabuleux que tu vas utiliser tous les jours. Un article avancé sur Git arrive dans les mois qui viennent. On va parler de git flow et de commandes plus pointues comme git bisect, reflog et cherry-pick !
clearfix