Introduction

5

Git est un outil qui vous protège, vous et les autres, de vous-même et des autres. Il permet en quelque sorte de faire des "checkpoints" ou en français, des points de sauvegarde 💾, dans un projet.

Ainsi, vous pouvez modifier/briser/améliorer votre projet l'esprit tranquille, puisqu'il vous permet de revenir en arrière en cas de besoin.

Répertoire

Un répertoire, en anglais repository ou son diminutif repo, est le nom donné au dossier 📂 devant être surveillé par Git. À chaque commit, tous les changements effectués à l'intérieur de celui-ci seront enregistrés par Git.

Commit

À tout moment, il est possible de sauvegarder en local (sur son ordinateur) l'avancement d'un projet 💾.

Cette étape est appelée commit.

Voir le CodePen de Simon Arnold (@smnarnold).

Push

Idéalement, un commit est ensuite poussé vers le cloud ☁️.

Ce qu'on appel faire un push ⬆️.

Voir le CodePen de Simon Arnold (@smnarnold).

Ainsi, si vous devez changer d'ordinateur pour X raisons:

  • Votre ordinateur a explosé 💻💥.
  • Est occupé par quelqu'un d'autre.
  • Vous préférez continuer de travailler ailleurs (de la maison 🏠 / du collège 🏫).

Il sera possible d'y avoir accès à partir d'un autre ordinateur, puisque votre commit (sauvegarde) est maintenant synchronisé sur un serveur en ligne (ex: GitHub).

Pull

De n'importe quel ordinateur, il est possible de tirer la sauvegarde la plus récente d'un repo.

Ce que l'on appelle faire un pull ⬇️.

Voir le CodePen de Simon Arnold (@smnarnold).

Ainsi, il est possible de récupérer les changements les plus récents sur un projet et de continuer son avancement exactement où nous étions rendus.

Pour continuer la métaphore du jeu vidéo, l'équivalent serait de faire une sauvegarde en ligne. Ainsi, même si votre console brise ou si vous êtes en visite, vous pouvez récupérer votre partie et la continuer sur une autre console.

Branches

Par défaut, tous les repos ont une branche appelée master. Lorsqu'un push est effectué, les changements sont envoyés vers cette branche.

Cependant, il est parfois préférable de laisser la branche master indemne. Par exemple, à l'approche d'une démonstration client où l'on souhaite s'assurer qu'aucun bug ne vienne perturber la présentation. Néanmoins, arrêter de travailler quelques jours avant la présentation, simplement pour éviter un potentiel bug lors d'une présentation représente une perte de temps non négligeable. Il est donc préférable de créer une nouvelle branche à partir de master et de travailler sur celle-ci plutôt.

Ainsi, il est possible de présenter la branche master l'esprit en paix sachant qu'aucun bug de dernière minute ne risque de faire son apparition. Lorsque la présentation est passée ou que les changements sur la nouvelle branche sont complétés, il est possible de merger la nouvelle branche vers master afin d'y incorporer ses changements.

Collaboration

Git permet également de travailler à plusieurs simultanément sur un même projet. Pour ce faire, chaque développeur possède une copie du même repo sur son ordinateur et partage un repo commun en ligne pour pousser ses commits.

Ainsi, à chaque fois qu'un développeur 👩 effectue un commit et le push en ligne, son collègue 👨 reçoit une notification l'avertissant que de nouveaux changements sont disponibles, bref l'invite à faire un pull.

Ce dit collègue 👨 peut attendre avant de récupérer les changements et continuer à travailler / commiter à sa guise. Cependant, Git bloquera toute tentative de push tant qu'il n'aura pas pullé les changements disponibles en ligne.

Voir le CodePen de Simon Arnold (@smnarnold).

Conflits

À moins de toujours travailler en solo, aucun développeur n'échappe à la problématique d'avoir modifié le même fichier que l'un de ses collègues.

Gérer un conflit SANS Git

Deux scénarios sont possibles:

  • Personne ne remarque l'incident et les changements effectués par le premier développeur sont écrasés par ceux du deuxième 🙍.
  • Les développeurs comparent minutieusement chaque version du fichier afin de repérer les différences et essayer de les combiner, ce qui exige du temps, de la concentration et est malheureusement prône aux erreurs. Bref, cette activité a des allures d'une partie du jeu des 7 différences, alors que personne n'a envie de jouer.

Gérer un conflit AVEC Git

Heureusement, comme mentionné précédemment, Git surveille chaque changement. Ainsi, si deux développeurs ont modifié le même fichier, lorsque le deuxième développeur effectuera un pull, afin de récupérer les changements disponibles, Git validera en premier temps si les lignes modifiées sont différentes.

Si les lignes sont différentes: les modifications seront combinées automatiquement comme par magie ✨.

Si certaines lignes sont les mêmes:

  1. Git informera le deuxième développeur de la présence d'un conflit.
  2. Indiquera le fichier touché.
  3. Ajoutera des commentaires dans le fichier indiquant la zone touchée.

Par exemple:

<<<<<<< HEAD
Texte écrit par le premier développeur
=======
Texte écrit par le deuxième développeur
>>>>>>>

Ainsi, il pourra facilement comparer les différences et sélectionner quelle version il est préférable de garder.

Dans le but d'éviter autant que possible les conflits, ou du moins de les simplifier, il est conseillé de commiter régulièrement. Minimalement 1x par jour.

Pour comprendre en détail le fonctionnement de Git, je vous suggère l'excellent learngitbranching.js.org

Donnez votre opinion
sur les notes de cours sur cette page.
Merci d'avoir partagé ton opinion 😎
Pssst, c'est 💯 anonyme