• 12 heures
  • Facile

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 26/08/2019

Utilisez des techniques de nettoyage de branche

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Comment utiliser Rebase pour nettoyer votre branche ?

Nous avons vu dans le chapitre précédent que Git rebase était très utile pour modifier l'ordre des commits, et modifier les messages de commit. Nous allons voir maintenant que Git rebase est un véritable couteau suisse de Git. Il va nous permettre de modifier des commits intermédiaires avant d'envoyer sur le dépôt à distance.

Le rebasage interactif permet ainsi de maintenir la propreté et la cohérence de l'historique d'un projet.

Rappelons les commandes du rebase interactif :

# Commandes :
# p, pick = utilisez le commit
# r, reword = utilisez le commit, mais éditez le message de commit
# e, edit = utilisez le commit, mais arrêtez-vous pour apporter des changements
# s, squash = utilisez le commit, mais intégrez-le au commit précédent
# f, fixup = commande similaire à "squash", mais qui permet d'annuler le message de log de ce commit
# x, exec = exécutez la commande (le reste de la ligne) à l'aide de Shell 
# d, drop = supprimez le commit

Sélectionnons les deux derniers commits :

$ git rebase -i HEAD~2

Puis supprimons-les avec la commande Drop :

drop 58gkbg56 commit52
drop 899hbg78 commit53

Vos commits ont été supprimés et votre branche est désormais propre.

Supprimez les branches non suivies

Maintenant que vous savez comment nettoyer vos branches à l'aide Git rebase, il est parfois très utile de tout simplement les supprimer.

Prenons l'exemple des arbres, il y a des branches qui sont harmonieuses et que les paysagistes vont laisser, et d'autres qui ne sont pas jolies ou qui n'ont pas d'utilité et que l'on va tailler ! :)

Avec Git, on supprime les branches non suivies avec :

git branch -d brancheTest

Squash ? Débarrassez-vous des commits à tout va !

Ahah ! Du squash ? Nous ne parlons bien évidemment pas du sport de raquettes ici. :soleil:  Squash est encore une de ces super fonctionnalités du rebase interactif ! Un squash est un regroupement de plusieurs commits. Le but est de les fusionner en un seul pour avoir un historique Git plus propre. Il est notamment conseillé de le faire dans le cadre des envois sur le dépôt à distance, pour simplifier la relecture des modifications effectuées.

Mais alors, comment l'utiliser ? il s'utilise comme le reste des commandes du rebase interactif. On va aller sélectionner tous les commits nous intéressant, et on va leur appliquer la commande Squash !

git rebase -i HEAD~3

On leur applique la commande Squash :

pick 57dcsd58 Création du formulaire
squash 58gkbg56 Design Formulaire
squash 899hbg78 Correction du formulaire 

Concrètement, on dit à GIT de se baser sur le premier commit et on lui applique tous les suivants pour n’en faire qu’un seul.

Lorsque l’on valide le squash, Git va réappliquer les commits dans le même ordre dans lequel ils ont été configurés juste avant. On met alors un message de commit qui concerne le regroupement de nos commits.

Trouvez l’origine d’un bug avec Git bisect

On ne va pas se mentir, lorsque l'on développe, on perd beaucoup de temps à déboguer notre application. :euh: C'est toujours long et fastidieux de retrouver ce qui a pu provoquer le bug en question !

Le principe est plutôt simple. Vous indiquez à Git que vous cherchez un bug, il se déplace de commit en commit, vous testez la version et vous lui dites si le bug est présent dans le commit courant ou pas.

Le but est de retrouver le premier commit où le bug est apparu. Grâce à cela, vous saurez que l'une des modifications faites dans ce commit a causé le bug. ;) Il faut bien entendu avoir réalisé des commits réguliers. :) Si vous n'avez pas fait de commit depuis deux semaines, passez votre chemin ! Il faudra chercher le bug à la main.

D'où l'intérêt de tout petits commits : plus vos commits seront petits, plus l'utilisation de  git bisect  sera utile, puisqu'elle permettra de localiser plus précisément où est situé le bug dans votre code. :D

On commence par la commande start :

git bisect start [bad] [good]

Au lieu de bad, vous devrez mettre le hash d'un commit où le bug est présent. À la place de good, vous devrez mettre le hash d'un commit où le bug n'était pas présent !

Git va alors naviguer dans chacun des commits entre les deux, dans le but de trouver le premier commit où le bug est apparu.

Git va se déplacer sur chaque commit et vous allez devoir, pour chacun de ces commits, lui indiquer si le commit est good ou bad.  :)

Si le commit ne présente pas le bug :

git bisect good 

Si le commit présente le bug :

git bisect bad 

Une fois chaque commit vérifié, Git va vous indiquer le commit qui a provoqué le bug. Il va l'indiquer de cette manière :

fvsd54g5s5d4g5f34g5dfg47df578q9qdff6 is first bad commit
commit fvsd54g5s5d4g5f34g5dfg47df578q9qdff6
Author: Moi <Moi@example.com>
Date: Tue mar 27 16:28:38 2019 -0800

 Add fonctionnality AB

Il ne vous reste plus qu'a trouver dans vos modifications, la modification qui a engendré le problème. :)

Passons à l'intégration d'autres dépôts !

Exemple de certificat de réussite
Exemple de certificat de réussite