#gitfr

Git est hautement configurable, avec des dizaines de variables possibles dans le fichier de configuration, la longueur de l'aide de l'option config donnant d'ailleurs quelques vertiges. Au lieu de faire un (très) long billet sur les différentes possibilités de configuration, je vous propose plutôt des billets courts sur un thème particulier de la configuration.

Pour ce premier billet, je souhaite aborder le comportement de Git lors d'un push. Ce qui ont suivis l'atelier Git à Bordeaux ne seront pas étonnés par ce choix : ayant totalement oublié cette option, je ne comprenais pas que ma machine ne se comporte pas comme ceux des participants à l'atelier (ma crédibilité en tant qu'expert Git en a sérieusement pâti :).

Commençons par lire le manuel sur l'option push.default :

Defines the action git push should take if no refspec is given on the command line, no refspec is configured in the remote, and no refspec is implied by any of the options given on the command line. Possible values are:

• nothing - do not push anything.
• matching - push all matching branches. All branches having the same name in both ends are considered to be matching. This is the default.
• upstream - push the current branch to its upstream branch.
• tracking - deprecated synonym for upstream.
• current - push the current branch to a branch of the same name.

Comme vous pouvez le constater, si aucun refspec n'est fourni (en ligne de commande ou par configuration) le comportement par défaut est de pousser toutes les branches qui existent en local et sur le serveur. Cela veut donc dire que si vous tapez la commande git push, vous allez mettre à jour sur le serveur toutes les branches que vous avez modifié en local, ce qui est rarement souhaitable. Il faudra indiquer le refspec complet git push origin mybranch pour éviter cela.

C'est pour cette raison que je configure Git avec l'option upstream :

$ git config --global push.default upstream

2 avantages immédiats :

• Il ne pousse que la branche courante.
• Il m'oblige à faire un tracking, ce qui est bien utile.

Maintenant, si vous tentez de pousser la branche test avec la commande git push sans tracking préalable, Git vous répond :

fatal: The current branch test has no upstream branch. To push the current branch and set the remote as upstream, use

git push --set-upstream origin test

Suivez le conseil de Git en tapant la commande ci dessus pour suivre votre la branche distante test sur origin avec votre branche locale test. Vous verrez immédiatement un changement sur votre shell avec l'information u=, qui indique que vos deux branches sont synchronisées.

Rappel sur le tracking

Le tracking consiste à associer une branche locale et une branche distante (dite upstream dans la terminologie Git), ce qui informe Git de la branche distante à utiliser lors d'un git pull. Si vous ne comprenez pas pourquoi vous n'êtes pas plus souvent confronté à cette notion de tracking, c'est tout simplement que Git le fait pour vous la plupart du temps :

• Git suit la branche master lors d'un clone.
• Git suit la branche que vous venez de créer si celle ci existe déjà sur le serveur

C'est donc (la plupart du temps) dans le cas ou créer une nouvelle branche en locale sans existance préalable sur le serveur que vous devez explicitement faire cette association.

Si vous avez déjà travaillé avec un dépôt distant, vous savez comment se comporte Git : il vous indique les références du dépôt distant en ajoutant l'espace de nom origin (dans le cas d'un clone) ou le nom que vous lui donnez si vous l'avez ajouter avec la commande git-remote add. Mais pourquoi Git a t'il ce comportement ?

La réponse se trouve dans le refspec, nom un peu barbare, qui pourrait se traduire en bon français par : «comment je gère les dépôts distants chef ?». Soit ce refspec est spécifié en ligne de commande au moment de l'action (fetch ou push), soit elle se trouve dans le fichier de configuration du dépôt.

Petit rappel

Il est impossible de modifer directement un dépôt distant, vous devez obligatoirement modifier le dépôt local puis pousser vos commits sur le dépôt distant. Autrement dit, modifier un dépôt consiste à synchroniser les bases de données.

C'est là que le refspec rentre en jeu, il permet de définir les branches concernées au moment de la synchronisation.

Clonage

Si vous joué rarement avec le refspec, c'est que vous travaillé la plupart du temps sur un dépôt local que vous avez créé avec la commande git-clone. Ce dernier génère un refspec générique suffisant. Editez le fichier .git/config et vous verrez ces lignes :

