Le système de gestion de version Git et GitHub

Cette conférence présente le système de gestion de version Git ainsi que la plateforme GitHub, en s'inscrivant dans le cadre d'un cours de génie logiciel.

D'après le document Le système de gestion de version Git et GitHub

Cet article a été rédigé automatiquement à partir du document source, puis vérifié avant publication.

Document source

Le système de gestion de version Git et GitHub

Software Engineering · PDF · 29 pages · 2016

Afficher l'aperçu du document

Consulter le document original →

Cette conférence présente le système de gestion de version Git ainsi que la plateforme GitHub, en s'inscrivant dans le cadre d'un cours de génie logiciel. Elle explique les principes fondamentaux des systèmes de gestion de version, détaille le fonctionnement de Git, ses commandes de base, la gestion des branches, le travail avec des dépôts distants, et se termine par des conseils pratiques et une introduction à GitHub.

Introduction aux systèmes de gestion de version

Un système de gestion de version est un logiciel permettant de maintenir et gérer toutes les versions d’un ensemble de fichiers. Il facilite le suivi de l’évolution d’un projet au cours du temps, permet de revenir aisément à une version précédente, autorise le travail en parallèle sur des parties distinctes du projet tout en gérant les modifications concurrentes, et aide à la détection et à la correction d’erreurs.

Types de systèmes de gestion de version

Système local

Ce système est simple à gérer et à utiliser, mais il est très sensible aux pannes et ne permet pas la collaboration entre plusieurs utilisateurs.

Système centralisé

Ce système est structurellement simple et facile à gérer. Cependant, il reste sensible aux pannes et n’est pas adapté aux très grands projets ou à ceux avec une forte structure hiérarchique.

Système distribué

Ce système est moins sensible aux pannes et adapté aux très grands projets ou à ceux avec une structure hiérarchique complexe. En revanche, sa gestion et son utilisation sont plus compliquées et il peut devenir structurellement très complexe.

Présentation de Git

Git est un système de gestion de version distribué (DVCS). Il a été développé en 2005 par Linus Torvalds après que la communauté Linux ait dû abandonner l’utilisation du DVCS propriétaire BitKeeper. Git a rapidement hébergé le développement du noyau Linux.

Principes de base de Git

Un dépôt Git est une base de données qui enregistre les versions des fichiers d’un projet à des moments précis sous forme d’instantanés.

Les trois sections d’un projet Git

  • Le répertoire Git/dépôt : contient les méta-données et la base de données des objets du projet.
  • Le répertoire de travail : correspond à une extraction unique d’une version du projet depuis la base de données du dépôt.
  • La zone de transit (staging area) : un fichier simple contenant des informations sur ce qui sera pris en compte lors de la prochaine soumission (commit).

Les états d’un fichier dans Git

  • Non versionné : fichier non géré par Git.
  • Non modifié : fichier sauvegardé de manière sûre dans sa version courante dans la base de données du dépôt.
  • Modifié : fichier ayant subi des modifications depuis la dernière soumission.
  • Indexé (staged) : fichier modifié qui sera inclus dans l’instantané lors de la prochaine soumission.

Le commit dans Git

Chaque commit crée un objet contenant :

  • Un pointeur vers un instantané du contenu dont les modifications étaient indexées au moment de la soumission.
  • Des méta-données (auteur, message).
  • Un pointeur vers le commit précédent.

Ce mécanisme permet de stocker un instantané des fichiers concernés et de reproduire la structure du répertoire projet et de ses sous-répertoires.

Commandes de base Git

  • git init : initialiser un dépôt.
  • git status : afficher l’état des fichiers dans le répertoire courant, distinguant les fichiers non versionnés, ceux indexés pour le commit, et ceux modifiés mais non indexés.
  • git add [-p] <fichier> : indexer l’ajout ou les changements d’un fichier.
  • git reset <fichier> : annuler les modifications indexées d’un fichier.
  • git checkout [--] <fichier> : annuler les modifications non encore indexées d’un fichier.
  • git rm <fichier> : indexer la suppression d’un fichier.
  • git rm --cached <fichier> : déversionner un fichier (le retirer de l’index sans le supprimer du disque).
  • git diff : afficher les détails des modifications non indexées.
  • git diff --staged : afficher les détails des modifications indexées.
  • git commit : soumettre les modifications indexées en zone de transit.
  • git log : voir l’historique des commits.

Gestion des branches dans Git

Une branche est une ligne d’évolution divergente de la ligne courante, permettant de poursuivre indépendamment plusieurs développements.

Pourquoi utiliser des branches ?

  • Pour lancer des évolutions ambitieuses tout en pouvant revenir à une version stable maintenue indépendamment.
  • Pour tester différentes implémentations d’une même fonctionnalité de manière indépendante.

