Les commandes Git – branches, rebase… (2/3)

Wodric0

Nous poursuivons la série d’article sur Git, vous pouvez retrouver les articles précédents aux liens suivants:

Ce deuxième article est l’occasion de présenter d’autres commandes Git relatives aux branches, aux tags et au processus de merge. L’objectif de cet article est de permettre à un développeur de s’intégrer dans un workflow de développement plus complexe basé sur des branches.

Vous pouvez retrouver l’articles suivant ici :

Gérer les branches

La gestion des branches de git est un des ses points forts. Légère et très facile à utiliser ces dernières permettent de travailler en utilisant des workflows puissants.

Ces workflows concernent aussi bien la manière de développer en local (Workflow de développement) que les workflows utilisés par les équipes de dev (ex : gitflow ou github flow).

Voici quelques commandes de bases sur les branches.

Pour récupérer la liste des branches disponible en local:

git branch

Détail intéressant, cette commande permet également de savoir quel est la branche courante en la notifiant d’une étoile « * ».

Récupérer la liste des branches du dépôt distant:

git branch -r

De cette manière, on peut voir les éventuelles nouvelles branches disponibles sur votre dépôt.

Création d’une branche:

git branch monNomDeBrancheACreer

La commande précédente ne fait que créer la branche.

Créer une branche et aller dessus :

git checkout -b monNomDeBrancheACreer

Changer de branche:

git checkout brancheARecuperer

Supprimer une branche:

git branch -d branchASupprimer

Gérer les tags

Un tag permet de marquer le code à un instant précis, souvent la révision d’un livrable. Par exemple, il permet de retrouver la version du code associée à une vieille version de l’application qu’un client chiant refuse de mettre à jour pour laquelle il veut la correction d’un bug ;).

Lister les tags:

git tag

Créer un tag :

git tag -a NomDuTag -m 'MonMessageAssocie'

Partager un tag sur le dépôt:

git push origin NomDuTag

Partager toutes les tags:

git push origin --tags

Merge et rebase:

Voilà le gros morceau, le merge et le rebase sont deux processus de fusion de code. Ces processus sont utilisés lorsque, par exemple, de nouveaux commits sont disponibles sur le dépôt central et que l’on souhaite récupérer ceux ci (le « pull » effectue un « merge »).

La fusion de code pose deux problèmes principaux la gestion de l’historique de Git et la gestion des conflits.

Un conflit survient quand il y a eu une modification de la même partie d’un fichier sur le dépôt centrale et en locale. Git ne peut pas définir seul quelle version prendre. Il créé alors un conflit.

Merge de deux branches :

Le merge est une fusion brute des branches. Les commits sont intégrés en fonction de leur ordre de commit dans l’historique, ce qui peut rendre ce dernier chaotique, mélangeant les commits des fonctionnalités. Cela n’a rien d’alarmant au niveau du code, mais il y a une perte de lisibilité de cet historique.

Pour faire simple, le merge est utile principalement dans le cas suivant :

  • Création d’une branche à partir du master pour développer une fonctionnalité
  • Développement de la fonctionnalité
  • Réintégration avec fast-forward (voir ci dessous) du développement dans le master

Le merge se fait avec les commandes suivantes:

# Aller sur le master
git checkout master
# merger la branche correctif pour intégrer les modifications dans le master
git merge correctif

Notion importante : Le fast forward

Il s’agit là d’une notion floue pour une partie des développeurs utilisant Git. L’utilisation du fast forward (cas par défaut du merge) permet de ne pas laisser de trace du merge dans l’historique de Git. C’est ce que je préconise dans l’exemple que je donne.

Dans le cadre des workflows basés sur plusieurs branches, il est nécessaire de montrer à quel moment ces derniers sont faits pour assurer la traçabilité. Pour cela, il faut désactiver le fast-foward pour ce merge spécifiquement.

# merger la branche correctif avec la traçabilité du merge
git merge --no-ff brancheAMerge

Rebase de deux branches :

Dans la plupart des autres cas pour un développeur lambda, il faut utiliser le rebase. Voici quelques explications.

Pour expliquer ce que fait le rebase rien de vaut un petit schéma.

Illustration rebase
Illustration rebase

Pour faire simple, le rebase déplace le commit d’origine de la branche pour le dernier commit de la branche passé en paramètre (le master dans l’illustration). Les deux commits de vos collègues se retrouvent donc à la fois sur le master et dans la branche. Le rebase importe bien sûr les modifications de code des deux commits, il faudra donc régler les conflits éventuels.

Maintenant, un exemple en ligne de commande

# On créé la branche sur laquel nous allons dev
git checkout -b Branche_de_dev

# Après nos devs, on va cherche les modifications du dépôt
git checkout master
git pull master

# On intègre les modifications du dépôt à la branche avec le rebase
git checkout Branche_de_dev
git rebase master

Le rebase est une commande dont il faut bien comprendre pour être utilisé à bon escient. Voici plusieurs autres sources complémentaires:

Annuler des modifications

Des erreurs arriveront régulièrement au début avec les manipulations de branches. Combien de fois je n’ai pas commité sur la bonne branche, par exemple. La commande reset permet d’annuler les commits en conservant ou non les modifications du fichier.

Annuler le dernier commit en gardant les modifications de ce commit:

git reset md5_commit_précédent

Annuler le dernier commit en supprimant les modifications de ce commit:

git reset --hard md5_commit_précédent

Ce dernier s’utilise moins dans le contexte expliqué au dessus mais est très pratique pour revenir en arrière de manière un peu brutale si l’on se rend compte d’une erreur.

Pour finir

Après avoir vu les bases dans le premier article dédié aux commandes Git, ce second article a expliqué  certaines commandes un peu plus poussées (branche, tag, merge & rebase). Elles permettent à n’importe quel développeur de s’intégrer dans un workflow de développement avec Git au sein d’une équipe de développeurs.

Le prochain et dernier article sur les commandes Git aura comme objet d’autres commandes et configurations de Git. Ces dernières permettront par exemple de trouver l’origine d’un bug (bisect) et de se faciliter la vie avec Git (mergetool, alias …).

Si vous avez des questions sur Git ou pour tous autres messages, n’hésitez pas à profiter des commentaires auxquels je répondrai avec plaisir!

Sources:

Merci Mathieu pour ton retour !


Partager l'article :

Facebooktwitterredditlinkedinmail
 

Vous aussi participez, laissez un commentaire