Notes concernant Git et les méthodes de développement associées

logiciel-libre
#1

J’ai approfondi mon utilisation de git cette dernière semaine. Voici mes notes :

Sommaire

  1. Résumé (très) concis du (trop) strict minimum pour utiliser Git
  2. Visualiser l’historique des modifications du code
  3. Signer ses actes (commit) et étiquettes (tag) avec GPG
  4. Modifier les métadonnées d’un commit
  5. Retravailler un commit s’il n’est pas assez granulaire
  6. Retravailler ses derniers commit locaux avant de les pousser
  7. Correctement fusionner pour une bonne gestion des branches

Résumé (très) concis du (trop) strict minimum pour utiliser Git

  1. cd (mon/répertoire)
  2. git status
    • pour savoir où le système en est dans l’indexation des fichiers.
  3. git pull
    • pour récupérer le travail distant et le fusionner directement avec le travail local.
  4. (travail)
  5. git add
    • pour indexer le ou les fichiers modifiés.
  6. git commit puis rédaction d’un petit texte dans un éditeur pour générer l’acte (=commit).
  7. git push
    • pour « pousser » l’acte sur le dépôt distant.

Visualiser l’historique des modifications du code

Précision sémantique, log peut se traduire par « journal de bord » en français ; on va le comprendre ici par le mot historique.

  • git log bien sûr

    • Notament avec l’option -n (suivi d’un chiffre) pour limiter le nombre des commits affichés aux n derniers.
  • Mais surtout :

    • git log --oneline
    • git log --all --graph --pretty="%C(auto)%h %Creset%ae %Cred%ad %C(auto)%d %Creset%s" --date=iso
      • --date=short est une bonne alternative.

Signer ses actes (commit) et étiquettes (tag) avec GPG

  • Une fois pour toute : git config --global user.signingkey XXXXXXXX
    • avec XXXXXXX l’empreinte de notre clé PGP.
  • Désormais, on pourra utiliser l’option -s à git commit et git tag :
    • git commit -s
    • git tag -s

Modifier les métadonnées d’un commit

  1. git checkout (hash du commit) si HEAD ne pointe pas déjà dessus.
  2. git commit --amend
    • --author "Bon Nom <email@addresse.fr>" pour le nom et l’email de l’auteur de la modification de code.
    • --date=YYYY-MM-DDTHH:MM:SS (c’est le format iso) pour la date de commit.
  3. Probablement rebaser les commits pour reconstruire un historique cohérent git rebase (branche de rebasage) (branche à rebaser).

Retravailler un commit s’il n’est pas assez granulaire

  • git checkout (hash du commit) si HEAD ne pointe pas déjà dessus.
  • git reset HEAD~
  • git add -p (-p pour –patch) puis git commit
    • C’est pour n’indexer puis committer que des parties d’un commit (sections ou hunks).
    • On répond à ce que nous demande Git avec par exemple :
      • y (yes) ou n (no) pour inclure ou pas la section dans le futur commit.
      • s (split) pour scinder automatiquement la section (hunk) présentée.
      • e (edit) pour éditer la section présentée notamment si elle est trop difficile à scinder pour Git.
    • C’est à refaire autant de fois que nécessaire.
  • On peut terminer par un git add simple et un git commit.
  • Si la date du commit original est à garder, le préciser sur chaque nouveau commit avec des git commit --date==YYYY-MM-DDTHH:MM:SS.
  • À la fin, il faudra probablement rebaser les commits pour reconstruire un historique cohérent : git rebase (branche de rebasage) (branche à rebaser)

Retravailler ses derniers commit locaux avant de les pousser

  • git fetch éventuellement pour récupérer le travail distant des collaborateurs.
  • git rebase -i (nom de la branche d’intégration) (nom de notre branche de travail locale)
    • -i pour interactif
  • Dans le tampon de l’éditeur de texte qui s’est lancé, on va pouvoir (du plus simple au plus compliqué) :

    • Reformuler des messages de commit avec reword.
    • Supprimer des commits en virant leur ligne respective.
    • Réordonner les commit en agençant différemment les lignes (avec discernement car comme certains commits sont parents d’autres commits, ça ne fonctionne pas toujours sans conflits).
    • Regrouper des commits en un seul avec squash ou fixup.
    • Revenir sur des commits (et notamment les découper) avec edit.
  • S’il s’agit de découper un commit lors du rebasage interactif, voir la section précédente. Pour mémoire :

    1. git reset HEAD~
    2. git add -p puis travail sur les sections (hunks)
    3. git commit

Correctement fusionner pour une bonne gestion des branches

Sources Bien utiliser git merge et rebase sur le site Delicious Insights et Rebaser les branches avec git rebase dans le Git Book.

  • Rappels sur git branch

    • -m
      • git branch -m (nouveau nom) pour renommer la branche courante.
      • git branch -m (vieux nom) (nouveau nom) pour renommer une branche quelconque.
    • -d pour supprimer une branche
  • git checkout (nom de la branche dans laquelle on veut travailler)

  • git fetch pour repérer le travail effectué par les collègues (ne plus utiliser git pull)

  • S’il s’agit d’une branche sémantique (pour laquelle ça a du sens de la montrer : développement de fonctionnalité ou correction de bug), il faut que l’historique garde sa trace avec une bosse même si la branche d’intégration n’a pas évolué.

    • git fetch pour récupérer le travail éventuel distant (ou pas)
    • éventuellement un git log --oneline pour connaître les hash pour l’étape suivante.
    • éventuellement (ou pas) git rebase (hash du commit de rebasage) (branche à rebaser)
    • et surtout : git merge --no-ff pour “no fast forward” pour être sûr que la bosse ne disparaisse pas même s’il n’y a aucune divergence.
    • git branch -d (branche désormais intégrée)
  • S’il ne s’agit que d’une branche technique (locale et temporaire), il faut la noyer dans l’historique de la branche d’intégration même si celle-ci a évolué. Si c’est le cas, on va donc tenter de rebaser notre branche technique sur le dernier commit de la branche d’intégration, afin que notre branche technique redevienne une descendante de la branche d’intégration.

    • git fetch pour récupérer le travail éventuel distant.
    • éventuellement un git log --oneline pour se rappeler des noms de branches pour l’étape suivante.
    • git rebase (branche de rebasage) (branche à rebaser)
    • git checkout (branche de rebasage)
    • git merge (branche à rebaser)
    • git branch -d (branche désormais intégrée)
1 Like

#2

git pull = Git fetch + git merge
git pull --rebase = Git fetch + git rebase

juste une petite précision :slight_smile:

1 Like