Ce cours/TP va vous permettre de vous familiariser avec la gestion de versions logicielle.

Le but de cette pratique est suivre l’évolution d’un projet ou plus simplement d’un programme, localement et à distance, même lorsque l’on collabore à plusieurs, sans se marcher sur les pieds et prendre le risque de modifier ou supprimer le travail d’un collaborateur. Nous utiliserons pour cela le logiciel git.

1. Introduction

Git est un logiciel de gestion de versions décentralisé. C’est un logiciel libre créé par Linus Torvalds, auteur du noyau Linux, et distribué selon les termes de la licence publique générale GNU version 2. En 2016, il s’agit du logiciel de gestion de versions le plus populaire qui est utilisé par plusieurs millions de personnes.

Le principe de l’utilisation de git repose sur :

  • un dépôt distant : une version de votre projet stockée sur un serveur sur Internet.

  • des dépôts locaux sur les ordinateurs sur lesquels vous travaillez.

Vous faites vos modifications sur votre ordinateur, et lorsque vous avez accompli une amélioration qui fonctionne bien, vous pouvez la faire enregistrer (commit) par git.

Ces enregistrements sont locaux à votre ordinateur, et vous pouvez en faire autant que vous le souhaitez.

Si vous voulez partager votre travail avec votre équipe, il vous faut l’envoyer vers le dépôt distant (push).

À l’inverse, si vous souhaitez récupérer le travail fait par vos co-équipiers, il faut ramener ces modifications depuis le dépôt distant (pull).

De nombreux environnement de développement gèrent les fonctionnalités de git.

Dans cette activité, vous allez installer git sur votre ordinateur, créer un dépôt git distant et apprendre à utiliser ses fonctionnalités.

2. Pourquoi un logiciel de suivi de version?

Observons le contenu de ce dossier :

motivation1

Quelle est la version la plus à jour ? A prioris Rapport_VFinal.doc. Oui mais si le rédacteur a enregistré ses dernières modifications à partir de Rapport_V2.doc ? Et s’il a renommé la version finale en Rapport.doc pour l’envoyer par mail à ses collègues?

On peut toujours se référer aux propriétés des fichiers et observer leurs dates de modification et leur taille pour avoir une idée plus précise mais on voit bien ici que cette solution d’organisation du suivi des versions n’est pas satisfaisante.

  • La gestion des versions est un travail fastidieux et méthodique.

  • Les humains ne sont pas doués pour les travaux fastidieux et méthodiques.

  • Laissons à l’ordinateur le soins de faire ces travaux fastidieux et concentrons-nous sur la partie du travail où nous sommes meilleurs que lui.

Utilisons un logiciel de VCS (Version Control System)

3. Avantages

Les VCS étaient initialement dédiés à la gestion de code source pour les projets logiciels. Ils peuvent également servir à maintenir à jour une documentation ou le code d’un site web.

Ils permettent un travail collaboratif en facilitant les échanges de fichiers, en mettant en évidences les différences entre deux versions, en assurant la traçabilité des opérations et en gérant les conflits.

Principales fonctionnalités d’un VCS :

  • Sauvegarde (modulo la synchronisation avec un serveur distant)

  • Conservation de l’historique (nominatif) des fichiers (qui a fait quoi ?)

  • Possibilité de retour en arrière

  • Fusion des modifications lors du travail collaboratif

  • Visualiser les changements au cours du temps

4. Principe de fonctionnement

Le schéma suivant présente le principe de fonctionnement d’un VCS de type git.

