Mise en commun du travail

Introduction en vidéo :

Pour la plupart des projets, le travail de groupe est primordial. Git permet de grandement le simplifier, mais le faire en ligne de commande serait bien pénible.

C'est pour ça (et bien d'autres choses) que des outils en ligne existent, tels que :

Nous allons nous concentrer sur le premier, car le plus répandu, mais sachez que GitLab et BitBucket peuvent être installés gratuitement sur un serveur privé (c'est ce que nous avons fait chez Drakona 😉 ).

Je vous conseille donc de créer au moins un compte sur GitHub, qui pourra également vous servir de portfolio ou de carte de visite !

Créer un repository distant

En vidéo :

Pour créer un repository sur GitHub, il suffit d'aller sur la page de création d'un dépôt, d'entrer un nom et de décocher les cases... Et tout est prêt pour la suite.

Lier le local et le distant

En vidéo :

Si vous avez déjà un dépôt local non vide (avec au moins 1 commit), nous allons associer ce local avec le distant que nous avons créé sur GitHub avec la commande git remote add origin [email protected]:cheminDuDepot.git où origin est l'alias (ou le nom) du dépôt distant, pour votre machine et [email protected]:cheminDuDepot.git le lien SSH vers votre dépôt distant.

Si vous n'avez qu'un repository distant non vide (avec au moins 1 commit), nous pouvons récupérer les fichiers et lier les deux dépôts avec git clone [email protected]:cheminDuDepot.git qui créera un dossier portant le nom du projet, là où vous vous trouvez. Dans ce cas, le distant s'appellera origin et sera directement lié (le dossier est prêt à être utilisé).

Si vous avez un dossier vide, il faut :

  • initialiser un dépôt git avec git init
  • créer un premier fichier (ou un ensemble de fichiers)
  • créer un premier commit
  • lier ce nouveau dépôt avec le dépôt distant git remote add origin [email protected]:cheminDuDepot.git

Push et pull

En vidéo :

Maintenant que nous avons notre dépôt distant et qu'il est lié à notre dépôt local, il est temps d'envoyer et de récupérer des informations vers et depuis celui-ci.

Des commandes courantes :

  • git fetch récupère les informations sans changer vos fichiers locaux (permet simplement d'avoir les informations du distant, s'il y a de nouvelles branches, de nouveaux commits, etc.)
  • git pull origin nom-de-la-branche est à exécuter en étant sur la branche nom-de-la-branche sur votre dépôt local et permet de la mettre à jour par rapport à la branche nom-de-la-branche du distant (vos fichiers sont modifiés et vous récupérez les commits du distant)
  • git push origin nom-de-la-branche est à exécuter en étant sur la branche nom-de-la-branche sur votre dépôt local et permet de mettre à jour la branche distante avec les commits locaux
  • git push -u origin nom-de-la-branche est à exécuter en étant sur la branche nom-de-la-branche sur votre dépôt local et permet de mettre à jour le distant et de demander à Git de retenir le lien entre la branche locale et la branche distante. Avec ce lien, vous pourrez vous contenter de lancer git push ou git pull sans plus d'arguments (ce qui simplifie la vie 😉 ).

Pull Request (PR)

En vidéo :

Dans un projet à plusieurs, personne ne doit modifier directement la branche principale (main ou master la plupart du temps), mais on travaille dans des branches séparées et, lorsqu'elles sont terminées, on crée une Pull Request sur le dépôt distant (GitHub pour nous), que l'on fait relire (vérifier) par un collègue jusqu'à validation. La branche peut alors être fusionnée dans la branche principale (ou une autre branche de destination, ça arrive aussi). Je vous invite à plutôt regarder la vidéo, pour des exemples concrets.

Conventions de travail

Chez Drakona, nous utilisons un certain nombre de conventions pour travailler en équipe :

  • Tout développement (nouvelle fonctionnalité, correction de bug, etc.) a un ticket pour préciser le travail à faire.
    • Ce ticket contient en général 3 sections :
      • Quoi : que doit faire le ticket (sa finalité) ?
      • Comment : techniquement, comment répondre à la demande ?
      • Test / Vérification : comment vérifier que le ticket a bien été résolu
  • Pour travailler, on crée une branche :
    • Depuis la branche principale (main) à jour
    • qui contient le numéro et le nom du ticket (exemple : 42-creation-formulaire-de-contact)
    • qu'on écrit en minuscule, en séparant chaque mot par un - ou un _ (convention à définir au sein de l'équipe)
    • on évite les caractères spéciaux (qui peuvent poser problème sur certains systèmes).
  • Quand on crée un commit, on reprend le numéro du ticket et on ajoute un message clair (Exemple : 42 - Création du HTML du formulaire)
  • Chaque branche est liée à un et un seul ticket (un ticket peut avoir plusieurs branches, dans certains cas)

Merge, rebase, conflits

Une fois la PR faite, relue et qu'il faut la fusionner dans la branche principale, il ne reste plus qu'à appuyer sur le bouton Merge Pull Request sur la page GitHub. Malheureusement, si vous êtes plusieurs à avoir travaillé sur les mêmes fichiers, vous rencontrerez des conflits (Git ne sait pas quelles modifications il doit conserver ou comment les fusionner). Nous allons voir comment les régler, pour permettre la fusion.

En vidéo :

La première étape est de retourner sur votre machine, afin de régler les conflits. Pour cela, de nombreuses méthodes existent, mais la plus pratique (dans le cadre d'un fonctionnement avec Github) reste d'utiliser la commande git rebase.

Le rebase consiste à changer le point de départ de votre branche (qui avait pour point de départ un commit, généralement de la branche principale) vers un autre commit, plus à jour. Pour avoir un moyen plus visuel de comprendre ce changement, je vous invite à regarder la vidéo ci-dessus ou de tester sur un outil de visualisation de Git, très pratique pour apprendre (sur l'exemple donné, il faut juste lancer la commande git rebase master pour voir un rebase en action).

Dans la plupart des cas, nous allons faire comme suit (je pars du principe que vous êtes sur la branche à rebase) :

  • git checkout main pour aller sur la branche principale
  • git pull origin main (ou juste git pull) pour la mettre à jour (et s'assurer d'avoir tous les derniers changements)
  • git checkout - pour retourner sur la branche de travail
  • git rebase main pour lancer le rebase
  • Il faut maintenant gérer les éventuels conflits. Git rebase appliquant vos commits un par un, il est possible que vous ayez des conflits pour un ou plusieurs commits, et il faudra répéter les opérations suivantes :
    • ouvrir les fichiers concernés dans votre IDE et les corriger pour garder la ou les modifications que vous souhaitez conserver
    • une fois tous les conflits gérés, utiliser la commande git add (git add . ou git add nomDuFichier) pour les ajouter à l'index, afin de préciser à la commande rebase que les conflits ont été corrigés
    • git rebase --continue pour passer au commit suivant
  • Une fois tous les commits appliqués, votre branche locale est à jour
  • git push --force origin nom-de-votre-branche pour mettre à jour de force l'historique de votre branche sur GitHub (ne faites jamais cette opération sur la branche principale)
  • Faites re-faire une relecture rapide de votre PR, pour vous assurer que tout est toujours bon
  • Vous pouvez fusionner ou faire fusionner votre PR