Lancer le diaporama

1.  de survie

• Mardi 13 novembre 2012
• Présentation de git à KNP Labs
• pour les First Jeudis de Nantes
• mais mise à jour depuis

---

2. Maîtrise du code source

« De tous temps, l’Homme a voulu maîtriser les versions de son code source, tant par rapport au temps qui passe que par rapport à la multiplicité intrinsèque du soi. »

---

3. Le plan du kit

Pourquoi et comment
Les commandes, le dotgit
La config, mais surtout les alias
Les trois arbres
Les références
Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

4. Le plan du kit

>>> Pourquoi et comment
Les commandes, le dotgit
La config, mais surtout les alias
Les trois arbres
Les références
Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

5. Pourquoi et comment

• Torvalds n’était pas satisfait de l’offre (perfs).
• Créé en avril 2005, maintenu par J.Hamano, devenu très populaire.
• Design révolutionnaire
  • sorte de file system distribué, cumulatif et cryptographique,
  • géré par une grosse boîte à outils (de multiples tailles).
• Deux couches :
  • « porcelaine » haut niveau, pour les humains,
  • « plomberie » bas niveau (mais à dispo), pour les autres.

---

6. Le plan du kit

>>> Pourquoi et comment
Les commandes, le dotgit
La config, mais surtout les alias
Les trois arbres
Les références
Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

7. Le plan du kit

Pourquoi et comment
>>> Les commandes, le dotgit
La config, mais surtout les alias
Les trois arbres
Les références
Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

8. Les commandes

• De la forme git cmd opts args.
• git
• Aide avec git help cmd,
• ou man git-cmd (faux barbu).
• Hint si typo (git knp).
• D’où alias git > alias shell.
• cd un_repertoire_de_travail
• git init

---

9. Le .git

• ls -a
• Pour rigoler, on versionne .git (avec ce même .git).
• git ne veut pas, donc on ruse :

  cd .git
    ln -s ../.git
    git status     # 3 f, 2 dirs (et 3 dirs "vides")
    git add *[^k]  # contenu pour le prochain commit
    git status     # A -> le .git originel

---

10. Le .git

• branches/
• config
  • très bientôt (prochaine section)
• description
  • fichier texte informatif
• HEAD
  • tête de lecture principale (contient le numéro du commit courant)
• hooks/
  • PS1=':$( [ $? == 0 ] && echo ") " || echo "( " )'
• index
  • ou stage, contient le patch qui va être commité
• info/
  • contient pour l’instant un fichiers d’exclusion
• objects/
• refs/
  • différentes têtes de lecture

---

11. Le plan du kit

Pourquoi et comment
>>> Les commandes, le dotgit
La config, mais surtout les alias
Les trois arbres
Les références
Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

12. Le plan du kit

Pourquoi et comment
Les commandes, le dotgit
>>> La config, mais surtout les alias
Les trois arbres
Les références
Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

13. Config et aliases

• git pousse à l’intégrité (soft) : « author ».
• Conf globale ou par dépôt.
• Mes alias et mes couleurs : gitconfig à mettre dans ~/.gitconfig ou .git/config.
• Comment lister les aliases ?
  • git config alias.al "config --get-regexp alias.*"
• Ajouter à ~/.gitconfig ou .git/config une section [user]
  • name = "mon nom"
  • email = "mon@email.com"
• ou utiliser git en tapant : git config --global user.name "mon nom"…

---

14. Config et aliases

git commit  # Message dans éditeur.
            # Un format normalisé.
git cm      # Pour un message d’une ligne.
git sl      # sl = short log
git s       # s  = show, montre le commit
            #      courant par défaut
git st      # st = status, ne montre
            #      ici que des ajouts:
            #      (`??` bleus).

Rappel : alias git > alias shell.

---

15. Config et aliases

• Modifions notre working copy,

  # insertion de blabla en tête de fichier
    sed -i '1iblabla' ./description
    # ajout de blublu en fin de fichier
    echo blublu >> ./description

• puis git st pour voir…
• Mais que signifient ces A, M, ces couleurs… ?

---

16. Le plan du kit

Pourquoi et comment
Les commandes, le dotgit
>>> La config, mais surtout les alias
Les trois arbres
Les références
Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

17. Le plan du kit

Pourquoi et comment
Les commandes, le dotgit
La config, mais surtout les alias
>>> Les trois arbres
Les références
Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

18. Les trois arbres

• Au moins trois en tous cas (distribution) :
  • .git/index (jaune) est l’intermédiaire
  • entre wc (copie de travail en rouge)
  • et repo (dépôt en vert).
• git diff (ou git d pour les flemmards) diff entre wc et index.
• git diff montre les modifs de tout à l’heure (./description).

---

19. Les trois arbres

Un commit se fait en trois temps :

1. choix du contenu
   • git add quelque_chose : wc → index
   • On peut même introduire les modifs depuis wc vers index au compte-gouttes :
   • git add --patch (alias git ap)
2. vérif du contenu
   • git diff --cached (alias git dc) diff entre index et repo.
   • C’est l’état de l’index qui va être commité.
