Module 6.1 : Workflow Git - Interface VS Code

Contexte

Dans le module précédent (Module 6), nous avons exploré les commandes Git en ligne de commande pour gérer le contrôle de version de nos projets web. Cependant, Visual Studio Code offre une interface graphique intégrée appelée "Contrôle de source" qui permet de réaliser toutes ces opérations de manière plus intuitive et visuelle. Ce module vous montrera comment effectuer le même workflow Git que nous avons vu précédemment, mais cette fois-ci en utilisant exclusivement l'interface graphique de VS Code.

Objectifs du cours

• Comprendre l'interface Contrôle de source de VS Code
• Apprendre à effectuer les commandes Git de base via l'interface graphique
• Savoir gérer les conflits de fusion via l'interface
• Utiliser un fichier .gitignore pour exclure des fichiers du suivi

Le fichier .gitignore

Rôle du fichier .gitignore

Le fichier .gitignore est un fichier spécial dans un dépôt Git qui permet de spécifier quels fichiers ou dossiers ne doivent pas être suivis par Git. Cela est utile pour exclure des fichiers temporaires, des fichiers de configuration locaux, des dépendances, ou tout autre contenu qui ne devrait pas être versionné.

Utilisation du fichier .gitignore

Pour utiliser un fichier .gitignore :

1. Créer un fichier nommé .gitignore à la racine de votre dépôt Git.
2. Ajouter les patterns des fichiers ou dossiers à ignorer, un par ligne.
3. Les patterns peuvent utiliser des caractères génériques comme * pour matcher plusieurs fichiers.

Exemples de patterns courants

• node_modules/ : Exclut le dossier des dépendances Node.js
• *.log : Exclut tous les fichiers avec l'extension .log
• .env : Exclut les fichiers de variables d'environnement
• build/ : Exclut le dossier de build
• *.tmp : Exclut les fichiers temporaires

Note

Le fichier .gitignore lui-même doit être commité pour que les règles s'appliquent à tous les contributeurs du projet.

Exemple de contenu d'un fichier .gitignore

# Exclure les dépendances Node.js
node_modules/
# Exclure les fichiers de log
*.log
# Exclure une installation locale de Bootstrap 
partial/
# Exclure les fichiers de configuration locaux
.env
# Exclure les fichiers temporaires
*.tmp

L'interface Contrôle de source de VS Code

Définition

L'interface Contrôle de source de VS Code est une intégration native de Git qui permet de gérer le contrôle de version directement depuis l'éditeur. Elle offre une vue d'ensemble des changements, des commits, des branches et des opérations Git sans avoir à utiliser la ligne de commande.

Accès à l'interface

Pour accéder au Contrôle de source dans VS Code :

1. Ouvrir un projet Git dans VS Code
2. Cliquer sur l'icône de branche dans la barre latérale gauche (ou Ctrl+Shift+G)
3. La vue Contrôle de source s'ouvre

Note

Si le projet n'est pas un dépôt Git, VS Code proposera de l'initialiser.

Points importants

• L'interface reflète exactement les commandes Git vues au Module 6
• Chaque action dans l'interface correspond à une commande spécifique
• Les messages d'erreur sont affichés de manière claire
• L'historique des commits est facilement navigable

---

Exemple 1 : workflow sans conflit avec le Contrôle de source

1 : Travail normal sur les fichiers

Tu travailles normalement sur tes fichiers HTML, CSS, etc. dans VS Code. Lorsque tu sauvegardes, les changements sont automatiquement détectés par l'interface Contrôle de source plus bas.

2 : Contrôle de source

Une fois dans l'interface Contrôle de source, tu peux voir tous les fichiers modifiés, ajoutés ou supprimés. Tu peux cliquer sur chaque fichier pour voir les changements ligne par ligne. À cette étape, tu es rendu aux étapes de vouloir faire un git add, git commit, etc. mais au lieu de les faire en ligne de commande, tu vas les faire via l'interface graphique.

