Git – Présentation basique et non-exhaustive
Matthieu FOURNET 29 septembre 2021 doc.callmematthi.eu/TOC_Git.html [email protected] Sommaire
1 Le versioning : quoi ? pourquoi ?
2 Git – généralités
3 Git en détail
4 Trucs en vrac
5 Mes $0.02 de dernière minute
Git – Présentation basique et non-exhaustive 2/117 Le versioning : quoi ? pourquoi ?
Git – Présentation basique et non-exhaustive 3/117 le versionnage (aka “versioning”)
mécanisme qui consiste à conserver la version d’une entité logicielle quelconque, de façon à pouvoir la retrouver facilement, même après l’apparition et la mise en place de versions plus récentes.
Git – Présentation basique et non-exhaustive 4/117 “versioning” manuel
Git – Présentation basique et non-exhaustive 5/117 “versioning” manuel, la méthode CPOLD
Git – Présentation basique et non-exhaustive 6/117 “versioning” manuel, la méthode “bavarde”
NB : cette méthode décrit les versions successives mais ne permet d’en restaurer aucune.
Git – Présentation basique et non-exhaustive 7/117 “versioning” manuel : le problème (1/3)
Ces méthodes (et bien d’autres) montrent que : le besoin de “versioning” est réel on a tous fait du CPOLD au moins une fois on a l’impression de versionner, sans le faire réellement faute d’outil dédié : on s’emm***e à versionner manuellement on le fait mal : demande une extrême rigueur pour être (peu) efficace procédé très sensible aux erreurs peu souple coûteux en temps + espace disque + gymnastique intellectuelle inadapté au travail en équipe
Git – Présentation basique et non-exhaustive 8/117 “versioning” manuel : le problème (2/3)
Il est impossible de versionner manuellement :
plusieurs fichiers inter-dépendants sur plusieurs versions avec un historique non linéaire
Rappel : “versionner” = être capable de restaurer n’importe quelle version d’une entité logicielle
Git – Présentation basique et non-exhaustive 9/117 “versioning” manuel : le problème (3/3)
avec 3 fichiers source, en 10 itérations, on a 23 fichiers en partant de la situation présente t10, comment restaurer : t3 ? t8 ? Git – Présentation basique et non-exhaustive 10/117 Un outil de “versioning” : pour quoi faire ?
collaboration : travailler à plusieurs sur les mêmes fichiers en même temps synchronisation : le travail de chacun profite à tous traçabilité : qui a changé quoi, quand, comment et pourquoi ? fonction avancées, outil de développement : “backup”/“restore” “undo” isolation des développements (branches)
Le “versioning” ne s’applique pas qu’au code et n’est pas réservé aux développeurs.
Git – Présentation basique et non-exhaustive 11/117 Historique : quelques outils de “versioning”
1970 : Panvalet 1972 : SCCS 1985 : RVS 1986 : CVS 2000 : BitKeeper, Apache Subversion (SVN) 2003 : darcs 2005 : Git, Mercurial, GNU Bazaar 2007 : Fossil ...
(source : https://en.wikipedia.org/wiki/Comparison_of_version-control_software\#History_and_adoption)
Git – Présentation basique et non-exhaustive 12/117 Git – généralités
Présentations Git vs “rest of the world”
Git – Présentation basique et non-exhaustive 13/117 Présentations
Git – Présentation basique et non-exhaustive 14/117 Git ... (1/2)
est un logiciel libre de “versioning” sous licence GPL v2 a été créé en 2005 par Linus Torvalds (entre autres) en moins de 15 jours pour le code source de Linux (détails ici, là, et là), cap du million de “commits” franchi en mai 2021 est écrit en C est versionné sous Git : https://github.com/git/git
Git – Présentation basique et non-exhaustive 15/117 Git ... (2/2)
est un logiciel de “versioning” parmi d’autres n’est pas le plus récent est / n’est pas le meilleur logiciel de “versioning” est le plus populaire actuellement :
nombre de questions sur stackoverflow.com (source)
Git – Présentation basique et non-exhaustive 16/117 Signification degit “ ”
littéralement (en anglais) : “une personne désagréable ou méprisable” (c’est-à dire : “un c*nnard”, Linus Torvalds ne cherchant pas à être “politiquement correct” à tout prix ;-) Sinon : un mot de 3 lettres, prononçable, et pas déjà utilisé par une commande Unix quand il fonctionne : “Global Information Tracker” quand il ne fonctionne pas : “Goddamn Idiotic Truckload (of sh*t)”
Git – Présentation basique et non-exhaustive 17/117 Git vs “rest of the world”
Git – Présentation basique et non-exhaustive 18/117 Git vs SVN : gestion des branches
les branches font partie du coeur de Git. Leur utilisation est : facile rapide encouragée SVN est moins pratique pour travailler avec des branches : plus long : la création d’une branche implique de dupliquer l’intégralité du dépôt vers un nouveau répertoire (consommation d’espace disque, délai de copie) en pratique, l’espace disque limite le nombre de branches plus compliqué lors du merge
Git – Présentation basique et non-exhaustive 19/117 Git vs SVN : Git est décentralisé
techniquement, aucun dépôt Git n’a le rôle de “point central” : tous les dépôts interagissent d’égal à égal on fait jouer le rôle de “point central” à l’un des dépôts pour des questions pratiques Git peut assurer ce rôle seul (via CLI + SSH + scripting) ou avec des outils tiers tels que GitLab ou GitHub
Git – Présentation basique et non-exhaustive 20/117 Git vs GitHub vs GitLab
GitHub : dispo via le web uniquement GitLab : peut être installé en local ajoutent des fonctionnalités à Git : visualisation du dépôt via une interface web : diff, commit, ... pull request, merge request, ... intégration continue + déploiement continu gestion de projets + dépôts + utilisateurs “ticketing” Wiki ...
Git – Présentation basique et non-exhaustive 21/117 Git en détail Briques de base Utiliser Git L’historique Les branches
Git – Présentation basique et non-exhaustive 22/117 Briques de base
Git – Présentation basique et non-exhaustive 23/117 Briques de base
(source : NDP Software Git cheatsheet)
Stash Workspace (ou Working Directory) Index (ou Staging Area) Local Repository Upstream Repository
Git – Présentation basique et non-exhaustive 24/117 Briques de base : Stash
. o O (ne pas oublier d’en parler plus tard...)
Git – Présentation basique et non-exhaustive 25/117 Briques de base : Working Directory
Répertoire et sous-répertoires dans lesquels se trouvent les fichiers suivis par Git c’est ici que l’utilisateur effectue des changements aux fichiers (ajout / modification / suppression) Git peut changer le contenu de cet espace sur demande explicite de l’utilisateur lors d’un changement de branche ou lorsque l’utilisateur consulte un état passé du dépôt
Git – Présentation basique et non-exhaustive 26/117 Briques de base : Index
Zone tampon dans laquelle l’utilisateur regroupe des changements en vue du prochain commit. équivalent “IRL”:“packaging” dans un entrepôt l’utilisateur peut ajouter ou retirer des changements à l’Index (changement = ajout / modification / suppression) il peut faire cela en une seule ou plusieurs opérations se termine par l’opération de commit
Git – Présentation basique et non-exhaustive 27/117 Briques de base : Local Repository
Base de données au format texte dans laquelle Git stocke l’historique du dépôt. visible sous la forme d’un répertoire .git dans le Working Directory ne JAMAIS aller farfouiller là-dedans !!! Même si une recherche Google vous a indiqué un moyen “infaillible” de résoudre votre problème. Il existe certainement une commande pour faire la même chose de manière sûre.
Git – Présentation basique et non-exhaustive 28/117 Briques de base : Upstream Repository
C’est le dépôt “central” géré par GitLab. 1
1. Au sein d’une équipe travaillant sur un projet commun, n’importe quel dépôt Git peut être l’Upstream Repository de n’importe quel autre dépôt (et réciproquement). Cela est rendu possible par la nature décentralisée de Git. En pratique, l’Upstream Repository est la plupart du temps un dépôt centralisé GitLab (ou équivalent). Git – Présentation basique et non-exhaustive 29/117 Briques de base : vue d’ensemble
(inspiré de : blog de Rachel M. Carmena)
Git – Présentation basique et non-exhaustive 30/117 Utiliser Git
Git – Présentation basique et non-exhaustive 31/117 Utiliser Git : cloner un dépôt
à faire une seule fois, en commençant à travailler sur le projet télécharge le contenu du dépôt dans le Working Directory télécharge l’historique du dépôt et crée la base locale Git – Présentation basique et non-exhaustive 32/117 Utiliser Git : fichiers suivis et non suivis
Git ne versionne que les fichiers explicitement déclarés avec git add utiliser les “wildcards” avec précaution : risque de surcharger le dépôt de fichiers inutiles. Éviter : git add * git add .
Git – Présentation basique et non-exhaustive 33/117 Utiliser Git : bonnes pratiques avec git add (1/2)
Idéalement, on ne versionne que du texte (code source, scripts, documentation, HTML, CSS, XML, SVG, ...). Git est optimisé pour gérer du texte (compression, recherche, comparaison, fusion, ...). On ne versionne pas les fichiers qui peuvent être obtenus à partir des fichiers versionnés, quel que soit leur type (exécutables compilés : problème de “l’oeuf-ou-la-poule”) Les fichiers “binaires” sont tolérés avec modération (ils alourdissent le dépôt). Si besoin, utiliser des outils tiers.
ATTENTION : chaque utilisateur devra télécharger l’intégralité du dépôt (contenu actuel + historique) en rejoignant le projet !!!
Git – Présentation basique et non-exhaustive 34/117 Utiliser Git : bonnes pratiques avec git add (2/2)
Lorsque la tentation est trop grande de “détourner” Git des cas d’usages “classiques”, il existe des outils dédiés : git-annex : synchronisation de répertoires Git-LFS :“versioning” de gros fichiers binaires
Git – Présentation basique et non-exhaustive 35/117 Parenthèse : comment SVN gère et stocke les versions successives d’un fichier
(source : git-scm.com)
SVN (et d’autres) stocke les informations sous la forme : d’une liste de fichiers et d’une liste de différences
Git – Présentation basique et non-exhaustive 36/117 Parenthèse : comment Git gère et stocke les versions successives d’un fichier
(source : git-scm.com)
Git stocke les informations sous la forme : d’un “snapshot” des fichiers, à chaque commit de références vers les versions précédentes pour les fichiers sans changements Permet à Git de sauter très rapidement d’une version à une autre, quel que soit le temps écoulé entre les 2.
Git – Présentation basique et non-exhaustive 37/117 Utiliser Git : pousser des changements vers le Remote Repository
git add : à utiliser à chaque changement sur un fichier une 1re fois pour qu’il soit suivi par Git. Dans ce cas, toutes les lignes du fichier seront considérées comme “nouvelles”. à chaque modification ultérieure.
Git – Présentation basique et non-exhaustive 38/117 Utiliser Git : voir les changements effectués
MODIFIED (édition d’un fichier suivi) : le changement n’est “vu” par Git que dans le Working Directory, avec git diff STAGED (changement déplacé vers l’Index avec git add): il n’apparaît plus dans le résultat de git diff, mais devient visible avec git diff --staged COMMITTED : le changement apparaît alors avec git diff
Git – Présentation basique et non-exhaustive 39/117 Utiliser Git : recevoir les modifications (1/3)
git fetch : met à jour la base de données locale laisse le Working Directory en l’état
Git – Présentation basique et non-exhaustive 40/117 Utiliser Git : recevoir les modifications (2/3)
git pull = git fetch + git merge git merge modifie le Working Directory : ATTENTION : aux fichiers ouverts !!!
Git – Présentation basique et non-exhaustive 41/117 Utiliser Git : recevoir les modifications (3/3)
git pull --rebase = git fetch + git rebase “rebase” : notion importante (on y reviendra)
Git – Présentation basique et non-exhaustive 42/117 L’historique
Git – Présentation basique et non-exhaustive 43/117 Info “évidente” qu’on ne trouve dans aucune doc sur Git Présentation de l’historique sous forme d’arbre :
horizontal vertical
schéma sens du passé à gauche passé en bas temps commits perles bleues branches lignes parallèles séparation “1 en 2” : nouvelle branche regroupementGit – Présentation basique et non-exhaustive“2 en 1” : fin d’une branche (merge) 44/117 Consulter l’historique
git log affiche : commit 95562d5d4365baebeb807358b30566bb18a6cf6a Author : Thomas ANDERSON
commit message, bla , bla et bla
commit 2e62144592bdb048c658e6163922c3b8bc0247ab Author : Thomas ANDERSON
commit message, ga, bu, zo , meu le commit ID l’auteur du commit (nom + email) la date + l’heure du commit le message de commit version plus compacte : git log --graph --oneline --decorate * 95562d5 commit message, bla , bla et bla * 2e62144 commit message, ga, bu, zo , meu comme en géologie : plus c’est profond, plus c’est vieux.
Git – Présentation basique et non-exhaustive 45/117 Voir les changements apportés par un/des commit(s)
git show
si
Git – Présentation basique et non-exhaustive 46/117 Voyageons dans le temps !!!
Git permet de consulter n’importe quel état passé du dépôt :
1 trouver l’ID de commit correspondant : git log
Git – Présentation basique et non-exhaustive 47/117 Point de départ : le présent
HEAD = “Vous êtes ici.” (source : https://marklodato.github.io/visual-git-guide/index-en.html)
Git – Présentation basique et non-exhaustive 48/117 Voyage “dans le présent”
Git – Présentation basique et non-exhaustive 49/117 Aller simple vers le passé
On vient de remonter de 3 commits dans le passé.
Git – Présentation basique et non-exhaustive 50/117 Et si je ne peux pas repartir dans le passé à cause de changements non “committés”?
git checkout modifie : l’Index le Working Directory Git refusera de faire un checkout si cela doit écraser ces données. Il faut donc les stocker quelque part “en attendant”. 2 solutions : git commit : ... et on n’en parle plus... mais c’est sale :-( git stash
Git – Présentation basique et non-exhaustive 51/117 git stash
man says : “Use git stash when you want to record the current state of the working directory and the Index, but want to go back to a clean working directory. The com- mand saves your local modifications away and re- verts the working directory to match the HEAD com- mit.” pile “LIFO” pour empiler : git stash pour dépiler : git stash pop ATTENTION : à ne rien oublier dans la pile à la fin !!!
Git – Présentation basique et non-exhaustive 52/117 Les branches
Git – Présentation basique et non-exhaustive 53/117 Définition :
Des questions ? :-D
Git – Présentation basique et non-exhaustive 54/117 À quoi sert une branche ?
À poursuivre un développement normalement (coder + tester + “committer” + recommencer) de manière isolée, sans altérer un état donné : pour un développement expérimental pour le développement d’une fonction (création d’une feature branch) pour isoler les différentes étapes du développement d’un logiciel : code “en développement” code “en beta-test” code “en pré-production” code “en production” Il existe des branches : permanentes temporaires
Git – Présentation basique et non-exhaustive 55/117 Branches permanentes (1/2)
cas d’usage : branches spécialisées par environnement (source : GitLab flow)
Git – Présentation basique et non-exhaustive 56/117 Branches permanentes (2/2)
autre exemple : modèle Git Flow source de débat chez les spécialistes : gain dépendant du contexte (détails) mais montre que Git peut être utile bien au-delà du simple “versioning” et peut s’intégrer dans un process de “Continuous Delivery”.
Git – Présentation basique et non-exhaustive 57/117 Branches temporaires
cas d’usage : feature branch bugfix refactoring expérimentation apparaissent et disparaissent naturellement au fil de la vie du projet durée de vie limitée, DOIVENT finir par : être mergées être détruites (avec ou sans merge)
Git – Présentation basique et non-exhaustive 58/117 Trop de branches temporaires = spagitty
Git – Présentation basique et non-exhaustive 59/117 Destin d’une branche temporaire : git merge
création d’un nouveau commit résultant de la “fusion” des 2 branches résolution éventuelle de conflits
ATTENTION : git merge “fusionne” une branche mais ne la termine pas. Pour cela, il faut explicitement la détruire : git branch -d
(source, voir aussi wikipedia.org)
Git – Présentation basique et non-exhaustive 60/117 2 types de merge (1/3)
3-way merge
Git – Présentation basique et non-exhaustive 61/117 2 types de merge (2/3) Cas particulier : fast-forward merge
aucun commit sur master pendant l’avancement de la branche some-feature rien à fusionner lors du merge il suffitavancer d’ rapidement (fast-forward ;-) master vers le dernier commit de some-feature la branche some-feature peut : recevoir de nouveaux commits être détruite : git branch -d some-feature
Git – Présentation basique et non-exhaustive 62/117 2 types de merge (3/3)
On peut choisir de ne pas faire un fast-forward merge pour la lisibilité de l’historique.
Git – Présentation basique et non-exhaustive 63/117 Trucs en vrac Installation + configuration initiale Glossaire mv et rm merge request / pull request Gestion de l’index avec git add “bon” commit / “mauvais” commit git rebase Corriger une erreur Commandes principales Obtenir de l’aide Commandes “rares mais utiles”
Git – Présentation basique et non-exhaustive 64/117 Installation + configuration initiale
Git – Présentation basique et non-exhaustive 65/117 Le strict minimum
1 apt install git 2 git config --global user.name "Thomas ANDERSON" 3 git config --global user.email [email protected] 4 git config --global core.editor emacs 5 cd path/to/your/future/working/directory 6 git init 7 enjoy ! NB : les paramètres spécifiés avec git config --global affectent tous les dépôts Git du poste de travail pour qu’un paramètre soit spécifique à un dépôt local, utiliser git config sans --global
(source : https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup)
Git – Présentation basique et non-exhaustive 66/117 Pour aller plus loin...
La configuration locale de Git est dans ~/.gitconfig : on peut y définir des alias (même principe que pour ~/.bashrc):
[ alias ] a = add ap = add −−patch b = branch co = commit d = d i f f −−color−words ds = d i f f −−staged (voir mon ~/.gitconfig) On peut aussi y définir un Commit Template afin d’être guidé lors de la rédaction des messages de commit
On peut aussi afficher le nom de la branche actuelle dans le prompt du shell : voir cet article (pour Bash).
Git – Présentation basique et non-exhaustive 67/117 Glossaire
Git – Présentation basique et non-exhaustive 68/117 Glossaire 1
tag : nom arbitraire donné à un commit avec git tag remote : dépôt “distant” lié au dépôt actuel peut être à l’autre bout du monde. Ou dans un répertoire du même disque l’URL de chaque remote “décrit” le protocole permettant de dialoguer avec lui (SSH, HTTPS, fichier local, ...) origin : nom par défaut du premier remote master : nom par défaut de la première branche HEAD : pointe sur le commit qui sera le parent du prochain commit. C’est un “vous êtes ici dans l’arbre de l’historique”. Peut être déplacé avec git checkout. Avance automatiquement à chaque commit.
Git – Présentation basique et non-exhaustive 69/117 Glossaire 2
master (ou n’importe quel nom de branche) : pointe sur le dernier commit de la branche. Avance automatiquement à chaque commit sur la branche. pointeur~n : pointe sur le commit situé n commits avant pointeur commitId~1 : père de commitId commitId~2 : grand-père de commitId pointeur^n : pointe sur le n-ième parent de pointeur commitId^1 : père no1 de commitId commitId^2 : père no2 de commitId (détails)
Git – Présentation basique et non-exhaustive 70/117 mv et rm
Git – Présentation basique et non-exhaustive 71/117 mv et rm
Git nous assiste pour gérer les changements Ne rien changer “dans son dos” : mv monFichier unAutreFichier Git va croire que monFichier a été supprimé et ne suivra pas unAutreFichier rm monFichier Git va croire que toutes les lignes de monFichier ont disparu, mais continuera de le suivre solution : git mv monFichier unAutreFichier git rm monFichier sans oublier de “committer” ces changements
Git – Présentation basique et non-exhaustive 72/117 merge request / pull request
Git – Présentation basique et non-exhaustive 73/117 merge request / pull request : définitions
fonctions de GitLab, GitHub & Co. n’existent pas dans Git dédiées au travail collaboratif + distribué : équipe “projet” dans une entreprise ou projet “open-source”(merge request) contribution à un projet “open-source”(pull request)
Git – Présentation basique et non-exhaustive 74/117 merge request
Git – Présentation basique et non-exhaustive 75/117 pull request
Git – Présentation basique et non-exhaustive 76/117 Ce qui nous amène à...
Qui veut expliquer à la classe ?
Git – Présentation basique et non-exhaustive 77/117 Gestion de l’index avec git add
Git – Présentation basique et non-exhaustive 78/117 Changements
Git – Présentation basique et non-exhaustive 79/117 git add
git add file1 file3 file4 ajoute tous les changements des fichiers spécifiés à l’Index Git – Présentation basique et non-exhaustive 80/117 git add --patch
git add --patch file1 file3 file4 permet de choisir interactivement quels changements seront ajoutés à l’Index (démo) on peut supprimer interactivement certains changements de l’Index avec git reset --patch
Git – Présentation basique et non-exhaustive 81/117 “bon” commit / “mauvais” commit
Git – Présentation basique et non-exhaustive 82/117 Mauvais1000 commit
Git – Présentation basique et non-exhaustive 83/117 Communiquer efficacement
communication efficace : qui ? quoi ? où ? quand ? comment ? pourquoi ? (combien ?) un bon commit répond à toutes ces questions
Git – Présentation basique et non-exhaustive 84/117 un bon commit précise :
qui ?, quoi ?, où ?, quand ? : dans les métadonnées du commit quoi ?, où ?, comment ? : dans le diff pourquoi ? : doit être expliqué dans le message de commit
La finalité duversioning “ ” est de pouvoir remonter dans le passé...Git – Présentation basique et non-exhaustive 85/117 Bonne pratique : commit atomique 2
“Il ne doit y avoir qu’une seule raison de faire un com- mit.” parce que sinon, comment on “undo”? s’il y a plusieurs raisons, il faut faire plusieurs commits : modifier + committer un seul changement à la fois git add --patch
“Cette raison ne doit être invoquée qu’une seule fois.” sinon cela signifie qu’une modification atomique est répartie dans plusieurs commits regrouper ces commits avec les commandes : git commit --amend git rebase (utiliser les termes “git squash” dans les recherches) (source : http://adopteungit.fr/methodologie/2017/04/26/commits-atomiques-la-bonne-approche.html) 2. atomique != nucléaire, atomique == indivisible Git – Présentation basique et non-exhaustive 86/117 Intérêt de faire des commits atomiques
réduit le risque de conflits facilite la résolution des conflits puisque le contexte de chaque changement est connu prérequis pour utiliser certaines fonctionnalités de Git : revert cherry-pick ... rend l’historique plus clair
Git – Présentation basique et non-exhaustive 87/117 Règle d’or
“Un commit est un état stable où tout fonctionne.”
Git – Présentation basique et non-exhaustive 88/117 Message de commit : bonnes pratiques
Doit expliquer pourquoi on a fait ce commit forme : message court : une seule ligne brève message long : 1 description succinte sur une seule ligne 2 ligne vide 3 description détaillée sur plusieurs lignes, paragraphes, listes, ... s’adresse à un pair : peut utiliser le jargon du métier doit mentionner une référence (si disponible) : numéro de ticket / d’incident, ID de tâche, ... possible de définir un template qui simule un formulaire pour rappeler les bonnes pratiques et guider lors du commit astuce pour commit de bugfix : “avant, ça faisait ça (...)”
Git – Présentation basique et non-exhaustive 89/117 git rebase
Git – Présentation basique et non-exhaustive 90/117 git rebase “re-base” = changer la base d’une branche permet : de faire un fast-forward merge de maintenir la branche à jour pour faciliter son futur merge
alternative, sans rebase : 3-way merge
Git – Présentation basique et non-exhaustive 91/117 git pull / git pull --rebase
avant :
git pull = git fetch + git merge
git pull --rebase = git fetch + git rebase
Git – Présentation basique et non-exhaustive 92/117 git rebase --interactive
permet de : changer l’ordre des commits regrouper plusieurs commits en un seul (squash) éditer les messages de commits
Git – Présentation basique et non-exhaustive 93/117 git rebase : conclusion (1/2)
git rebase (et ses variantes – cf git squash):
ne change pas globalement le contenu du dépôt : A-B-C-D-E == B-A-D-C-E agit sur l’historique du dépôt en “redessinant” l’arbre améliore la lisibilité de l’arbre facilite le “retour dans le passé” cache le détail du développement
Git – Présentation basique et non-exhaustive 94/117 git rebase : conclusion (2/2) git rebase modifie l’Histoire L’une des règles d’or de Git est : “On ne peut réécrire l’Histoire que si on est le seul à la connaître.” Risque de conflit (entre collègues) sinon (détails).
git rebase est une commande puissante et utile.
Git – Présentation basique et non-exhaustive 95/117 Corriger une erreur
Git – Présentation basique et non-exhaustive 96/117 Corriger une erreur sur le commit précédent
cas d’utilisation typique : erreur mineure, faute de frappe, oubli d’un “;”, ... N’affecte que le commit IMMÉDIATEMENT précédent (le 1er affiché par git log Ne pas utiliser cette méthode si le commit contenant l’erreur a été “pushé” : historique public
1 éditer le(s) fichier(s) concerné(s) 2 ajouter les changements à l’Index normalement 3 au lieu de créer un nouveau commit avec git commit modifier le commit précédent avec git commit --amend
Git – Présentation basique et non-exhaustive 97/117 Corriger une erreur sur un autre commit (1/2)
git revert permet de défaire un changement fait par n’importe quel commit en le “repassant à l’envers” ce changement devient un nouveau commit nécessite de trouver le commitId concerné avec git log
Git – Présentation basique et non-exhaustive 98/117 Corriger une erreur sur un autre commit (2/2)
git reset peut être utilisé pour supprimer une série de commits :
ATTENTION : git reset est l’une des rares commandes de Git qui supprime des informations du dépôt !!! “With great power ...”
Git – Présentation basique et non-exhaustive 99/117
(source : https://stackoverflow.com/questions/3639342/whats-the-difference-between-git-reset-and-git-checkout) Commandes principales
Git – Présentation basique et non-exhaustive 100/117 Git : commandes principales 1
git add
Git – Présentation basique et non-exhaustive 101/117 Git : commandes principales 2
git diff : affiche les différences entre 2 commits git log --name-status : liste les commits et les fichiers modifiés par chaque commit git log : liste les commits git ls-files : liste les fichiers suivis git pull : télécharge les changements depuis un dépôt git push : envoie mes changements vers un dépôt git rebase : change la source d’une branche git remote : gestion des remotes (configuré automatiquement par git clone)
Git – Présentation basique et non-exhaustive 102/117 Git : commandes principales 3
git reset : peut effacer des commits (mais “pas que”, cf “man page”) git revert :“undo” d’un commit git status : liste les modifications locales non “committées” 3
(source : https://git-scm.com/docs)
3. très approximatif Git – Présentation basique et non-exhaustive 103/117 À propos des commandes de Git Les commandes de Git ont de nombreuses options, parmi lesquelles : -f, --force --hard options en majuscules (git branch -D)
ici aussi ;-)
Git – Présentation basique et non-exhaustive 104/117 Obtenir de l’aide
Git – Présentation basique et non-exhaustive 105/117 Obtenir de l’aide
man git
Git – Présentation basique et non-exhaustive 106/117 Commandes “rares mais utiles”
Git – Présentation basique et non-exhaustive 107/117 git blame
git blame
Git – Présentation basique et non-exhaustive 108/117 git bisect
Permet de retrouver LE commit qui a introduit un bug ingrédients : un moyen –si possible– automatisé de détecter : la présence du bug : état BAD l’absence du bug : état GOOD l’état présent (BAD) un point de départ dans le passé (GOOD) Fonctionnement : git bisect 1 choisit un commit par dichotomie 2 détecte s’il est GOOD ou BAD 3 recommence jusqu’à trouver un GOOD suivi d’un BAD
Git – Présentation basique et non-exhaustive 109/117 Mes $0.02 de dernière minute
Git – Présentation basique et non-exhaustive 110/117 Se former / expérimenter avec Git
1 apt install git 2 mkdir -p /tmp/test && cd /tmp/test 3 git init 4 ... et c’est parti ! Il est très facile de se créer un bac à sable pour tester, casser et apprendre.
Git – Présentation basique et non-exhaustive 111/117 Quand le doute m’habite...
On trouve facilement, sur Internet, des réponses à nos “Comment on fait ... ?” Mais on hésite (parfois) à appliquer la solution à notre environnement de travail : peur de faire une bêtise de “casser” quelque chose de perdre notre travail Solution : travailler sur une copie conforme de notre dépôt, obtenue avec git clone
Git – Présentation basique et non-exhaustive 112/117 Conclusion
Git – Présentation basique et non-exhaustive 113/117 Conclusion (1/3)
Git a été conçu par les auteurs de Linux, pour versionner le code source de Linux, l’un des logiciels les plus complexes qui soient en termes de : nombre de lignes de code (+ de 15 millions) nombre de développeurs (plusieurs milliers) nombre de branches parallèles (euh... beaucoup !) Il est conçu et amélioré par ceux qui l’utilisent (no bullsh*t), en mettant l’accent sur : la simplicité l’efficacité la rapidité
Git – Présentation basique et non-exhaustive 114/117 Conclusion (2/3)
Git : est un logiciel réellement puissant, efficace, fiable et pas si compliqué ;-) est destiné aux développeurs, “mais pas que”! n’est pas la panacée (on peut faire de la m***e, même avec Git) impose peu de choses, permet toutes sortes de “workflows” (eux-mêmes sujets à de nombreux débats dans la communauté) est “l’outil qui se fait à la main de l’artisan”
Git – Présentation basique et non-exhaustive 115/117 Conclusion (3/3)
“Fear makes you a worse programmer.” Git fait partie des outils qui aident à “supprimer la peur” en permettant : de se lancer très facilement dans un développement expérimental (quitte à l’abandonner après coup mais, au moins, on ose “tester des trucs”) de toujours revenir à un état “stable” : le fameux monFichier.GOOD du CPOLD (on teste sans jamais rien casser) de faire des petits changements dans un processus itératif court : 1 coder 2 tester 3 livrer 4 recommencer
Git – Présentation basique et non-exhaustive 116/117 FIN
The End.
Git – Présentation basique et non-exhaustive 117/117