,Gestion de version avec GitHub
Sommaire de la note :
1. 1. Utilisation : En synthèse
2. 2. Présentation
2.1. 2.1. C’est quoi ?
2.2. 2.2. Installation
3. 3. Les principes d’utilisation
3.1. 3.1. Repository
3.2. 3.2. Ajout de fichier
3.3. 3.3. Commit
3.4. 3.4. Mise à jour
4. 4. Utilisation
4.1. 4.1. Création du repository (base de données)
4.2. 4.2. Commit
4.3. 4.3. Visualisation de différences
4.4. 4.4. Récupération en local de la dernière version
4.5. 4.5. Autres fonctions
5. 5. Conseils généraux
1. Utilisation : En synthèse
Créez un compte ici : https://github.com/signup
Téléchargez ici : https://desktop.github.com/
Installer.
Connectez-vous sur GitHub desktop : File / Options… / Sign into GitHub.com
Créez un repository sur GitHub desktop : File / New repository.
Pour enregistrer une version : sur GitHub desktop :
Donnez un titre et indiquez les principales modifications.
Si besoin, cliquez sur un fichier modifié pour voir les modifications apparaitre.
Cliquez sur Commit to main.
2. Présentation
2.1. C’est quoi ?
Lorsque l’on développe un logiciel, le code évolue très vite : on ajoute des
fonctionnalités, on modifie, on corrige les bugs, … Le risque est donc grand que, à
partir d’un code fonctionnel, on le modifie et que ça ne marche plus. Ou encore que,
en rajoutant les modifications d’un collègue, on introduise des bugs ou casse des
fonctionnalités (sans ne plus savoir ce qu’on a modifié).
Il est donc utile de garder une trace des différentes versions pour voir ce que l’on a
modifié, pouvoir revenir en arrière et comprendre ce qui fait bugger notre logiciel.
L’intérêt de l’outil est encore plus fort (ou indispensable) lorsque l’on développe à
plusieurs : chaque personne importe ses modifications, les autres pourront ensuite
fusionner leur version courante avec la version importée avant d’importer à leur tour
leur version modifiée.
Différents outils existent pour cela, notamment Git (https://fr.wikipedia.org/wiki/Git).
Il s’agit d’un outil de gestion de version qui permet d’enregistrer un ou plusieurs
fichiers pour une version, pouvoir revenir à une version précédente, afficher les
modifications entre la version en cours et une version enregistrée, …
GitHub est un service qui permet d’une part d’utiliser simplement Git sur son OS et
d’autre part de stocker notre code et les modifications successives sur le cloud : il
offre donc à la fois l’outil de gestion de version ainsi que l’espace de stockage de la
base de donnes. D’autres outils proposent SVN (en gros un Git plus ancien mais
similaire pour notre utilisation) sur d’autres plateformes, notamment Sourcetree
(https://www.sourcetreeapp.com/) ou SmartGit (https://www.syntevo.com/register-
non-commercial/#academic). Le principe de ce qui suit est commun aux différents
outils.
2.2. Installation
Créer un compte GitHub ici : https://github.com/signup
Télécharger GitHub Desktop ici : https://desktop.github.com/
Ouvrir GitHub Desktop
Cliquer sur File / Options…
Cliquer sur « Sign into GitHub.com » et connectez-vous à votre compte
GitHub :
Vous pouvez désormais suivre votre code.
3. Les principes d’utilisation
Ici sont présentés les principes d’utilisation d’un outil de gestion de version ; la
façon de le réaliser sur GitHub sera présenté au chapitre suivant.
3.1. Repository
Le repository est la base de données où sont stockées les différentes informations
concernant l’historique de votre projet.
Le repository est créé sur GitHub ce qui permet d’y accéder de n’importe où et de
permettre à tous les membres du projet d’y accéder.
3.2. Ajout de fichier
Une fois le repository créé, il faut indiquer au logiciel les fichiers que l’on veut suivre.
Par exemple, on peut vouloir ajouter les fichiers de code, les librairies, les
documents Word de suivi de projet ou du cahier des charges (qui change
généralement dans « la vraie vie ») mais ne pas suivre certains documents
temporaires.
3.3. Commit
Le « commit » est le fait d’enregistrer une version des fichiers suivis : vous importez
dans la base de données vos modifications et désignez alors ce code par une
nouvelle version. Vous pourrez ensuite le modifier et « commiter » (importer les
modifications) en une nouvelle version lorsque vous le jugerez nécessaire.
Quand « commiter » ? Il n’y a pas de règle formelle, cela peut donc être quand
vous le souhaitez. Typiquement, on commit lorsqu’on a fini une étape (ajout d’une
fonctionnalité, correction de bug, …). Néanmoins, n’hésitez pas à faire des
commit intermédiaires si vous le jugez nécessaire.
Comment documenter le commit ? Commiter, c’est bien ; dire ce que contient la
version, c’est mieux (et indispensable). Lorsque vous faîtes un commit, vous
pouvez ajouter un commentaire (dans la fenêtre de l’outil utilisé). On y indique
typiquement :
Si la version est fonctionnelle.
La/les fonctionnalité(s) ajoutée(s).
Le(s) bug(s) corrigé(s).
La liste des fichiers modifiés et les modifications ne sont pas à documenter :
modifications à l’aide de l’outil de comparaison intégré😊
l’outil indique directement les fichiers concernés et on peut visualiser les
.
On peut alors visualiser les différentes versions avec l’affichage du « log » de
l’historique, mettre à jour sur une versions précédentes, …
3.4. Mise à jour
Avant de commiter, il faut toujours faire une mise à jour des données. Si par
exemple un collègue a corrigé un bug, il ne faut pas écraser sa modification avec
notre commit (le logiciel de gestion de version avertit généralement si on oublie de
le faire).
Lors de la mise à jour, le logiciel importe automatiquement les modifications
importées depuis la dernière fois que vous avez fait une mise à jour. S’il y a un
conflit (même ligne de code modifiée par exemple), le logiciel vous demande
généralement de vérifier vous-même en vous montrant la modification importée et
votre version pour que vous choisissiez/modifiez pour la nouvelle version à
enregistrer.
4. Utilisation
Ci-dessous sont présentées les principales fonctions.
4.1. Création du repository (base de données)
Sur GitHub Desktop, cliquer sur File / New repository :
Remplir les champs (dont le répertoire local où sera créé le répertoire contenant
les fichiers du code) et cliquer sur Create repository.
Le répertoire est copié en local. Il faut maintenant indiquer à GitHub de
« publier » le repository sur GitHub.com en cliquant sur Publish repository.
Vous avez alors :
En local, le répertoire où vous pouvez créer vos fichiers à suivre (code source,
éventuellement documents de suivi, …).
Sur GitHub.com, un nouveau repository où seront accessibles les fichiers
commités (et contenant la « base de données » des versions de fichiers).
Créez, modifiez vos fichiers sur le répertoire local. Lorsque vous le souhaitez,
vous pourrez « commiter » la première version ; je vous conseille de commiter
dès la création de vos fichiers (par exemple la base de départ de vos fichiers)
afin de pouvoir tracer les toutes premières modifications que vous ferez ensuite.
4.2. Commit
La liste des fichiers modifiés depuis le dernier commit apparait dans le volet de
gauche.
La liste des modifications pour le fichier sélectionné apparait sur le volet de
droite.
Vous pouvez choisir d’ignorer certains fichiers (temp.c ou *.bak par exemple) :
clic droit sur le fichier à ignorer / ignore …
Pour commiter :
En bas à gauche : indiquez un titre au commit (synthèse des modifications ou
nom du tag par exemple) et décrivez vos modifications.
Cliquez sur Commit to main.
Cliquez sur Push origin.
A noter que vous pouvez éditer vos fichiers texte (donc code source)
directement sur la page GitHub de votre repository et l’y commiter.
4.3. Visualisation de différences
La visualisation des différences se fait sur le web.
Allez sur la page de votre repository : Repository / View on GitHub
Ajoutez « /compare » à l’adresse.
Ex : https://github.com/S-e-b-G/Test/compare
Vous pouvez y indiquer la plage de date à comparer :
Ex : https://github.com/S-e-b-G/Test/compare/main@{2day}...main
Vous pouvez aussi indiquer les versions à comparer :
Aller sur GitHub desktop.
Aller sur le volet History (en haut à gauche).
Cliquer sur la version retenue.
Copier le numéro de version (SHA) :
Aller sur la page sous la forme :
https://github.com/S-e-b-G/Test/compare/[SHA-1]...[SHA-2]
A noter : vous pouvez télécharger une (ancienne) version d’un fichier et faire la
visualisation des différences avec votre fichier local (version de travail non
commitée par exemple) en utilisant un outil type Winmerge.
4.4. Récupération en local de la dernière version
Sur GitHub desktop, cliquer sur « Fetch origin » (en haut à droite) :
S’il y a (au moins) une modification à récupérer, vous pourrez appuyer sur le
bouton Pull origin :
4.5. Autres fonctions
D’autres fonctions moins utiles dans le cadre de ce projet sont possibles :
Branch : pour faire une version parallèle. C’est typiquement utile pour le
développement de deux projets similaires partageant une même base.
Tag : Pour « tagger » (étiqueter) une version particulière (par exemple lors d’un
passage de phase, une publication de version auprès du client, …).
Ce peut être utile pour vous si vous voulez mettre en exergue une version
particulière : set de fonctionnalités, version avant tests de vérification, avant
tests de validation, …
5. Conseils généraux
S’entrainer sur quelques fichiers « tests »
Ce type d’outils est indispensable pour un développement logiciel, mais l’utiliser
sans le connaitre un minimum peut ruiner votre travail. Avant donc de l’utiliser sur
votre projet, entrainez-vous dans un répertoire test sur des fichiers textes tests
pour comprendre les principales commandes.
En cas de doute, faire une copie du répertoire avant de faire une commande.
Une copie n’est pas longue et vous permettra de conserver votre travail si vous
n’êtes pas sûrs de la marche à suivre. N’oubliez pas que toutes les versions
précédentes, une fois commitées, sont sauvegardées et restent donc
accessibles.
Utilisez !!
Un développement logiciel sans gestion de version est comme jouer à la roulette
russe : avec de la chance, vous ne vous en servirez pas, mais c’est tellement
aléatoire (et peu probable) que le très léger surcoût en vaut largement la peine.
D’autre part, utiliser ce type d’outils vous aide (et vous oblige) à structurer votre
méthode de travail (commits réguliers, documentation a minima à chaque
commit, …) ce qui là aussi rentabilise largement le très léger surcoût de temps
pour l’utiliser.
Pour suivre le code, mais pas que 😉
Même s’il est surtout utilisé pour suivre les différentes versions de logiciel, le
principe de gestion de version peut être utilisé pour tout type de fichiers :
documents bureautiques (analyse fonctionnelle, architecture, nomenclature, …),
documents de développement (fichiers Matlab/Simulink, fichiers 3D, …).
Pour info, sachez que :
Google Drive propose une gestion des versions (sur Google Drive sur le web :
clic droit sur un fichier / Gérer les versions).
Matlab/Simulink peut réaliser le suivi par SVN ou GIT :
https://fr.mathworks.com/help/matlab/source-control.html