Fonctionnement des branches

Une branche est simplement un pointeur vers un objet commit. Par défaut, il existe une branche nommée master. Le pointeur spécial HEAD indique la branche actuellement active et extraite dans le répertoire de travail.

Commandes pour gérer les branches

  • git branch <branche> : créer une nouvelle branche.
  • git branch : afficher les branches locales.
  • git branch -d <branche> : supprimer une branche.
  • git checkout <branche> : passer à une branche donnée (mise à jour de l’index, du répertoire de travail et du pointeur HEAD).

Fusion et rebase

Pour incorporer les modifications d’une branche dans la branche courante, deux méthodes sont possibles :

  • Fusion (merge) : combine les instantanés des deux branches. Si la branche à fusionner est un ancêtre de la branche courante, rien n’est fait. Si elle est un descendant, le pointeur de la branche courante est déplacé (fast-forward). Sinon, Git crée un nouvel objet commit de fusion basé sur les trois instantanés (branche courante, branche à fusionner, plus jeune ancêtre commun).
  • Rebase : déplace la branche courante pour qu’elle pointe sur la branche donnée, puis réapplique les changements un par un. Cela permet d’obtenir un historique linéaire.

Gestion des conflits lors d’une fusion

En cas de conflit empêchant la fusion :

  • Aucun commit de fusion n’est créé, le processus est mis en pause.
  • git status liste les fichiers non fusionnés (unmerged).
  • Git ajoute des marqueurs de résolution de conflits dans les fichiers concernés pour permettre une résolution manuelle.
  • Une fois les conflits résolus, il faut faire git add <fichier> pour marquer la résolution.
  • Après résolution de tous les conflits, un commit de fusion est effectué avec git commit pour terminer le processus.

Travail avec des dépôts distants

Pour collaborer, il est nécessaire d’échanger avec un ou plusieurs dépôts distants hébergeant le même projet. Les données des dépôts distants (commits et instantanés) sont entièrement copiées dans le dépôt local. Pour chaque branche distante, une branche locale <dépôt>/<branche> non modifiable permet de suivre la position de la branche distante localement.

Commandes liées aux dépôts distants

  • git remote : afficher la liste des dépôts distants du projet.
  • git clone <URL> [<répertoire>] : cloner un dépôt distant (nommé automatiquement origin).
  • git fetch <dépôt> : récupérer les modifications d’un dépôt distant.
  • git remote add <nom> <URL> : ajouter un dépôt distant.
  • git push <dépôt> <branche> : mettre à jour un dépôt distant pour une certaine branche locale. Cette opération ne fonctionne que si la mise à jour peut être faite par fast-forward, c’est-à-dire si le dernier commit distant a été récupéré et intégré localement.
  • git pull <dépôt> <branche> : combine git fetch et git merge.
  • git pull --rebase <dépôt> <branche> : combine git fetch et git rebase.

Conseils et bonnes pratiques

  • Utiliser abondamment les branches pour organiser le travail.
  • Éviter de faire systématiquement un git pull sans réfléchir à la méthode la plus pertinente (fusion ou rebase).
  • Ne jamais rebaser une branche déjà présente sur un dépôt public.
  • Respecter les conventions de formatage des messages de commit : un titre de 50 caractères maximum, suivi d’une ligne vide, puis d’une description détaillée avec des lignes de 72 caractères maximum, le tout au présent de l’impératif.

Présentation de GitHub

GitHub est un service web d’hébergement et de gestion de projets de développement logiciel utilisant Git. Au-delà du système de gestion de version, GitHub propose un écosystème complet incluant notamment un Wiki et un système de tickets avec support Markdown et référencement des tickets.

Site officiel : https://help.github.com/

Points clés à retenir

  • Git est un système de gestion de version distribué adapté aux projets complexes et collaboratifs.
  • Un dépôt Git contient trois zones : le dépôt lui-même, la zone de travail, et la zone de transit (staging area).
  • Les fichiers peuvent être non versionnés, non modifiés, modifiés ou indexés.
  • Les commits enregistrent des instantanés du projet avec des métadonnées et un lien vers le commit précédent.
  • Les branches permettent de développer plusieurs évolutions indépendantes.
  • La fusion (merge) et le rebase sont deux méthodes pour intégrer des modifications entre branches.
  • Le travail avec des dépôts distants nécessite des commandes spécifiques pour synchroniser les modifications.
  • Les bonnes pratiques incluent l’usage intensif des branches, la prudence avec le rebase, et le respect des conventions de message de commit.
  • GitHub offre un environnement complet pour héberger et gérer des projets Git avec des outils collaboratifs.

Partager

Commentaires

Aucun commentaire pour le moment. Posez la première question.

Les commentaires sont relus avant publication. Votre e-mail n'est jamais affiché.

← Toutes les révisions