Comprendre les étapes (pull = fetch + merge @{u})

Je commence par te montrer le cas nominal du pull en mode merge. Ne t’inquiète pas pour la syntaxe du titre, je l’ai mise là à titre informatif avec ce @{u} qui est une syntaxe de révision désignant l’upstream, ou en français la branche distante depuis laquelle on récupère les mises à jour. Tu n’auras pas à taper ce genre de commande, git pull le fera implicitement pour toi.

J’ai là l’historique de ma branche master. On voit une autre étiquette de branche nommée origin/master et qui est en c2, donc deux commits en arrière de master. Cette branche fait partie du procédé de Git pour gérer mes synchronisations entre ma branche locale et sa jumelle distante. Git crée une branche localement qu’il nomme « <le nom du dépôt distant>/<nom de la branche> ». La plupart du temps on a « origin » comme nom de dépôt distant et comme nom de branche le même que pour notre branche locale. Donc ici j’ai origin/master.

Bon là j’ai pris un gros raccourci. Garde juste à l’esprit que toutes les mises à jour récupérées du dépôt distant pour ma branche seront retranscrites sur une branche localement. D’ailleurs cette branche qui piste le dépôt distant n’est visible qu’avec un git log --all

Si je reprends mon historique je peux en conclure que ma branche master a évolué localement par rapport à la dernière version connue de son équivalent distant. En d’autres termes, je n’ai pas encore pushé mes commits c3 et c4

Admettons maintenant qu’un des mes collègues ait réalisé 2 commits de son côté et que je les récupère avec un git pull, voici ce que ça va donner : l’opération de fetch va faire évoluer ma branche origin/master en récupérant les commits oc1 et oc2 de mon collègue. Je vais alors avoir une divergence entre origin/master et master. Puis la seconde opération, le merge, va venir intégrer ces nouveautés dans master en réalisant une fusion.

Le résultat est alors qu’on a une bosse et un commit de fusion pour retranscrire la mise à jour avec le distant. Je te montre après avec ma démo dans le terminal ce que ça donne quand on a plusieurs synchronisations et surtout la tête que va avoir notre historique.

Bien utiliser Git merge vs rebase

Produire un historique cohérent et utile nécessite de savoir aussi bien nettoyer notre travail que fusionner des branches. Les commandes rebase et merge se complètent parfaitement quand on sait bien les utiliser…