Le <src> est souvent le nom de la branche que vous voudriez pousser, mais il peut s’agir de n’importe quelle "expression SHA-1" arbitraire, comme master ~ 4 ou HEAD (voir gitrevisions[7]) .

Le <dst> indique quelle référence du côté distant est mise à jour avec cette poussée. Des expressions arbitraires ne peuvent pas être utilisées ici, une référence réelle doit être nommée. Si git push [<dépôt>] sans aucun argument <spéc-de-réf> est défini pour mettre à jour une référence à la destination avec <src> avec la variable de configuration remote. <dépôt> .push, la partie  :<dst > ` peut être omise - une telle poussée mettra à jour une référence que <src> met normalement à jour sans aucun <spéc-de-réf> sur la ligne de commande. Sinon, un ` :<dst> manquant signifie mettre à jour la même référence que le <src>.

Si <dst> ne commence pas par refs/ (par exemple refs/heads/master), nous essaierons de déduire où dans refs/* sur le <dépôt> de destination il appartient en fonction du type de <src> poussé et si <dst> est ambigu.

L’objet référencé par <src> est utilisé pour mettre à jour la référence <dst> du côté distant. Le fait que cela soit autorisé dépend de l’endroit où vit la référence <dst> dans refs/* comme décrit en détail ci-dessous. Dans ces sections, "mise à jour" signifie tout type de modification sauf les suppressions, qui, comme indiqué après les quelques sections suivantes, sont traités différemment.

L’espace de noms refs/heads/* n’acceptera que les objets commit, et les mises à jour uniquement si elles peuvent être en avance rapide.

L’espace de noms refs/tags/* acceptera tout type d’objet (car les commits, les arbres et les blobs peuvent être étiquetés), et toute mise à jour de ceux-ci sera rejetée.

Il est possible de pousser n’importe quel type d’objet vers n’importe quel espace de noms en dehors de refs/{tags,heads}/*. Dans le cas des tags et des commit, ceux-ci seront traités comme s’ils étaient des commits à l’intérieur de refs/heads/* afin de déterminer si la mise à jour est autorisée.

C’est-à-dire qu’une avance rapide des commits et des étiquettes en dehors de refs/{tags,heads}/* est autorisée, même dans les cas où ce qui est avancé rapidement n’est pas un commit, mais un objet étiquette qui pointe vers un nouveau commit qui est une avance rapide de la dernière étiquette (ou commit) qu’il remplace. Le remplacement d’une étiquette par une étiquette entièrement différente est également autorisé, si elle pointe vers le même commit, ainsi que le fait de pousser une étiquette pelée, c’est-à-dire de pousser le commit vers lequel l’objet étiquette existant pointe, ou un nouvel objet étiquette vers lequel un commit existant pointe.

Les objets d’arbre et de blob à l’extérieur de refs/{tags,heads}/* seront traités de la même manière que s’ils étaient à l’intérieur de refs/tags/*, toute mise à jour de ceux-ci sera rejetée.

Toutes les règles décrites ci-dessus sur ce qui n’est pas autorisé en tant que mise à jour peuvent être passées outre en ajoutant le caractère facultatif + à une spéc-de-réf (ou en utilisant l’option de ligne de commande --force). La seule exception à cela est qu’aucune quantité de forçage ne fera que l’espace de noms refs/heads/* acceptera un objet non-commit. Les crochets et la configuration peuvent également remplacer ou modifier ces règles, voir par ex. receive.denyNonFastForwards dans git-config[1] et pre-receive et update dans githooks[5].

Pousser un <src> vide vous permet de supprimer la référence <dst> du dépôt distant. Les suppressions sont toujours acceptées sans signe + dans la spéc-de-réf (ou --force), sauf lorsque la configuration ou les crochets l’interdisent. Voir receive.denyDeletes dans git-config[1] et pre-receive et update dans githooks[5].

La spéc-de-réf spéciale : (ou +: pour permettre des mises à jour pas en avance rapide) ordonne à Git de pousser les branches "correspondantes" : pour chaque branche qui existe du côté local, le côté distant est mis à jour si une branche du même nom existe déjà du côté distant.

tag <étiquette> signifie la même chose que refs/tags/<étiquette>:refs/tags/<étiquette>.

Cette option passe outre cette restriction si la valeur actuelle de la référence distante est la valeur attendue. "git push" échoue sinon.

Imaginez que vous devez rebaser ce que vous avez déjà publié. Vous devrez contourner la règle "doit avancer rapidement" afin de remplacer l’historique que vous avez initialement publié par l’historique rebasé. Si quelqu’un d’autre a construit sur votre historique d’origine pendant que vous rebasez, le sommet de la branche distante peut avoir avancé avec son commit, et pousser aveuglément avec --force éliminera son travail.

Cette option vous permet de dire que vous vous attendez à ce que l’historique que vous mettez à jour est ce que vous avez rebasé et que vous souhaitez remplacer. Si la référence distante pointe toujours sur le commit que vous avez spécifié, vous pouvez être sûr qu’aucune autre personne n’a fait quoi que ce soit à la référence. C’est comme prendre un "contrat" sur la référence sans la verrouiller explicitement, et la référence distante n’est mise à jour que si le "contrat" est toujours valide.

Seul --force-with-lease, sans préciser les détails, protégera toutes les références distantes qui vont être mises à jour en exigeant leur valeur actuelle à être la même que la branche de suivi à distance que nous avons pour eux.

--force-with-lease=<nom-de-réf>, sans spécifier la valeur attendue, protégera (seulement) la référence nommée, si elle va être mise à jour, en exigeant que sa valeur actuelle soit la même que la branche de suivi à distance que nous avons pour elle.

--force-with-lease=<nom-de-réf>:<attendu> protégera (seulement) la référence nommée, si elle va être mise à jour, en exigeant que sa valeur actuelle soit la même que la valeur spécifiée <attendu > `(qui peut être différente de la branche de suivi à distance que nous avons pour le nom de référence, ou si nous n'avons même pas besoin d'avoir une telle branche de suivi à distance lorsque cette forme est utilisée). Si `<attendu> est la chaîne vide, alors la référence nommée ne doit pas déjà exister.

Notez que toutes les formes autres que --force-with-lease=<nom-de-réf>:<attendu> qui spécifie explicitement la valeur actuelle attendue de la référence sont toujours expérimentales et leur sémantique peut changer à mesure que nous acquérons de l’expérience avec cette fonctionnalité.

"--no-force-with-lease" annulera tous les précédents --force-with-lease sur la ligne de commande.

Une note générale sur la sécurité : fournir cette option sans valeur attendue, c’est-à-dire que --force-with-lease ou --force-with-lease=<nom-de-réf> interagit très mal avec tout ce qui exécute implicitement git fetch sur le distant pour être poussé en arrière-plan, par exemple git fetch origin sur votre dépôt dans un job cron.

La protection qu’il offre par rapport à --force est d’assurer que les modifications ultérieures sur lesquelles votre travail n’était pas basé ne sont pas supprimées, mais elle est trivialement réduite à néant si un processus de mise à jour des références est effectué en arrière-plan. Nous n’avons rien d’autre que les informations de suivi à distance à utiliser comme heuristique pour les références que vous êtes censé avoir vues et que vous êtes prêt à supprimer.

Si votre éditeur ou un autre système exécute git fetch en arrière-plan pour vous, un moyen d’atténuer cela est simplement de configurer un autre distant :

Maintenant, lorsque le processus d’arrière-plan exécute git fetch origin, les références sur` origin-push` ne seront pas mises à jour, et donc des commandes comme :

Échouera à moins que vous ne lanciez manuellement git fetch origin-push. Cette méthode est bien sûr entièrement contrecarrée par quelque chose qui lance git fetch --all, auquel cas vous devrez soit la désactiver soit faire quelque chose de plus fastidieux comme :

C’est-à-dire créer une étiquette base pour les versions du code amont que vous avez vues et que vous êtes prêt à écraser, puis réécrire l’historique, et enfin forcer la poussée des modification vers master si la version distante est toujours à base, indépendamment de ce que votre remotes/origin/master local a été mis à jour en arrière-plan.

Alternativement, spécifier --force-if-includes comme une option auxiliaire avec --force-with-lease[=<nom-de-réf>] (c’est-à-dire sans dire vers quel commit exact la réf du côté distant doit pointer, ou quelles réfs du côté distant sont protégées) au moment de "push" vérifiera si les mises à jour des réfs du côté distant qui peuvent avoir été implicitement mises à jour en arrière-plan sont intégrées localement avant d’autoriser une mise à jour forcée.

Ce drapeau désactive ces contrôles et peut entraîner la perte de commits du dépôt distant ; utilisez-le avec précaution.

Notez que --force s’applique à toutes les refs qui sont poussées, donc l’utiliser avec push.default réglé sur matching ou avec plusieurs destinations de poussée configurées avec remote.*.push peut écraser les refs autres que la branche courante (y compris les refs locales qui sont strictement derrière leur homologue distante). Pour forcer un push vers une seule branche, utilisez un " + " devant le spécificateur de référence à pousser (par exemple git push origin +master pour forcer une poussée vers la branche master). Voir la section <spéc-de -réf>... ci-dessus pour plus de détails.

Cette option permet de vérifier si le sommet de la référence de suivi à distance est accessible depuis l’une des entrées "reflog" de la branche locale qui est basée dessus pour une réécriture. Cette vérification permet de s’assurer que toutes les mises à jour du distant ont été incorporées localement en rejetant la mise à jour forcée si ce n’est pas le cas.

Si l’option est passée sans spécifier --force-with-lease, ou spécifiée avec --force-with-lease=<nom-de-réf>:<attendu>, c’est un "no-op".

Spécifier --no-force-if-includes désactive ce comportement.

Lors de l’utilisation de on-demand ou only, si un sous-module possède une configuration "push.recurseSubmodules={on-demand,only}" ou "submodule.recurse", une récursion supplémentaire se produira. Dans ce cas, "only" est traité comme "on-demand".

En cas d’échec de la mise à jour, de plus amples détails sont donnés :

Le comportement par défaut de cette commande quand aucun <spec-de-réf> n’est donné peut être configuré en définissant l’option push du distant, ou la variable de configuration push.default.

Par exemple, pour pousser par défaut uniquement la branche actelle vers origin, utilisez git config remote.origin.push HEAD. Tout <spec-de-réf> valide (comme ceux des exemples ci-dessous) peut être configuré par défaut pour git push origin.

Voir la section décrivant <spéc-de-réf>... ci-dessus pour une discussion sur la sémantique de correspondance.

Il s’agit d’émuler git fetch exécuté sur le vaisseaumère en utilisant git push qui est exécuté dans la direction opposée afin d’intégrer le travail effectué sur satellite, et est souvent nécessaire lorsque vous ne pouvez établir la connexion que dans un seul sens (c’est-à-dire que le satellite peut ssh dans vaisseaumère mais que le vaisseaumère ne peut pas établir de connexion avec satellite parce que ce dernier se trouve derrière un pare-feu ou n’exécute pas sshd).

Après avoir lancé ce git push sur la machine satellite, vous ouvririez un ssh sur le vaisseaumère et y lanceriez git merge pour compléter l’émulation de git pull qui était lancée sur vaisseaumère afin de tirer les modifications faites sur satellite.

La commande ci-dessus changerait le dépôt origin en

Les commits A et B n’appartiendraient plus à une branche portant un nom symbolique, et seraient donc injoignables. Dans cet état, ces commits seraient supprimés par une commande git gc sur le dépôt origin.