Différences

Ci-dessous, les différences entre deux révisions de la page.

--- workshop_git [2024/03/21 07:20] – bigMax
+++ workshop_git [2024/04/03 07:49] (Version actuelle) – bigMax
@@ Ligne 17: / Ligne 17: @@
 ## Disclaimer
 - Plusieurs manières différentes de faire certaines actions
+- On montre beaucoup de commandes différentes dans cet atelier. L'objectif n'est pas de toute les apprendre, mais de sentir la philosophie et être capable de les retrouver au quotiden.
 - Lire les indication donnés par git qui sont très très très très utiles
 - Votre moteur de recherche préféré + stackoverflow sont vos amis pour trouver quoi faire en toute situation
@@ Ligne 24: / Ligne 24: @@
 ## help
 - git help
 - man git
@@ Ligne 30: / Ligne 29: @@
-## Tuto 1 cloner un repo (double window CLI / FS_Browser)
+## Tuto 1 : débuter en clonant un dépôt git existant (double window CLI / FS_Browser)
-### Etape 1 : "naviguer"
 ``` bash
 git clone git@github.com:mxbossard/mass.git
+git clone https://github.com/mxbossard/mass.git
+cd mass
 git branch
 git branch -r
 git switch develop
 git branch
-git status
 git log
 git log --pretty=oneline --abbrev-commit --graph --decorate
+git hist ORIG_HEAD.. --stat --no-merges
+```
+## Mot clés
+- repo : repository ou dépôt en français : structure conservant toute nos opérations git (peut être local ou distant) (un espace de stockage, une base de donnée)
+- tree : (arbre en français) structure de donnée interne représentant d'un dossier et tout son contenu
+- blob : structure de donnée intern représentant un fichier
+- commit : collections de fichiers & dossiers représentés par un hash (sha1)
+- HEAD : On peut voir ça comme une "tête de lecture" qui lit un commit et l'affiche dans notre repertoire de travail.
+- pathspec : expression representant un ou plusieurs chemins de fichier dans un dépôt
+- tree-ish : expression représentant un tree (ex: HEAD:README.md) (ex: HEAD) (les commits et tags sont déréférencés pour l'arbre vers lequel ils pointent)
+- commit-ish : expression représentant un commit (ex: HEAD) (ex: f8f3f58)
+- worktree / working tree / working directory : repertoire de travail qui reflete le contenu d'un commit
+- index / staging area : zone tampon qui stoque un tree contenant les modification en attente de commit
+- tag: pointeur vers un commit
+- branch :  pointeur vers un commit "mouvant" auquel on attache son working tree
+## Tuto 2 : modifier des fichiers comparer et commit les modifications
+``` bash
+git status
 git diff
 git diff HEAD
 git diff HEAD^
-```
-### Etape 2 : "modifier"
-``` bash
 echo foo > bar
 echo baz >> README.md
+mkdir pif
 git status
 git diff
@@ Ligne 56: / Ligne 73: @@
 git diff --staged
 git commit -m "ma modif"
+touch pif/paf
+git commit -a --amend
 git log
 git diff
@@ Ligne 62: / Ligne 81: @@
 ```
-### Mot clés
+## Fonctionnement
+### Interne
+</markdown>
+{{ :media_12:git_index_tree_blob.png?direct&800 |}}
+<markdown>
+[Documentation Git Internals - Git Objects](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)
-- commit : collections de fichiers & dossiers représentés par un hash (sha1)
+### Décentralisé
-- worktree / working tree / working directory : repertoire de travail qui reflete le contenu d'un commit
-- index / staging area : zone tampon qui stoque des modification en attente de commit
-- HEAD : pointeur vers le commit du working tree
-- tag: pointeur vers un commit
-- branch :  pointeur "mouvant" vers un commit
-## Fonctionnement
-### Decentralisé
 - Pas besoin de repo central
 - Tout l'historique en local
 - On peut commit dans son repo local
 - La réconciliation peut être compliqué si plusieurs personnes modifie le même fichier simultanément (classique, ce n'est pas magique)
+</markdown>
+{{ :media_12:git_layers_and_commands.jpg?direct&600 |}}
+<markdown>
 ### Commit Hash (sha1)
+Hash des données et méta-données contenu dans le commit. Une représentation du commit réputé unique dans un repo.
+- exemple de hash :       f8f3f58c67b5be45cc4595d0dace0728f5c9c9bf
+- exemple de short hash : f8f3f58
-Hash des données et meta-données contenu dans le commit. Une représentation du commit réputé unique dans un repo.
+### Branch
+Une branche pointe vers un commit, mais à la différence du tag, on "travail sur une branche". Cela veut dire que notre espace de travail (working dir) est en général accroché sur une branche. Lorsque l'on effectue un commit, ce commit est attaché à la branche, et devient le dernier commit de la branche.
-### Index
+</markdown>
+{{ :media_12:git_commits_tree_branches_tags.png?direct&600 |}}
-zone tampon qui permet de construire un nouveau commit
+<markdown>
 ### diff comme patch
+Les git diff permettent de produire des fichiers patch qui peuvent être appliqués à la main.
-les git diff permette de produire des fichiers patch qui peuvent être appliqués à la main
+</markdown>
+{{ :media_12:git_diff_sample_2.png?direct&600 |}}
+<markdown>
-## Tuto 2 travailler avec git
+## Tuto 3 : Initialiser son propre dépôt git et travailler dessus
 ``` bash
 git init myrepo
@@ Ligne 120: / Ligne 145: @@
 git switch develop
 ```
-Creer un repo sur une forge et plugger le repo remote sur notre repo local
+## Forges git
+### Exemples de forges git "Public"
+- [framagit](framagit.org)
+- [gitlab](gitlab.com)
+- [github](github.com)
+### Intérêts
+- Des outils graphiques en plus (diff, ...)
+- Un repo central souvent plus pratique pour callaborer
+- Fork & Pull Request organisé
+- Pipelines
+- Pages
+- ...
+### Exemples de solutions déployable
+Il existe des outils pour déployer dans une forge git privé.
+- gitlab : complet et lourd
+- gitea ?
 TODO
+## Tuto 4 : Creer et suivre (track) un remote repo (dépôt distant) sur une forge git
+Demo en live sur framagit.
+``` bash
 git remote
-git push
+git remote add origin git@framagit.org:labomedia/foo.git
+git remote
+git remote -v
+git branch -M main
+git push -uf origin main
+```
+Visit URL: https://framagit.org/labomedia/foo.git
 ## Quoi commit ?
-.gitignore file
+.gitignore file permet de configurer des fichiers à ne pas commit
-### A commit
+Attention, si vous avez commit un secret sur un dépôt distant, il faut considérer que le secret n'est plus secret.
+### Fichiers à commit
 - des sources
 - des test
 - des configurations applicatives
+### Fichiers à ne pas commit
+- des secrets (compliqué à retirer correctement)
+- des binaires (prend beaucoup trop de place)
+- des fichiers temporaires
+- la configuration de son IDE
-### A ne pas commit
+## Travail collaboratif
+- Lorsqu'on travail à plusieurs, Il est important de synchroniser sont repo local le plus souvent possible pour éviter de trop grosses divergences.
+- A plusieurs, il est toujours compliqué de travailler simultanément sur les même fichiers. Lorsque c'est possible, il vaut mieux s'attribuer à chacun une compétence sur des fichiers différents.
+- Il faut éviter de modifier les commits partagés cela équivaut à changer l'historique partagé par tous et ne vient pas sans problème sur les travaux en cours.
-- des binaires
+## Reset, Restore, Revert
-- des fichiers temporaires
+Il est parfois nécessaire de faire des opérations de "retour en arrière" :
-- la configuration de son IDE
+* Néttoyer son index (retirer des fichiers stagged) => git restore .
+* Néttoyer son working tree (on perd tous ses changements en cours) = > git checkout .
+* Annuler un commit => git revert (cela ne supprime pas le commit, mais créé un nouveau commit qui annule les modifications du commit annulé)
+* Modifier le dernier commit => git --amend (Il est relativement aisé de modifier des commits tant qu'ils ne sont pas partagés)
+* Supprimer le dernier commit => git reset HEAD^ (Il est relativement aisé de supprimer des commits tant qu'ils ne sont pas partagés)
+* Modifier un ancien commit => cela revient à modifier l'historique, c'est compliqué, il faut l'éviter le plus possible
+Il est facile de modifier des commit dans son repo local tant qu'ils n'ont pas été partagés dans un autre repo. Toutefois, il est toujours dangereux de modifier l'historique des commit, surtout lorsqu'on travail à plusieurs.
-## Travail collaboratif
+Attention, si vous avez commit un secret sur un dépôt distant, il faut considérer que le secret n'est plus secret.
-- Lorsqu'on travail à plusieurs, Il est important de synchroniser sont repo local le plus souvent possible pour éviter de trop grosses divergences.
+### git restore
+Manipule le "working tree" ou le "staging area". Ne change pas l'historique.
-- A plusieurs, il est toujours compliqué de travailler simultanément sur les même fichiers. Lorsque c'est possible, il vaut mieux s'attribuer à chacun une compétence sur des fichiers différents
+### git revert
+Annule les modifications d'un ou plusieurs commit. Ne change pas l'historique
+### git reset
+Permet de modifier l'historique (à faire avec précaution).
-## Forges git
+## Merge vs Rebase ?
+Débat d'ordre philosophique non tranchable. Cela dépend des pratiques de chacun, de l'équipe et du workflow de travail.
-### Public
+Les 2 opérations permettent de fusionner 2 branches en une. Typiquement on va fusionner la branch develop dans la branch main lorsque l'on a terminé ses modifications sur la branch develop.
-- framagit.org
-- gitlab.com
-- github.com
-### A déployer
+Les 2 opérations different dans la manière de réaliser cette fusion dans l'historique.
-TODO
-### Interets
+</markdown>
+{{ :media_12:git_merge_vs_rebase.jpeg?direct&600 |}}
+<markdown>
-- Des outils graphiques en plus (diff, ...)
+### Merge
-- Un repo central souvent plus pratique pour callaborer
+Ne modifie pas l'historique et ajoute un nouveau commit dans la branch accueillant la fusion.
-- Fork & Pull Request organisé
-- Pipelines
-- Pages
-- ...
+### Rebase
+Modifie l'historique afin de faire démarrer la branch fusionné à la fin de la branche accuillant la fusion.
-## Git flows
+### squash
-TODO
+## Git workflows
+Si on est nombreux sur un repo, il faut synchro son repo local souvent.
+### Minimal flow : quand on travail essentiellement seul (mon mien)
+- Au départ je ne m'encombre pas des branches et je travail sur la branche main (anciennement master)
+- Puis quand ma production est mature et que je veus faire de nouvelles modifications, je créé une branche develop
+- Lorsque je me lance dans un gros truc je créé une nouvelle branch nommé d'apres les travaux
+- Je tag avec une version semantic (0.0.1-rc2) chaque commit que je veux publier
+- J'essaye de remonter les tag commités dans la branch main autant que possible
+### Git flow : exemple de workflow pour travailler à plusieurs sans se marcher sur les pieds
 - Pour travailler seul et surtout a plusieurs nécéssaire de se mettre d'accord sur un procéssus
-- Expliqué une propal de git flow
+</markdown>
-- Linker d'autres git flows
+{{ :media_12:gitflow_1.webp |}}
+<markdown>
+[Une doc en français](https://mindsers.blog/fr/post/gitflow-la-methodologie-et-la-pratique/)
+[Une doc fr du plugin git-flow](https://danielkummer.github.io/git-flow-cheatsheet/index.fr_FR.html)
+### Autres
+TODO: Linker d'autres git flows
-### Reset, Restore, Revert
-TODO
-## Merge vs Rebase ?
+## Pull requests
 TODO
@@ Ligne 189: / Ligne 275: @@
 ### Alias tiptop
 ``` bash
-git config --global alias.s status
+git config --global alias.s "status"
-git config --global alias.who shortlog -sne
+git config --global alias.who "shortlog -sne"
-git config --global alias.changes diff --name-status
+git config --global alias.changes "diff --name-status"
-git config --global alias.dic diff --cached
+git config --global alias.dic "diff --cached"
-git config --global alias.d diff --stat
+git config --global alias.d "diff --stat"
-git config --global alias.hist log --pretty=oneline --abbrev-commit --graph --decorate
+git config --global alias.hist "log --pretty=oneline --abbrev-commit --graph --decorate"
-git config --global alias.lc !git hist ORIG_HEAD.. --stat --no-merges
+git config --global alias.lc \!"git hist ORIG_HEAD.. --stat --no-merges"
-git config --global alias.amend commit --amend
+git config --global alias.amend "commit --amend"
-git config --global alias.undo git reset --soft HEAD^
+git config --global alias.undo "git reset --soft HEAD^"
-git config --global alias.spull !__git_spull() { git pull "$@" && git submodule sync --recursive && git submodule update --init --recursive --remote; }; __git_spullgit config --global alias.spush push --recurse-submodules=on-demand
+git config --global alias.spull \!"__git_spull() { git pull "$@" && git submodule sync --recursive && git submodule update --init --recursive --remote; }; __git_spull"
+git config --global alias.spush "push --recurse-submodules=on-demand"
 ```
@@ Ligne 208: / Ligne 295: @@
 ## git init --bare
 TODO
+## Feedback 1er atelier
+- need git config user.email & user.name for fresh install
+- clone ssh repo may not works out of the box.
+- Montrer les schéma avant les definitions
+- Atelier de bout en bout git clone to pull
+- Atelier de bout en bout fork un repo faire une modif et proposer une PR.
+- Demander si on manip en premier ou si on fait les definitions en premier.
+- Si peu de manip, definition en premier peut etre bien.
 </markdown>