Comprendre Git en 7 minutes
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 !
> Il bosse dessus depuis 2002
En fait Linux bosse sur Linux depuis 1991 😉
Bon article d’introduction à Git sinon, même si je suis pas forcément fan des rebase, surtout chez les débutants ^^
En effet ! C’est corrigé 🙂
Merci pour cette article. Je préfère recommandé l’utilisation de `git switch` et `git restore` à la place de `git checkout`. La commande `checkout` est trop générique et perd les gens imo
Un peu déçu par cet article. Tout le monde connait git, l outil est assez simple à utiliser et la doc est assez clair
Vous avez tous des niveaux d’expertises et de connaissances radicalement différents. J’arriverais JAMAIS à contenter tout le monde à chaque sujet. Donc oui, parfois tu vas voir un article pas taillé spécialement pour toi. Il en faut pour tout le monde !
Excellent article. Et quand on pense que quelque chose est « connu de tout le monde », il faut savoir que 10 000 américains l’apprennent tous les jours (ça correspond au nombre de naissances par jour…)
merci même si j’ai rien appris sa donne une ressource claire pour les débutants
Tout le monde le connaît et personne ne sait l’utiliser correctement. Et je ne parle pas des gens qui débutent en développement pour qui c’est clairement LA bête noire. Il ne faut pas oublier que ce n’est pas parce que quelque chose est simple une fois qu’on le maîtrise qu’il l’est de base. Je pense que 90% des gens qui découvrent Git passent quand même pas mal de temps à se taper la tête contre les murs quand ils font quelque chose de travers.
Bien d’accord avec ça !
C’est bien de dire les choses telles qu’elles sont. Nombre de gens qui connaissent Git un tant soit peu ne tarissent pas d’éloges sur cette réalisation de Linus Torvalds. Effet Gourou oblige. Personnellement je ne comprends pas qu’on ait pu laisser passer un jeu de commandes aussi abscons… Le propre d’une commande c’est de dire ce qu’elle fait et ne pas donner lieu à cent cinquante mille options (comme c’est le cas pour netstat malheureusement). Par ailleurs il y a des conditions de complétude dont il faudrait tenir compte. Git est donc un produit qui nous renvoie à une autre ère. Vivement qu’il y ait mieux comme standard incontesté…
Top cet article ! Pour le rebase interactif je préfères faire : git rebase -i master. Comme ça pas besoin de compter le nombre de commits que je veux, ils sortent tous. Très pratique avant un gros push.
Pour moi ce qui à fait la force de Git c’est l’écosystème qui s’est mis en place tout autour. Les Github,Gitlab Bitbucket & co on très vite proposé des outils plutôt très cool qui était quasi inexistant avec les autres VCS.
C’est ce qui nous à fait basculer de SVN à GIT il y’a presque 5 ans maintenant.
@Thomas , je crois que tu serais extrêmement surpris du nombre de boite qui travail avec des VCS de l’age de pierre voir même sans … Plus de la moitié des stagiaires qu’on reçois n’on jamais fait de git de leur vie.
D’où viennent ces stagiaires ?!
Suis pas stagiaire,ais j’ai rarement bossé en équipe. Donc presque jamais eu besoin d’outils de versionming et autres…
Là faut que je m’y mette (ENFIN!!!)
c’est pas parce que tu n’as jamais bosser un équipe qu’une gestion de versionning ne servait à rien. « on a toujours fait comme ça » bonjour
Même juste avec une branche master et une dev, en bossant tout seul sur un projet, je t’assure qu’on en voit très vite l’utilité ! Pouvoir séparer son projet en plusieurs branches, rapidement revenir à une version antérieure en cas de bug, c’est super pratique !
Hello,
Il y a quelques années, nous étions 4 dév dans le même espace. C’était fatigant de demander « personne n’est sur tel fichier ? ». Je ne comprends pas pourquoi notre lead dév ne voulait pas s’y mettre. Peut-être par crainte de voir son VCS maison oublié…
Très bon article à relayer.
M****: c’est l’apéro… du coup plein de fautes de frappe, désolé ^^
Le fait de mettre le suffixe “feature/” dans le nom est une bonne pratique.
Suffixe –> Préfixe plutôt me semble-t-il ? 🙂
Super article pour connaître les bases rapidement !
Super intéressant, merci beaucoup.
Je suis pas dev, mais je m’y intéresse depuis longtemps et je tente de suivre ce qui se fait. Et des articles de vulgarisation comme çà sont toujours efficaces pour moi.
Merci pour tous tes articles du coup 🙂
Bonjour,
L’article est super, j’aurais ajouté un git merge pour fusionner le boulot sur la branche principale, cela fait parti des gestes très fréquents ?
Keep On, Keepin’ On
« 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. »
La fable open source est jolie… mais non. La création de Git est la conséquence d’une trahison: la société bitkeeper avait permis une utilisation de son système a condition qu’il n’y ait pas de tentative de retro engineering. Or a un moment dans la base de donnée il y a commencé a y avoir des grosses anomalies…. Ce qui etait la preuve qu’un retro engineering etait en cours et c’est pour cette raison qu’ils ont retirés la licence dont profitait les développeurs du noyau.
Linus a codé git en un coup de vent pour récupérer le coup. Et cela explique en partie le monde surréaliste des options git… A comparer avec les options de mercurial. Pour connaître un commiter git lui même reconnaît que c’est le souci numero 1.
Hello,
Super article, bien vulgariser pour aider à comprendre cet outil un peu abstrait au début.
Une commande que j’utilise assez régulièrement lorsque j’ai commencé un développement sur la mauvaise branche et que je veux changer de branche en gardant mon travail : git stash (créer un « commit » temporaire pour sauvegarder les modifications faites) et git stash apply après avoir changé de branche pour appliquer les changements à cette nouvelle branche.
Merci encore pour ton article, au top !
Hahaha… Git… depuis le temps que j’attends de l’utiliser pour autre chose que des projets persos ou des tutos… Au boulot on est encore coincés avec SVN, parce que hiérarchie qui traine des pieds (sont tellement conservateurs qu’on pourrait les utiliser pour remplacer un frigo), certains devs que Git effraie, et surtout la tripottée d’outils qui sont calés sur SVN et qu’il faudrait modifier. Disons que c’est prévu, plus ou moins en cours, mais c’est pas demain la veille que ça arrivera. Et encore, là, au moins, on en a un, de cvs.
Du coup je me contente de bricoler avec de mon coté.
Salut !
Merci pour tes articles 🙂
Question qui n’a rien à voir avec Git : comment réalises-tu tes gif ?
Celui que tu as fais sur cette page est très réussi !
@+
J’utilise le logiciel gratuit ScreenToGif !
Merci à toi et longue vie à ton blog 😀
Merci pour cette article simple qui m’a bien éclairé. (moi débutant sur ce sujet 😉)
Beaucoup de développeurs ne connaissent pas réellement git et utilisent les raccourcis qu’on peut avoir sur un éditeur (hello Visual Studio Code). En même temps on oubli qu’on en a fait quelques cauchemars le jour où on a dû apprendre à l’utiliser. Rien de mieux qu’une bonne formation ou qu’un bon article comme ça pour mieux y parvenir.