3 : Staging (add) et commit

Ici, il faut entrer un message de commit dans la zone prévue à cet effet, puis cliquer sur le bouton "Valider" pour enregistrer les changements. Cette opération est l'équivalent de faire DEUX commandes en ligne de commande : git add . pour ajouter tous les fichiers modifiés au staging, puis git commit -m "message" pour créer le commit.

Ce que git fait comme commandes en arrière-plan :

git add .
git commit -m "message de commit"

4 : Push et Pull

Une fois que tu as commité tes changements, tu peux les pousser vers le dépôt distant en cliquant sur le bouton "Synchronisation" (flèche vers le haut). C'est l'équivalent de faire git push. De même, pour récupérer les changements du dépôt distant, tu peux cliquer sur le bouton "Synchronisation" (flèche vers le bas) pour faire un git pull.

Pull va se faire uniquement si des fichiers plus récents sont présents sur le dépôt distant. Sinon, tu n'auras pas l'option de pull, mais seulement de push.

Ce que git fait comme commandes en arrière-plan :

git push

Fin du workflow

Une fois que tu as poussé tes changements, tu peux vérifier sur GitLab que les commits ont bien été envoyés. Tu peux aussi voir l'historique des commits directement dans VS Code en cliquant sur l'onglet "Historique" dans la vue Contrôle de source.

Points importants

• Utiliser des messages de commit descriptifs, en français
• Vérifier les changements avant de committer
• Commiter fréquemment pour un historique propre

---

Exemple 2 : workflow avec conflit et résolution via le Contrôle de source

Dans cet exemple, nous allons simuler un conflit de fusion et voir comment le résoudre directement dans l'interface Contrôle de source de VS Code.

1 : Conflit suite à un push

Rendu au moment de faire un push, tu réalises que quelqu'un d'autre a déjà poussé des changements sur le dépôt distant. Lorsque tu essaies de pousser, tu obtiens une erreur indiquant qu'il y a des changements plus récents sur le dépôt distant.

2 : Pull pour récupérer les changements

Pour résoudre ce problème, tu dois d'abord faire un pull pour récupérer les changements du dépôt distant. Cependant, comme tu as des changements locaux qui entrent en conflit avec ceux du dépôt distant, tu obtiens un message d'erreur indiquant qu'il y a un conflit de fusion et que tu dois le résoudre manuellement.

Ce que git fait comme commandes en arrière-plan :

git pull

3 : Éditeur de fusion

VS Code ouvre automatiquement les fichiers en conflit dans un éditeur spécial qui affiche les différentes versions du code : ta version locale, la version distante et une version combinée. Tu peux choisir quelle version garder ou fusionner manuellement les changements.

• Ici, tu dois faire un choix entres les deux versions du code, ou les fusionner manuellement. À gauche tu as la version ENTRANT (les changements du repo distant), à droite la version ACTUELLE (la tienne).
• Une fois la version ENTRANT ou ACTUELLE choisie, la partie en bas (RÉSULTAT) affiche le code final qui sera gardé après la fusion. Ici, tu peux également faire du nettoyage manuel pour fusionner les deux versions si nécessaire.

4 : Terminer la fusion

Dans cet exemple, nous avons choisi de garder la version ENTRANT (les changements du dépôt distant). Après avoir fait ce choix, tu dois cliquer sur le bouton "Terminer la fusion" pour marquer le conflit comme résolu. Ensuite, tu dois commiter la résolution du conflit pour enregistrer les changements.

• Ne pas oublier le bouton Terminer la fusion

5 : Recomiter et pousser

Une fois que tu as résolu le conflit et commité la résolution, Vs Code va te proposer de "Continuer", ce qui équivaut à faire un add/commit et push pour envoyer les changements résolus vers le dépôt distant. Tu peux cliquer sur ce bouton pour terminer le workflow.

Ce que git fait comme commandes en arrière-plan :

git add .
git commit -m "Résolution du conflit"
git push