Gestion du code source
- cours
- projet
- François Brucker
Comment gérer le code source d'un projet des principes au repository github.
La gestion du code source (SCM pour Source Control Management) est bien sûr utilisée massivement en informatique, mais les méthodes et techniques mises en œuvre fonctionnent pour tout projet où l'on doit utiliser/produire des documents qui sont modifiés au cours du temps. C'est un cadeau fait par les informaticiens au monde (ne le détruisez pas comme la gestion de projet agile...).
Un des bénéfices d'une gestion des documents bien comprise est que l'on peut :
- archiver et retrouver facilement toutes les évolutions d'un projet,
- travailler sur plusieurs versions d'un projet en même temps.
Mais surtout : ne pas avoir peur de modifier, tester et expérimenter des nouveautés.
Ces bénéfices sont incommensurables lorsque l'on travaille à plusieurs sur un projet et sont très utiles même pour un projet solo.
Principes : gestion des sources comme un dépôt
Après avoir examiné les besoins qui impliquent l'utilisation d'un SCM, on en verra une implémentation possible sur une structure distribuée et l'usage qu'on peut en faire au quotidien.
Besoins pour un dépôt
Structure distribuée
Pour que son accès soit facile, il faut que la structure de stockage soit sur le même ordinateur que celui ayant le répertoire de travail.
Si cette solution est idéal lorsque l'on est un unique développeur, elle devient plus complexe à mettre en œuvre si on est plusieurs à travailler sur le projet. Il faut :
- en avoir une copie de la structure de stockage chez chaque participant,
- permettre à plusieurs personnes de travailler sur le même fichier,
- permettre le travail asynchrone entre les personnes : une personne va avancer à un endroit pendant qu'une autre travaille sur autre chose
- pouvoir reprendre un projet existant avec une nouvelle équipe
Ceci implique que chaque copie soit synchronisée par un dépôt référent, un projet référent faisant autorité pour tous les participants.
Une bonne implémentation consiste à ne pas sacraliser la mise en commun. Il faut le faire le souvent pour que tout le monde ait une version claire de l'ensemble actuel du projet.
À retenir
Lorsque vous utilisez un projet en commun il faut avoir un dépôt commun mais ne faut pas en sacraliser la mise en commun avec des règles de soumission stricte ou un superviseur.
Dépôt origin
Nous allons utiliser https://github.com/ comme dépôt commun de nos projet. Le site fonctionne avec logiciel de gestion de sources git. Il en existe d'autres, comme https://gitlab.com/ par exemple.
Projet Dépôt
Principes : gestion des sources en local
Besoins pour une gestion des sources locale
Projet : gestion des sources
Principes : gestion d'un dépôt distant
Besoins pour l'utilisation d'un dépôt distant
Projet : local et origine
Usage courant
Outre ce qu'on a vu au préalable l'usage d'un SCM au quotidien nécessite quelques connaissances supplémentaires qui permettent de que nous allons aborder maintenant.
Sha
À tout objet de git est associé un nombre écrit en hexadécimal correspondant à son hash avec la fonction de hachage sha-1.
Ceci permet de retrouver de façon unique (au moins en probabilité et sûrement pour un projet donné) tout ce que stocke git.
TBD projet voir le sha.
Diff
TBD faire un exemple avec la commande diff au terminal : deux fichiers (lignes ≠) et deux dossiers (deux fichiers ≠) TBD sous windows https://learn.microsoft.com/fr-fr/troubleshoot/windows-client/shell-experience/how-to-use-windiff-utility ou https://www.git-tower.com/blog/diff-tools-windows
On a déjà vu le diff des fichiers lors de nos commits et en particulier lorsque l'on a résolu un conflit de fusion. Cela vaut le coût de connaître le format utilisé :
Notez que l'on peut faire nous même des diff au terminal :
Commande diff au terminal :
Les algorithmes utilisés pour faire un diff sont basés sur le problème de l'alignement de séquences. Ils ne travaillent cependant sur des caractères mais sur des lignes. Si cela vous intéresse suivez les liens suivant pour une introduction :
Altération et modification de l'historique
TBD projet avec desktop voir https://docs.github.com/en/desktop partie managing commits.
Authentification
Github actions
TBD :
- permet de mettre en place du CI/CD : https://www.youtube.com/watch?v=scEDHsr3APg
- github actions https://www.youtube.com/watch?v=p3W2XCD3smk
Git
- Linus Torvalds a crée git en 10 jours (et le 11ème il s'est reposé)
- Une histoire de git en français
Est l'outil utilisé par github. C'est mieux si vous avez installé ce logiciel sur votre ordinateur et que vous savez un petit peut vous en servir. Cette partie vous permettra d'installer git et de le configurer. On verra aussi comment créer et cloner un projet pour github.
Connexion ssh à github
Nous allons utiliser des clés ssh pour se connecter à github, donc si vous ne l'avez pas encore fait :
Puis renseignez votre clé publique dans votre profil github.
Installation et configuration
Les notions que l'on a vu précédemment suffisent pour un usage courant de la gestion des sources avec github. Si vous voulez :
- utiliser git avec votre éditeur de texte comme vscode
- ou si vous voulez utiliser git en ligne de commande pour contrôler toutes vos opérations
Il vous faudra installer le programme git
en ligne de commande.
L'installation et la configuration de git n'est pas très technique. Cela vaut le coup de de le faire ne serait-ce que pour pouvoir utiliser les magnifiques plugins de vscode.
Outils
App
Outil tout en un pour utiliser github :
Git avec vscode
vscode permet d'utiliser directement les commandes git et possède de nombreux plugins permettant, par exemples :
- d'utiliser github avec l'extension github
- de voir le graphe de dépendances avec l'extension git-graph (commande
git-graph.view
pour voir le graphe) - de voir l'historique de modification d'un fichier avec l'extension git-history (cliquer droit sur un fichier puis
Git: view file history
) - ...
TUI
- lazy git (une courte vidéo de présentation) : une excellente application pour git
- gh-dash : pour github et les pull requests
Bonnes pratiques
Porcelaine et plomberie de git
TBD expliquer porcelaine/plomberie
Porcelaine
Plomberie
TBD un tag c'est un objet. Commit, tree ou blob. TBD work-trees et stash TBD utiliser switch et pas checkout pour passer de branches en branches (checkout pour les commits particulier: headless ?) TBD : index = staging area. TBD diff format et différents algos TBD https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things
TBD reflog. TBD git sha. Intro : https://medium.com/@jonathan_finch/git-commit-hash-number-theory-770f67ec492d et https://graphite.dev/guides/git-hash. Mieux : https://www.designgurus.io/answers/detail/how-do-i-get-the-hash-for-the-current-commit-in-git
Cette partie du cours s'adresse plus particulièrement aux informaticiens voulant utiliser git en ligne de commande et/ou à ceux voulant comprendre le fonctionnement précis de git.
Bibliographie
Cours
Références
Misc
- https://learngitbranching.js.org/
- https://tonyg.github.io/revctrl.org/index.html
- https://ohshitgit.com/