git operations
Figure 1. git repositories operations [source : https://www.edureka.co/blog/git-tutorial/]

4.1. Le stockage

Vos fichiers se trouvent au départ dans votre dossier de travail ou Working Directory. Après une modification, vous les faites passer dans un espace temporaire appelé index ou Staging area avant de les versionner dans le dépôt local ou Local Repository. Les dépôts distants ou Remote Repository peuvent ensuite être synchronisés.

Vocabulaire :

  • Working Directory : Dossier de travail sur votre ordinateur.

  • Staging area : ou index est un espace temporaire contenant les modifications prêtes à être « commitées ».

  • Local Repository : Dossier caché .git qui contient toutes les données dont git a besoin pour gérer l’historique des versions.

  • Remote Repository : Dépôt distant qui contient l’historique des versions. Le contenu des dépôts local et distant est identique après un push (en principe).

4.2. Les opérations de bases

  • Clone : git clone <url_remote_repository> Copy le contenu du dépôt distant dans le dossier courant. A utiliser lorsque l’on veut travailler sur projet sur un ordinateur sur lequel on a pas encore de dépôt local concernant ce projet.

  • Initialize : git init Créer un dépôt local git vide ou en réinitialise un existant. Concètement, il crée un répertoire .git avec des sous-répertoires et des fichiers modèles. L’exécution de git init dans un dépôt existant ne remplacera pas les éléments déjà présents.

  • Add : git add <file> Cette commande met à jour l’index en utilisant le contenu actuel trouvé dans le dossier de travail, puis prépare le contenu dans la zone de transfert pour la prochaine validation.

Ainsi, après avoir modifié le contenu de l’arborescence de travail et avant d’exécuter la commande commit, on utilise la commande add pour ajouter tout fichier nouveau ou modifié à l’index.

  • Commit : git comit -a -m <message> L’historique d’un projet est une séquence "d’intantanés" du projet, contenant l’état de tous les fichiers du projet.

Ces "instantanés" ou "révisions" sont obtenues par l’application de la commande git commit -a -m <message> et possèdent :

  • une date

  • un auteur

  • une description textuelle <message>

  • un lien vers le(s) commit(s) précédent(s)

  • Pull : git pull origin <branch-name> Cette commande met à jour le dépôt local à partir du dépôt distant. Il faut avant préciser quel est le dépôt distant qui sert de source à cette mise à jour en utilisant la commande git remote add origin <url_remote_repository>. Si la branche à récupérer est la branche principale, <branche-name> = master

  • Push : git push <remote-name> <branch-name> Lorsque vous souhaitez partager votre projet, vous devez le "pousser"" vers le dépôt distant. Si vous souhaitez transférer votre branche principale sur le dépôt distant (le clonage configure généralement <remote-name> automatiquement), on exécute pour transférer le travail la commande

git push origine master

Cette commande ne fonctionne que si l’on a cloné à partir d’un dépôt distant sur lequel on a un accès en écriture et si personne n’a "poussé" entre-temps. Si quelqu’un d’autre "clone" en même temps, votre "poussée" sera rejetée. Vous devez d’abord récupérer son travail et l’intégrer au vôtre (pull) avant de pouvoir faire votre "poussée".

git commands
Documentation complète de git :

https://git-scm.com/book/en/v1/Git-Basics-Getting-a-Git-Repository

5. github

GitHub (exploité sous le nom de GitHub, Inc.) est un service web d’hébergement et de gestion de développement de logiciels, utilisant le logiciel de gestion de versions Git. Ce site est développé en Ruby on Rails et Erlang par Chris Wanstrath, PJ Hyett et Tom Preston-Werner. GitHub propose des comptes professionnels payants, ainsi que des comptes gratuits pour les projets de logiciels libres. Le site assure également un contrôle d’accès et des fonctionnalités destinées à la collaboration comme le suivi des bugs, les demandes de fonctionnalités, la gestion de tâches et un wiki pour chaque projet.

— Wikipedia
https://fr.wikipedia.org/wiki/GitHub

github
Figure 2. https://github.com/

5.1. Travail faire : Créer un compte github

  • Si vous ne possédez pas de compte github, vous devez en créer un :

  • Rendez vous sur le site https://github.com/ et créer vous un compte.

    • Vérifiez le puzzle

    • Laissez décochées les deux cases we need an organisation account et send me occasional product updates

    • Cliquez sur Next : Select a plan

    • Choisissez Free

    • Répondez au questionnaire sur la raison pour laquelle vous créer ce compte.

    • Cliquez sur Complete setup

    • Vérifiez vos email à l’adresse que vous avez indiquée lors de la création du compte et activez votre compte en cliquant sur le bouton Verify email address

    • Félicitation, vous avez créé votre compte github, vous pouvez désormais sauvegarder, organiser, partager votre code.

5.2. Travail faire : Faire connaissance avec github

  • Cliquez sur le bouton Read the guide

  • On vous propose ici une activité de 10 minutes environ pour balayer les principales fonctionnalités de github

    • Faites l’activité Create a repository en configurant le dépot en mode Private. Noubliez pas de cocher la case Initialize with a README

    • Faites l’activité Make a commit. Le fichier README.txt est écrit en langage de balisage Markdown. Consultez la syntaxe ici : https://www.markdownguide.org/basic-syntax pour obtenir un résultat comme ci-dessous :

README

  • Après avoit publié (on dira ici commiter), cliquez sur le nom du dépôt qui apparait à côté de vorte nom d’utilisateur pour revenir à la racine.
    Il ne devrait y avoir que votre fichier README.txt dans la liste des fichiers.

  • Ajoutez une image (upload files) que vous téléchargerez ici :

tux

  • Modifiez le fichier README.txt pour y faire apparaitre l’image à la fin.

### Une image
![Tux, the Linux mascot](/tux.png)
README avec tux

Bonne programmation !

the_end.jpg