[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = /path/to/repos

Une explication rapide : le dépôt distant qui se trouve à l'url spécifié s'appelle en local origin et on associe à chaque référence de branche du dépôt distant une référence de branche locale préfixée par origin.

Mais un deuxième rappel avant d'aller plus loin.

Structure des références

La gestion des références est d'une simplicité affligeante. Tout est contenu dans le répertoire .git/refs. Un répertoire étant un espace de nom, un fichier une référence. Pour fonctionner, Git à besoin de 2 espaces de nom bien particulier :

• heads pour stocker les références locales de type branche.

• tags pour stocker les références locales de type tag.

Vous ne faites pas attention à ces répertoires en temps normal car les commandes Git savent pertinamment que les références sont à ces endroits précis.

Explication

Si je vous dis qu'un refspec s'écrit toujours source:destination, la ligne suivante ne doit pas vous poser trop de soucis. Examinons la de plus prêt :

fetch = +refs/heads/:refs/remotes/origin/

• Le mot clé fetch indique que c'est lu à chaque utilisation de cette commande Le sens de transfert est du dépôt distant (la source) vers le dépôt local (la destination).

• Le symbole + signifie qu'on autorise les récuparation non fast-forword.

• le reste de la ligne est assez explicite. Pour toutes les références se trouvant dans le chemin refs/heads/ dans le dépôt distant, on associe une référence dans le chemin refs/remotes/origin/ dans le dépot local.

Si par exemple le dépôt distant a 3 branches qui se nomment riri, fifi et loulou, vous aurez donc en local 3 branches origin/riri, origin/fifi et origin/loulou.

Importance du refspec

Il est important de maitriser le refspec car tout part de là, c'est en fonction des références à récupérer ou à pousser que Git détermine les objets à synchroniser. Si je demande à récupérer toutes les références distantes, je demande implicitement tous les objets accessibles par ces références, donc toute la base. Au contraire, si le refspec implique des références précises, seuls les objets nécessaires à ces références seront impactés.

Ajout d'un dépôt distant

La commande git-remote permet de manipuler les dépôts distants, avec notamment la commande git-remote add pour en ajouter. Ce dernier se comporte comme la commande git-clone, en configurant le refspec au plus large (toutes les références donc).

refspec en ligne de commande

Le refspec se manipule aussi en ligne de commande, ce qui permet de passer outre la configuration ou d'utiliser Git sans configuration préalable.

Quelques exemples :

git fetch origin +pu:tmp

Récupére la référence pu et les objets associés et appeles la tmp en local.

git push HEAD:master

Pousse la branche actuelle sur la branche distante master.

git push origin master:refs/heads/qa/experimental

Pousse la branche master sur la branche distante expérimental. Nous utilisons ici le nom complet de la référence.

Le refspec :

Refspec particulier qui indique de mettre à jour toutes les branches distantes existantes qui ont un nom identique aux branches locales. C'est en fait le refspec utilisé par défaut au push quand nous en spécifions pas.

Effacer une référence distante

Autre cas particulier. Si vous souhaitez par exemple effacer la référence distante test si vous souhaitez effacer une référence distante, il faut taper :

git push :test

Autrement dit, je pousse une référence vide sur la référence test.

Associer branche locale / branche distante

Comme nous l'avons vu, le refspec en ligne de commande permet d'associer temporairement une branche locale et une branche sur le dépôt distant. Mais comment associer ces deux branches dans la configuration et éviter ainsi de le répêter à chaque fois ? Tout se situe encore dans le fichier .git/config du dépôt local :

[branch "master"]                                                                                   
remote = origin                                                                             
merge = refs/heads/master

Qui veut dire : associe la branche master du dépôt origin à ma référence locale master. Et oh surprise, la ligne est utilisée pour la commande merge, ce qui est tout à faire logique. la commande git-fetch ne fait que récupérer les objets et associer des références. Si vous voulez mélanger votre travail avec le travail distant, il faut donc faire un merge.

Petite remarque, c'est uniquement quand vous avez spécifiée une branche distante (upstream dans le vocabulaire Git) que votre shell vous indiquera si vous avez des commits en avance ou en retard (logique non ?). Cela arrive quand vous avez créé une nouvelle branche locale mais sans l'avoir poussée sur le dépôt distant.

pull = fetch + merge

Vous devez maintenant comprendre pourquoi on dit que la commande git-pull n'est en fait qu'un raccouri pour :

1. git-fetch
2. git-merge origin/master

A quoi sert le fetch ?

La commande git-pull est une commodité car c'est dans 90% des cas ce que l'on souhaite faire. Mais le merge est seulement une des nombreuses possibilités que vous offre Git. La beauté du travail collaboratif avec Git est que cette branche distante est en fait une branche locale (c'est uniquement la référence qui est distante), et que vous pouvez donc faire ce que vous souhaitez avec, comme cherrypicker des commits, faire un rebase... ou un merge. C'est à vous de voir ce qui vous intéresse. C'est la raison pour laquelle des personnes disent sur le Net de ne pas faire que des fetch.

Notez qu'il existe l'option --rebase pour rebaser automatiquement votre branche locale sur la branche distante (ce qui est la aussi un scénario de base).

Conclusion

Je pense avoir fait le tour. Comme d'habitude je vous conseille de de lire les pages du manuel (git-clone, git-fetch, git-push et git-pull).