Aaah, c’est ce fameux moment du mois, le moment de #BTW ! Aujourd’hui, on va parler de versioning avec Git ! Si tu ne sais pas ce que c’est, attache ta ceinture et embarque avec moi, je vais t’expliquer !

I. Git, c’est quoi ?

Avant d’expliquer concrètement ce qu’est le versioning, il me semble préférable d’expliquer dans un premier temps à quel problème ça répond. Je vais donc te poser une question : Ça ne t’ai jamais arrivé de perdre un fichier, un bout de code, un PSD, ou n’importe quoi ? Si hein … Et peut-être même que ma question a provoqué cette réaction chez toi :

Je sais. C’est dur. Quand ça t’arrive, tout ce dont tu as envie c’est de faire l’autruche et espérer que le monde oublie que tu as 42 rendus à faire basés sur cet unique fichier sur lequel tu avais travaillé 28h et que tu viens de perdre. Quand il s’agit de fichiers, on te recommandera d’utiliser un service de cloud comme par exemple Dropbox ou Google Drive et j’en passe. Et tu pourrais faire la même chose pour tes projets web, mais ce n’est pas le plus pratique quand tu as tout ton code sur ton serveur local. C’est là qu’entre en scène le versioning avec Git ! C’est une sorte de cloud pour le code. Et c’est pratique puisque tu peux « installer » ce service dans n’importe quel dossier de ton ordinateur. Tu n’as pas besoin de tout regrouper au même endroit.

D’autres problème dont je vais parler, ceux engendrés par la collaboration. Imagine, il vous reste une semaine à toi et ton équipe de choc pour finir votre site de PTPMU, et vous devez tous mettre la main à la patte, autrement, vous ne serez jamais dans les temps. Machin va faire l’intégration, Truc va faire le dev’, et Chouette va faire les interactions JS/jQuery. Le plan parfait, hein ? Jusqu’au moment où Machin va foirer la moitié du code de Truc et Truc va écraser 3/4 des modifs que Chouette a fait. Et là, on revient à la case départ.

C’est donc ici que la notion de collaborative code devient intéressante. Dans ce cas précis, où tu es un peu forcé de travailler simultanément avec d’autres développeurs, tu as deux solutions : soit de te coordonner à la perfection (et 9 fois sur 10 d’échouer lamentablement), soit de mettre en place un système de code collaboratif, et Git est le numéro 1 pour ça. Il va rendre possible à chaque personne de partir de la même base, mais surtout chacun sur sa propre branche et de faire ses modifs. Une fois toutes les modifs terminées pour l’équipe, vient le moment très délicat du merge (= le moment où vous allez mixer vos modifications et définir qui doit écraser quoi ou qui ne doit pas écraser quoi) donc déterminer quels fichiers vont être mixer (par exemple, le fichier index.html final gardera les modifs du dev comme de l’inté ! En gros ça va mélanger les 2 fichiers quoi).

Enfin, le dernier avantage de Git, c’est que tu peux versionner ton code, ce qui signifie que, si à ta dernière modif tu as tout cassé et qu’il n’y a plus rien qui marche, alors au lieu de pleurer tu pourras revenir à la version précédente de ton code ! Pendant que tu travailles sur ton projet, tu définis des « points d’arrêts » (qu’on appelle des commit) quand tu sais que ce que tu as fait, ça marche. Et à tout moment, tu peux revenir à n’importe quel point d’arrêt ! C’est pas magnifique ça ?

Maintenant que tu sais à quoi correspond Git, on va passer à des trucs un peu plus concrets, et surtout on va un peu jouer aux mythbusters aujourd’hui !

II. Git ≠ Github !

NON. Git, ce n’est pas seulement GitHub. Avant tout, sache que Git ce n’est PAS un site qui propose un service, c’est le service en lui-même, c’est le système ! Ce système est utilisé par plusieurs sites, dont GitHub qui est le plus connu. Ca ne signifie pas que c’est le meilleur pour autant. Il en existe plusieurs et chacun possède ses avantages et inconvénients. Personnellement, je n’en connais et utilise que deux, donc je ne parlerai que de ces deux là. Si tu veux avoir un éventail plus large, je te conseille de checker cet article qui compare très bien 12 services basés sur Git. Il est très important que tu saches que les services de Git s’emploient généralement via ligne de commande / terminal ! Mais attends, ne fuis pas, parce qu’il existe des solutions pour se faciliter la vie !

Github