3. le commit
   • git commit -m (alias git cm) pour mettre le message direct,
   • git commit a tout un tas d’autres options.

---

20. Les trois arbres

On peut passer du contenu dans l’autre sens.

• retirer du contenu de l’index :
  • git reset (cpte-gouttes avec -p)
  • Les modifs restent dans la wc.
• retirer du contenu de la wc :
  • git checkout (cpte-gouttes avec git co -p)
  • ATTENTION aux pertes de modifs avec git co !

---

21. Les trois arbres

À vous ! Un petit commit en trois temps.

1. Passer la troisième ligne de ./description dans l’index.
   • git add --patch chemin est interactif, la sous-sous-commande ? est utile.
   • git st donne alors deux couleurs à ce fichier, pourquoi ?
2. Vérifier avec git d et git dc.
3. Passer cette ligne dans le repo (commiter avec un message au choix).

---

22. Les trois arbres

Encore un effort :

• Passer la première ligne de ./description dans l’index,
• puis la retirer de l’index,
• puis la retirer de la wc (uniquement avec git bien sûr).

---

23. Le plan du kit

Pourquoi et comment
Les commandes, le dotgit
La config, mais surtout les alias
>>> Les trois arbres
Les références
Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

24. Le plan du kit

Pourquoi et comment
Les commandes, le dotgit
La config, mais surtout les alias
Les trois arbres
>>> Les références
Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

25. Les références

• Observons ce qu’il se passe dans .git lors d’un commit. git va nous le montrer lui-même.
• On a compris à quoi servaient ./index et ./COMMIT_EDITMSG.
• On peut les ignorer avec un .gitignore (glob et tout).
• .gitignore peut s’auto-ignorer (bof en général, mais là…).

  $ echo .gitignore >> .gitignore
    $ echo index >> .gitignore
    $ echo COMMIT_EDITMSG >> .gitignore

---

26. Les références

• Versionnons logs, objects et refs et eux seuls dans un même commit.
• git st nous permet de voir ce qu’il se passe dans .git lors d’un commit :
  1. modification de 3 fichiers :
     • deux dans logs,
     • un dans refs.
  2. création d’une foule d’objects.
• git diff montre que les logs logguent les états de refs/head/master.
• Mais que sont-ce ces hexas de 40km de long ?

---

27. Les références

• Là sont les entrailles de git.
• Un SHA-1 cache différents types de choses.
• Un commit contient :
  • des refs vers son contenu,
  • des refs vers ses parents (graphe orienté),
  • puis des données (auteurs et message).
• Son nom est le SHA-1 de son contenu : pousse à l’intégrité (hard).
• git cat-file -p 1234 pour observer l’objet stocké dans objects/12/34, (ou avec les alias : git cf 1234).

---

28. Les références

---

29. Les références

• Certaines commandes attendent une série de refs (log, rebase -i, …).
• Des requêtes très fines peuvent être formulées.
  
• Une visualisation intéressante : Git via D3.js.

---

30. Les références

• On commite les modifs et apparitions dans le .git lors du deuxième commit.
• Que s’est-il passé de spécial lors de ce troisième commit ?
• On pourrait continuer longtemps (git add logs objets refs, git commit).
• À noter : les objets sont accumulés, jamais modifiés,
  • permet un sauvetage, sauf si gc.
• À vous de jouer : ignorer les objets…

---

31. Les références

Pour ne pas encombrer git status, on ignore les objects.

$ echo objects >> .gitignore

Si plus tard on veut en ajouter,

$ git add objects
The following paths are ignored by one of your .gitignore files:
objects
Use -f if you really want to add them.
fatal: no files added
$ git add objects -f

---

32. Le plan du kit

Pourquoi et comment
Les commandes, le dotgit
La config, mais surtout les alias
Les trois arbres
>>> Les références
Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

33. Le plan du kit

Pourquoi et comment
Les commandes, le dotgit
La config, mais surtout les alias
Les trois arbres
Les références
>>> Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

34. Modifier l’histoire : ATTENTION

• Ne jamais modifier un graphe qui est sorti de votre dépôt.
• Après publication ou distribution, un repo se base sur les mêmes objets (donc ainsi que leurs relations) que l’original. Il faut que les intervenants aient les mêmes bases.
• Mais ça ne nous interdit pas de le faire AVANT publication.

---

35. Modifier l’histoire tranquille

• Le dernier commit est rarement publié automatiquement,
  • possible avec un hook.
• On peut donc recommiter par dessus avec :
  • git commit --amend (alias git amend)
    • Si l’index est intact, on modifie le message.
    • Si l’index est différent du repo, les changement s’ajoutent à ceux du commit écrasé.
  • git commit --amend -C HEAD (alias git amendc)
    • Si on ne veut pas changer le message.

---

36. Le plan du kit

Pourquoi et comment
Les commandes, le dotgit
La config, mais surtout les alias
Les trois arbres
Les références
>>> Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

37. Le plan du kit

Pourquoi et comment
Les commandes, le dotgit
La config, mais surtout les alias
Les trois arbres
Les références
Modifier l’histoire : attention
>>> Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

38. Dé-versionner

