Git Dammit!

Appuyez sur N pour afficher les notes

@mghignet

TDM/s

T'as deux minutes ?

- Paul Request
- Jane Kins
- Maxime

Ça ne permet pas de s'y retrouver
La revue de code est plus difficile
Les projets Open source le requièrent
Des outils existent pour générer des changelogs

De un, allez tenter de comprendre la démarche de quelqu'un qui fait ce genre de commits, 6 mois après, en vous disant "mais oui, ce changement là, c'était dans ce commit !"

De deux, la plupart des projets Open source demandent une certaine rigueur, que ce soit niveau testing ou conventions de commits.

Aussi, peut-être aimez-vous faire vos revue de code en procédant "commit par commit", surtout pour les gros changements. Avec du code éparpillé dans tous les commits, c'est impossible de procéder comme ça. Vous avez peut-être déjà rencontré une situation où vous commentez une modification dans un commit qui disparaît dans le suivant ?

Enfin, à partir des messages de commits, on peut faire d'autres choses... comme générer des changelogs. Du coup on ouvre nos messages de commits à un public plus important que juste les développeurs, et tous doivent comprendre sans lire le code, si tant est qu'ils y aient accès.

On tire une branche
On fait un ou plusieurs commits
On soumet sa branche à une revue de code

T'as oublié un point virgule dans ton dernier commit.

Paul

git add, puis...

# Le contenu et le nom
git commit --amend

# Le contenu seulement
git commit --amend --no-edit

# Bien entendu il faudra « force push »
git push -f origin ma-branche

Ce serait pas une faute d'orthographe ça ?

Jane
(C'est "Tuning", pas "Tunning")

Deux étapes

1. Créer un commit
de FIXUP

```
git commit --fixup A
```

2. Réécrire l'historique
REBASE

```
git rebase -i A~ --autosquash
```
-i : mode interactif
A~ : le parent de A
--autosquash : placer le commit de fixup au bon endroit

Oula, mais c'est quoi cette commande barbare ?

C'est simple, on va la découper :

-i: Le mode intéractif nous permet de choisir comment réécrire les commits: les renommer, les réordonner, changer leur contenu... plein de choses sont possibles.

A~: Quand on rebase, on se replace dans le passé pour faire comme si on n'avait pas encore créé les commits que l'on va réécrire. Du coup, si on veut réécrire l'historique à partir (et en incluant) A, il faut se replacer, non pas sur A mais juste avant. C'est ce que fait le tilde: il désigne le parent de A. En général, ajouter un tilde à un sha1 désigne le parent du commit désigné par le sha1.

--autosquash: Cela permet de replacer le commit de fixup directement au bon endroit pendant la procédure interactive.

# Ou un alias git dans mon .gitconfig
[alias]
  fixup = !sh -c 'SHA=$(git rev-parse $1) \
       && git commit --fixup $SHA \
       && git rebase -i --autosquash $SHA~' -
# Utilisation : git fixup {sha1}

# Encore une fois...
git push -f origin ma-branche

Oups ! J'ai modifié mes commits, et puis j'ai fait un pull.

Je me retrouve avec des commits en double :(

# Il fallait « force push »…
git push -f origin ma-branche

Il me semble qu'on avait dit qu'on ne développait plus les roues bleues ?

Jane.

Imaginons nous sur notre repository Git, en local, ayant notre fichier file.txt en version 1.

On distingue 3 notions différentes pour la gestion des sources.

- Le Working Directory: c'est ce qui se trouve effectivement sur votre disque dur : ce que vous voyez et pouvez modifier dans votre éditeur favori.

- L'index: Lorsque Git indexe les fichiers (git add), il crée dans le dossier .git un ensemble d'objets contenant le contenu des fichiers. Il crée aussi d'autres objets pour sauvegarder la hiérarchie et le nom de chaque fichier indexé. Tout cela forme un snapshot, prêt à être commité. D'ailleurs, un commit est un objet qui référence un snapshot.

- HEAD: C'est notre position actuelle sur Git. C'est à dire le commit sur lequel nous pointons. En d'autres termes, c'est un pointeur vers le commit en haut de la pile lorsque l'on lance un git log. Et donc par exemple si je me place sur master, alors HEAD, master et le dernier commit de master référencent exactement la même chose.

# On garde les modifs, indexées
git reset HEAD~ --soft

# On garde toujours les modifs mais non indexées
git reset HEAD~ --mixed
git reset HEAD~

# On supprime toutes les modifs
git reset HEAD~ --hard

J'ai tout cassé !

Comment je reviens à la version du repository distant ?

Pull ? Fetch ?

```
git pull origin master
```

git fetch origin master
git merge master

git fetch origin feature1
git reset --hard origin/feature1

# A placer dans le .gitconfig
[alias]
  dammit = !BRANCH=$(git rev-parse --abbrev-ref HEAD) \
    && git fetch origin $BRANCH \
    && git reset --hard origin/$BRANCH
# Utilisation : git dammit

Ok pour les modifs, mais tu t'es basé sur ma branche, pas sur master !

Paul

- ```
# On n'oublie pas le ~ tilde ~ !
git rebase E~ --onto master
```
- E~ : On réécrit à partir de E
- --onto master : Au dessus de master

Quelques Astuces à emporter...

Comment voir les modifications en cours ?

```
# Modifications non indexées
git diff
```

# Modifications indexées
git diff --cached
git diff --staged

# Toutes les modifications
git diff HEAD

# Les modifications entre deux commits / branches
git diff ab0f..89df
git diff ab0f..master
git diff ab0f..HEAD

Je veux séparer les modifications d'un même fichier dans deux commits différents.

# pour indexer des modifications
git add -p

```
# Dans l'autre sens
git reset -p
```

Je veux revenir sur la branche sur laquelle j'étais juste avant.

# Comme "cd -" en shell !
git checkout -

Je veux annuler les modifications faites sur un fichier en particulier.

# Cette méthode a des défauts...
git checkout monFichier.ext

# Tout ce qui suit le "--"
# est considéré comme un nom de fichier
git checkout -- monFichier.ext

Merci !

mghignet.github.io/git-dammit-talk/

@mghignet

Git Dammit!

TDM/s

T'as deux minutes ?

Deux étapes

1. Créer un commit

de FIXUP

2. Réécrire l'historique

REBASE

Pull ? Fetch ?

Quelques Astuces à emporter...