Le numéro 1 mondial des plateformes de code collaboratives. Mais j’ajouterai que GitHub a déjà des contraintes notamment pour les grands projets. En effet, c’est bien quand tu es une entreprise ou que tu as du budget, mais autrement, c’est contraignant pour une raison particulière : Les « projets » (repository ou repoprivés ne sont pas gratuits ! Ca veut dire que,  lorsque tu vas créer un repository sur GitHub, avec un compte « gratuit », il sera public et visible par n’importe qui. Ce qui n’est pas toujours l’idéal dans des contextes compétitifs (petites entreprises en compétition sur un même projet, appels d’offre, …). Si tu veux pouvoir créer des repo privés, il faudra débourser au bas mot 7$ / mois … Et pour cette somme, tu auras seulement 5 repo. Cependant, si tu es étudiant, tu as le droit à des features gratuites, donc profites-en ! Pour le dernier point, il faut savoir que GitHub possède son propre client graphique pour utiliser le service, ce qui est plutôt pas mal ! Mais tu verras que ce n’est pas le point le plus important dans ce domaine.

Bitbucket

Je ne sais pas vraiment où Bitbucket se place par rapport à ses concurrents, mais dans mon coeur en tout cas il est numéro 1 ! Il est simple d’utilisation, donne la possibilité de créer autant de repo privés que l’on souhaite, et s’intègre très bien avec les solutions d’interface graphique (qui permettent d’éviter la corvée de lignes de commandes qui fait si peur à tellement de gens). Il possède probablement des inconvénients quand on l’utilise à son maximum, mais pour une utilisation simple (collaboration à 2 / 3, repo privés), tu auras du mal à te dire que c’est la faute de Bitbucket si la faim dans le monde n’est toujours pas résolue.

 

Bon, tout ça c’est bien beau, mais la ligne de commande c’est difficile quand on ne connaît pas trop, donc comment faire ? C’est quoi ces interfaces graphiques ?

Pour ce point, c’est pareil. Je ne vais pas faire un catalogue de tout ce qui existe, mais parler de ce que je connais, à savoir Sourcetree qui est une application gratuite et multi-plateforme.

III. Comment utiliser Git avec mon projet ?

Sans plus attendre, on va se lancer dans ton premier repo ! Pour ça, fonce sur le site de Bitbucket et enregistre toi ! Dans la gestion de ton compte tu verras également que tu peux changer la langue par défaut de l’interface, plutôt cool si tu n’es pas anglophone.

Ensuite, il te faut le logiciel dont je te parlais il y a deux minutes, Sourcetree, que tu vas télécharger et installer. Il faudra bien sûr l’ouvrir après ça. Il te posera une ou deux question (quand il te parlera d’ignorer, tu peux dire « non »), te fera télécharger quelques trucs, et tu seras enfin prêt !

Il te demande maintenant de te connecter avec un compte. Si tu as bien créé ton compte Bitbucket, identifie-toi avec. Enfin, tu devrais pouvoir accéder à l’interface de Sourcetree qui peut, au premier abord, faire un peu peur, j’avoue.

Ton premier dépôt

Mais n’aie pas peur, on va créer notre premier dépôt ensembles ! Pour ça, une fois sur l’interface de Sourcetree, suis les étapes suivantes :

  1. Fichier > Cloner / Nouveau
  2. Tu as 3 onglets, le troisième est celui qui nous intéresse : « Créer un nouveau dépôt »
  3. Tu vois qu’il te demande le type de dépôt (= repository), reste sur Git, on parlera de Mercurial plus tard. Il te demande aussi une destination, et c’est là que c’est génial : Il te demande avec quel dossier de ton ordi tu veux synchroniser ce dépôt !
  4. Tu as choisis ton dossier ? Cool ! Maintenant tu dois choisir un nom pour ton dépôt, et je te conseille de toujours laisser « [Racine] » comme option pour « Dossier ».
  5. Et enfin, tu peux cliquer sur Créer !

Ca y est, tu as créé ton premier dépôt ! Tu vois, ce n’était pas si compliqué Maintenant, dans ton dossier, si tu n’as rien et que c’est un nouveau projet, créé y un fichier, n’importe lequel, de n’importe quel type. Si tu avais déjà quelque chose dans ce dossier, tu peux passer à la suite directement.

Ton premier commit

Maintenant, notre but est de mettre en ligne ceci. Et pour çà, tu verras que lorsqu’un changement est détecté par Sourcetree, il va te le dire. Au milieu, tu devrais trouver une partie « État des fichiers » quand tu es sur un dépôt, et en dessous « Copie de travail ».

Capture d'écran de SourceTree
Capture d’écran de SourceTree

Si tu coches la case « Fichiers dans l’arbre de travail », tu vas en fait dire à Sourcetree que ces fichiers là sont ceux que tu veux envoyer vers ton dépôt. Tu peux également voir qu’il y a une partie « Message de commit » : ici tu peux mettre un truc du genre « Mon premier commit ». Tu peux également cocher « Pousser les modifications » en bas à gauche, ce qui te permettra de confirmer que tu veux bien envoyer ces fichiers sur ton dépôt. Après un court instant, tu auras un message de succès. Maintenant, il est temps d’aller vérifier sur ton dépôt Bitbucket !

Connecte-toi à Bitbucket, tu auras alors la liste de tes dépôts. Sélectionne ton dépôt fraîchement créé, et regarde sur la gauche dans la barre latérale : il y a cette petite icône avec un tooltip « Source » :

Barre latérale sur SourceTree

En cliquant dessus, tu arrives sur la liste des fichiers de ton dépôt .. Et oh, magie, ils sont tous là ! C’est pas magnifique ça ? Raaah c’est beau. Ton code est désormais versionné !

Le changement de commit

Maintenant, tu peux t’amuser à faire plusieurs modifs, à les re-balancer (ou commit puis push comme on dit dans le jargon), et tu pourras ensuite constaté la puissance de Git dans Sourcetree : Quand tu as fait ton premier push, tu as pu constaté que dans la barre de gauche (« état des fichiers », « branches », etc..) une branche appelée « master » s’est créée. Clique dessus ! Et là, c’est la beauté de tout ce processus : tu peux voir directement tout tes commits, voir quels fichiers ont été changé, créés, supprimés. Et le mieux ? C’est que si tu double-clique sur un des commits, ça va te re-synchroniser ton code exactement comme il l’était à ce moment là. Prends garde tout de même à avoir commit tes dernières modifs avant de changer de commit, autrement tu risques de perdre tes modifications locales !

Les branches

On en parlait tout à l’heure, quand tu veux travailler avec quelqu’un d’autre, ou tout simplement si tu veux mieux organiser ton code sous forme de catégories, tu peux créer des branches. Quand tu créés une branche, tu peux lui dire sur quel commit elle doit se baser. Tu pourras donc travailler à partir de n’importe quel commit, faire tes modifications sans gêner celles de ton pote ou collègue, pour tout regrouper au final.

Si tu veux créer une branche, il te suffit de faire un clique droit sur « Branches », puis « Nouvelle branche », et celle ci va se baser sur le commit sur lequel tu es actuellement. Ainsi, à partir de là, tous tes commits s’effectueront sur cette branche ! Tu peux à tout moment changer de branche de la même manière que tu changes de commit, en double-cliquant sur le nom d’une branche. Fais attention également à avoir commit tes modifs avant de changer de branche à l’arrache !

Enfin, le merge

Ce moment délicat, où toi et ton collègue allaient vous mordre les doigts devant votre écran … Le moment fatidique du merge (= fusion).

Pour comprendre le merge basique, je te conseille d’aller lire ce tutoriel (en anglais, mais très simple à comprendre, beaucoup d’images et peu de texte).

S’il existe des conflits, Sourcetree te demandera de les résoudre avant de push ta branche fusionnée. Pour ça, tu peux vérifier dans la liste des fichiers lesquels présentent un conflit, et tu peux aller les changer manuellement (cette vidéo explique ce procédé bien mieux que moi).

Une fois que le tout est résolu, tu refais un commit puis un push, et hop, tout est bon. Si tu avais fait ça sur une branche de test, tu peux la merger avec la master qui est la première branche de tout dépôt. Et tu peux souffler.

Aller plus loin

Cet article est loin de t’expliquer toutes les possibilités qu’offre les systèmes de Git, c’est pourquoi je te conseille de faire quelques recherches de ton côté, et éventuellement de suivre ces différentes ressources :

Tout ça devrait composer un bon début. Sache que même si tu n’aimes pas Git, (mal)heureusement tu seras forcé d’utiliser un système de versioning (que ça soit Git, Mercurial ou SVN) dans ta carrière de développeur professionnel. Tout simplement parce qu’une entreprise ne peut pas se permettre de perdre du temps de travail sur des problématiques pareilles en 2015.

En 2015, quand tu dis à un client « ah ben en fait y’a eu un orage et mon mac a grillé du coup j’ai perdu tout votre projet » ça revient au même que de dire à ton prof « Mon DM de maths ? C’est mon chien qui l’a mangé j’vous jure ».

Non seulement tu risque très gros (perdre le client), mais en plus tu passes pour un novice qui n’est pas de confiance. Les clients discutent à leurs amis et à d’autres clients potentiels, et peuvent rapidement démolir ta réputation ou celle de ta boîte si tu fais des erreurs de ce genre (#nopressure).

LA conclusion.

Voilà voilà, Booste ton workflow #3 c’est déjà terminé ! En espérant que cette petite introduction à Git t’aura plu, et que ça t’encouragera à t’y mettre parce que tu n’as (vraiment) plus aucune excuse pour perdre bêtement ton boulot. A part la flemme, qui n’est pas une excuse valable. JUST DO IT.

Si tu as une idée d’un sujet que tu aimerais qu’on aborde ensemble dans le prochain épisode de #BTW, n’hésite pas à m’en faire part dans les commentaires, je suis toujours preneur, et je considère toutes les propositions !

Bisous bisous !

Booste ton workflow #3 : Le versioning avec Git
5 (100%) 3 vote[s]

Une réflexion sur “ Booste ton workflow #3 : Le versioning avec Git ”

  1. Ah que de souvenir quand mon PC m’a laché au début de mon stage de deuxième année et que j’ai perdu l’intégralité de mes travaux de la 1ere et 2eme année…
    Sinon ça serait bien de faire un article pour des astuces sur la recherche de contrat pro pour la licence Tais (vu que c’est directement la suite de MMI :p) et un sur l’utilité de faire sa propre toolbox en moi

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Je veux Contribuer

C'est parti

Je suis un Professionnel

Voyons voir