• Pour supprimer un fichier du repo tout en le gardant dans la wc :
  • git rm --cached chemin
  • Puis on commite.
  • On peut ensuite le gitignorer.
• Pour le réintégrer (avant ou après le commit) :
  • → devinette !
• Mais le fichier ne sort pas de l’histoire du repo…

---

39. Dé-versionner

• Sortir de l’histoire, c’est possible !

• git filter-branch --index-filter \
        "git rm -rf --cached --ignore-unmatch $files" HEAD
    git filter-branch --index-filter \
        'git update-index --remove $file' BAD_SHA1..HEAD

• Attention aux objets résiduels. Pour s’en débarasser : git gc --aggressive --prune.

---

40. Le plan du kit

Pourquoi et comment
Les commandes, le dotgit
La config, mais surtout les alias
Les trois arbres
Les références
Modifier l’histoire : attention
>>> Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
Bisect

---

41. Le plan du kit

Pourquoi et comment
Les commandes, le dotgit
La config, mais surtout les alias
Les trois arbres
Les références
Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
>>> Modifier l’histoire : les rebase
Bisect

---

42. Les rebase

• Plusieurs types :
  1. de branche en branche,
  2. au sein même d’une branche.
• Prenons une photo du .git pour observer le dépôt, sans oublier les objects que nous avons ignorés.

---

43. Rebase de branche en branche

• Webographie de cette section :
  http://think-like-a-git.net/.
• Plus précisément using git cherry pick to simulate git rebase.
• Les branches ne sont que des refs vers des commits.

---

44. Rebase de branche en branche

• On recopie C, D et E sur H.
  1. nouveaux objets,
  2. nouvelle branche temporaire.
• La copie se fait avec git cherry-pick (alias git cp).

---

45. Rebase de branche en branche

• On change le SHA-1 pointé par la branche que l’on « déplace ».
• En fait D et E sont toujours là, mais aucune branche ne pointe dessus.
• Une branche n’est qu’un commit à une extrémité ayant un nom (une des heads).

---

46. Rebase de branche en branche

• Comme on ne voit que les heads, le dépôt semble être dans cet état.
• On vérifie que tous les « objects » sont là avec git status.

---

47. Rebase sur une même branche

Autre type de rebase, le nettoyage d’une branche.

• Justifie le commit-mitraillette du codeur inspiré.
• Uniquement possible si working copy clean.

---

48. Rebase sur une même branche

• La haute voltige consistant à s’auto-versionner a ses limites,
  • le dépôt ne peut plus être dans un état clean (références versionnées).
• Exercice : repérer ces références et les déversionner !!!
  • Solution :

  • git rm -r --cached HEAD logs refs
      git commit -m "Unversion HEAD, logs and refs."

---

49. Rebase sur une même branche

Réinventons nous une histoire avec histoire.sh :

for i in $(seq 1 $1); do;
    echo "# ligne $i" >> test.sh;
    git add test.sh;
    git commit -m "Commit n°$i pour $2.";
done

Script à conserver dans ../histoire.sh, puis à lancer avec sh ../histoire.sh 20 test_rebase.

---

50. Rebase sur une même branche

Pour contrôler ce qu’il se passe dans logs et refs :

cp HEAD old_HEAD
cp -av logs old_logs
cp -av refs old_refs

---

51. Rebase sur une même branche

Pour un rebase plus ou moins interactif :

• git rebase --interactive <vieux_SHA-1> (alias git ri)
• En éditant le fichier proposé, on peut :
  • réordonner les commits (les lignes),
  • marquer un commit en vue de le modifier (e),
  • marquer un commit en vue de le fusionner avec le précédent (s ou f).

---

52. Rebase sur une même branche

• À chaque étape, on fait le boulot prévu.
  • modif ou insertion, fusion, gestion de conflits…
• Pour passer à l’étape suivante :
  • git rebase --continue (alias git rc)
• Pour revenir avant à l’état pré-rebase :
  • git rebase --abort (alias git ra)
• Puis git sl et git show <SHA-1> pour vérifier.

---

53. Rebase sur une même branche

• Observons les modifications dans le .git :

• git status
    diff old_HEAD HEAD
    diff -r old_logs logs
    diff -r old_refs refs

• Que des ajouts ou des mises à jour de head.
• Pas de destruction d’info et les logs permettent de revenir en arrière.

---

54. Le plan du kit

Pourquoi et comment
Les commandes, le dotgit
La config, mais surtout les alias
Les trois arbres
Les références
Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
>>> Modifier l’histoire : les rebase
Bisect

---

55. Le plan du kit

Pourquoi et comment
Les commandes, le dotgit
La config, mais surtout les alias
Les trois arbres
Les références
Modifier l’histoire : attention
Modifier l’histoire : dé-versionner
Modifier l’histoire : les rebase
>>> Bisect

---

56. Bisect

sh ../histoire.sh 1000 innocent
echo "exit 1" >> test.sh
git commit -am "Commit coupable."
sh ../histoire.sh 100 innocent
git blame test.sh
git bisect start, bad, good HEAD@{1100}
git bisect run sh test.sh
git bisect reset

Tweeter Suivre @profgraorg