git-push - En ligne dans le Cloud

PROGRAMME:

Nom

git-push - Mettre à jour les références distantes avec les objets associés

SYNOPSIS

jet pousser [--tout | --miroir | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack= ]
[--repo= ] [-f | --force] [--prune] [-v | --verbeux]
[-u | --set-amont]
[--[no-]signed|--sign=(true|false|if-demandé)]
[--force-avec-bail[= [: ]]]
[--pas-vérifier] [ [ ...]]

DESCRIPTION

Met à jour les références distantes à l'aide des références locales, tout en envoyant les objets nécessaires pour terminer le
références données.

Vous pouvez faire en sorte que des choses intéressantes se produisent dans un référentiel chaque fois que vous y accédez, en
mise en place d' crochets là. Voir la documentation pour git-recevoir-pack (1).

Lorsque la ligne de commande ne spécifie pas où pousser avec le argument,
branch.*.remote la configuration de la branche actuelle est consultée pour déterminer où
pousser. Si la configuration est manquante, elle est par défaut origine.

Lorsque la ligne de commande ne spécifie pas avec quoi pousser ... arguments ou --all,
--mirror, --tags options, la commande trouve la valeur par défaut en consultant
remote.*.push configuration, et s'il n'est pas trouvé, honore la configuration push.default pour
décider quoi pousser (Voir git-config(1) pour la signification de push.default).

Lorsque ni la ligne de commande ni la configuration ne spécifient ce qu'il faut pousser, la valeur par défaut
est utilisé, ce qui correspond à la valeur simple de push.default : le
branche est poussée vers la branche amont correspondante, mais par mesure de sécurité, la poussée
est abandonné si la branche amont n'a pas le même nom que la branche locale.

OPTIONS

Le référentiel "distant" qui est la destination d'une opération push. Ce paramètre peut être
soit une URL (voir la section URL GIT ci-dessous) soit le nom d'une télécommande (voir la section
TÉLÉCOMMANDES ci-dessous).

...
Spécifiez quelle référence de destination mettre à jour avec quel objet source. Le format d'un
le paramètre est un plus + facultatif, suivi de l'objet source ,
suivi de deux points :, suivi de la référence de destination .

Les est souvent le nom de la branche que vous voudriez pousser, mais cela peut être n'importe quel
"expression SHA-1" arbitraire, telle que master~4 ou HEAD (voir gitrévisions(7)).

Les indique quelle référence du côté distant est mise à jour avec cette poussée. Arbitraire
les expressions ne peuvent pas être utilisées ici, une référence réelle doit être nommée. Si git push
[ ] sans aucun l'argument est défini pour mettre à jour une référence au
destination avec avec télécommande. variable de configuration .push, :
partie peut être omise - une telle poussée mettra à jour une référence qui normalement mis à jour sans
tout sur la ligne de commande. Sinon, manque : signifie mettre à jour le même
réf comme le .

L'objet référencé par est utilisé pour mettre à jour le référence sur la télécommande
côté. Par défaut, cela n'est autorisé que si n'est pas une balise (annotée ou
léger), et seulement s'il peut avancer rapidement . En ayant l'option
menant +, vous pouvez dire à Git de mettre à jour le ref même si cela n'est pas autorisé par
par défaut (par exemple, ce n'est pas une avance rapide.) pas tenter de fusionner dans
. Voir les EXEMPLES ci-dessous pour plus de détails.

étiqueter signifie la même chose que refs/tags/ :refs/balises/ .

Pousser un vide permet de supprimer le ref du référentiel distant.

La refspec spéciale : (ou + : pour autoriser les mises à jour non rapides) ordonne à Git de pousser
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.

--tout
Poussez toutes les branches (c'est-à-dire refs sous refs/heads/); ne peut pas être utilisé avec d'autres .

--prune
Supprimez les branches distantes qui n'ont pas d'équivalent local. Par exemple une télécommande
la branche tmp sera supprimée si une branche locale du même nom n'existe pas
Suite. Cela respecte également les refspecs, par exemple git push --prune remote
refs/heads/*:refs/tmp/* s'assurerait que les refs/tmp/foo distants seront supprimés si
refs/heads/foo n'existe pas.

--miroiter
Au lieu de nommer chaque ref à pousser, spécifie que toutes les refs sous refs/ (qui
inclut, mais sans s'y limiter, refs/heads/, refs/remotes/ et refs/tags/) être mis en miroir
vers le référentiel distant. Les références locales nouvellement créées seront poussées vers l'extrémité distante,
les références mises à jour localement seront mises à jour de force sur l'extrémité distante, et les références supprimées seront
retiré de l'extrémité distante. C'est la valeur par défaut si l'option de configuration
à distance. .mirror est défini.

-n, --exécution à sec
Faites tout sauf envoyer les mises à jour.

--porcelaine
Produisez une sortie lisible par machine. La ligne d'état de sortie pour chaque référence sera
séparé par des tabulations et envoyé à stdout au lieu de stderr. Les noms symboliques complets des
les références seront données.

--effacer
Toutes les références répertoriées sont supprimées du référentiel distant. C'est la même chose que le préfixe
toutes les références avec un deux-points.

--Mots clés
Toutes les références sous refs/tags sont poussées, en plus des refspecs explicitement répertoriées sur le
ligne de commande.

--follow-tags
Push toutes les références qui seraient poussées sans cette option, et aussi push annotées
balises dans les références/balises qui manquent à la télécommande mais pointent vers commit-ish qui
sont accessibles depuis les arbitres poussés. Ceci peut également être spécifié avec
variable de configuration push.followTags. Pour plus d'informations, voir push.followTags in
git-config (1).

--[no-]signé, --sign=(true|false|si demandé)
GPG-signer la demande push pour mettre à jour les références du côté de la réception, pour lui permettre d'être
vérifié par les crochets et/ou être enregistré. Si false ou --no-signed, aucune signature ne sera
tenté. Si true ou --signed, le push échouera si le serveur ne prend pas en charge
poussées signées. Si défini sur si demandé, signez si et seulement si le serveur prend en charge signé
pousse. Le push échouera également si l'appel réel à gpg --sign échoue. Voir git-
recevoir-pack(1) pour les détails sur l'extrémité de réception.

--[no-]atomique
Utilisez une transaction atomique sur le côté distant si disponible. Soit toutes les références sont
mis à jour, ou en cas d'erreur, aucune référence n'est mise à jour. Si le serveur ne prend pas en charge atomic
pousse la poussée échouera.

--receive-pack= , --exec=
Chemin vers le git-recevoir-pack programme à l'extrémité distante. Parfois utile pour pousser
vers un référentiel distant via ssh, et vous n'avez pas le programme dans un répertoire sur le
par défaut $CHEMIN.

--[no-]force-with-lease, --force-with-lease= ,
--force-with-lease= :
Habituellement, "git push" refuse de mettre à jour une référence distante qui n'est pas un ancêtre du
ref local utilisé pour l'écraser.

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

Imaginez que vous deviez rebaser ce que vous avez déjà publié. Tu vas devoir
contourner la règle "doit avancer rapidement" afin de remplacer l'historique que vous avez initialement
publié avec l'historique rebasé. Si quelqu'un d'autre a construit sur votre original
historique pendant que vous rebasez, la pointe de la branche au niveau de la télécommande peut avancer avec
son engagement, et pousser aveuglément avec --force perdra son travail.

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

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

--force-with-lease= , sans spécifier la valeur attendue, protégera le
nommé ref (seul), s'il doit être mis à jour, en exigeant que sa valeur actuelle soit
le même que la branche de suivi à distance que nous avons pour cela.

--force-with-lease= : protégera la référence nommée (seule), si elle est
va être mis à jour, en exigeant que sa valeur actuelle soit la même que celle spécifiée
valeur (qui peut être différent de la branche de suivi à distance que nous
avoir pour le refname, ou nous n'avons même pas besoin d'avoir une telle branche de suivi à distance
lorsque ce formulaire est utilisé).

Notez que toutes les formes autres que --force-with-lease= : qui précise
la valeur actuelle attendue de la ref est explicitement encore expérimentale et leur
la 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 commande
ligne.

-f, --force
Habituellement, la commande refuse de mettre à jour une référence distante qui n'est pas un ancêtre du
ref local utilisé pour l'écraser. De plus, lorsque l'option --force-with-lease est utilisée, le
la commande refuse de mettre à jour une référence distante dont la valeur actuelle ne correspond pas à ce qui est
attendu.

Cet indicateur désactive ces vérifications et peut entraîner la perte des commits par le référentiel distant ;
l'utiliser avec précaution.

Notez que --force s'applique à toutes les références qui sont poussées, donc en l'utilisant avec
push.default défini sur correspondant ou avec plusieurs destinations push configurées avec
remote.*.push peut écraser les références autres que la branche actuelle (y compris les références locales
qui sont strictement derrière leur homologue éloigné). Pour forcer un push à un seul
branche, utilisez un + devant la refspec pour pousser (par exemple git push origin +master pour forcer
un push vers la branche master). Voir le ... section ci-dessus pour plus de détails.

--repo=
Cette option est équivalente à la argument. Si les deux sont spécifiés, le
l'argument de ligne de commande est prioritaire.

-u, --set-amont
Pour chaque branche qui est à jour ou poussée avec succès, ajoutez en amont (suivi)
référence, utilisé par sans argument git-pull(1) et d'autres commandes. Pour plus d'informations,
sur le lien branche. .fusionner in git-config (1).

--[non-]mince
Ces options sont transmises à git-send-pack(1). Un transfert fin réduit considérablement
la quantité de données envoyées lorsque l'expéditeur et le destinataire partagent plusieurs des mêmes objets dans
commun. La valeur par défaut est --thin.

-q, --calme
Supprimez toutes les sorties, y compris la liste des références mises à jour, sauf si une erreur se produit.
La progression n'est pas signalée au flux d'erreurs standard.

-v, --verbeux
Exécutez verbeux.

--le progrès
L'état d'avancement est signalé par défaut sur le flux d'erreurs standard lorsqu'il est
attaché à un terminal, sauf si -q est spécifié. Ce drapeau force le statut de progression même
si le flux d'erreur standard n'est pas dirigé vers un terminal.

--no-recurse-submodules, --recurse-submodules=check|on-demand|no
Peut être utilisé pour s'assurer que tous les commits de sous-modules utilisés par les révisions à pousser sont
disponible sur une succursale de suivi à distance. Si choisissez est utilisé Git vérifiera que tous
les commits de sous-module qui ont changé dans les révisions à pousser sont disponibles sur au moins
une télécommande du sous-module. Si des commits manquent, le push sera abandonné et
sortie avec un statut différent de zéro. Si à la demande est utilisé tous les sous-modules qui ont changé dans le
les révisions à pousser seront poussées. Si à la demande n'était pas en mesure de pousser tout le nécessaire
révisions, il sera également abandonné et se terminera avec un statut différent de zéro. Une valeur de aucune or
en utilisant --no-recurse-submodules peut être utilisé pour remplacer les push.recurseSubmodules
variable de configuration lorsqu'aucune récursivité de sous-module n'est requise.

--[non-]vérifier
Basculez le crochet de pré-poussée (voir crochets(5)). La valeur par défaut est --verify, donnant au hook un
chance d'empêcher la poussée. Avec --no-verify, le hook est complètement contourné.

GIT URL

En général, les URL contiennent des informations sur le protocole de transport, l'adresse du
serveur distant et le chemin d'accès au référentiel. Selon le protocole de transport, certains
de ces informations peuvent être absentes.

Git prend en charge les protocoles ssh, git, http et https (de plus, ftp et ftps peuvent être utilisés
pour l'extraction et rsync peuvent être utilisés pour l'extraction et le push, mais ceux-ci sont inefficaces et
obsolète ; ne les utilisez pas).

Le transport natif (c'est-à-dire l'URL git://) n'effectue aucune authentification et doit être utilisé avec
prudence sur les réseaux non sécurisés.

Les syntaxes suivantes peuvent être utilisées avec :

· ssh://[user@]host.xz[:port]/path/to/repo.git/

· git://host.xz[:port]/path/to/repo.git/

· http[s]://host.xz[:port]/path/to/repo.git/

· ftp[s]://host.xz[:port]/chemin/vers/repo.git/

· rsync://host.xz/path/to/repo.git/

Une syntaxe alternative de type scp peut également être utilisée avec le protocole ssh :

· [utilisateur@]host.xz:chemin/vers/repo.git/

Cette syntaxe n'est reconnue que s'il n'y a pas de barres obliques avant le premier deux-points. CA aide
différencier un chemin local qui contient un deux-points. Par exemple, le chemin local foo:bar pourrait
être spécifié comme un chemin absolu ou ./foo:bar pour éviter d'être mal interprété comme une URL ssh.

Les protocoles ssh et git prennent également en charge l'extension ~username :

· ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/

· git://host.xz[:port]/~[user]/path/to/repo.git/

· [utilisateur@]host.xz :/~[utilisateur]/chemin/vers/repo.git/

Pour les référentiels locaux, également pris en charge par Git nativement, les syntaxes suivantes peuvent être
utilisé:

· /chemin/vers/repo.git/

· file:///chemin/vers/repo.git/

Ces deux syntaxes sont pour la plupart équivalentes, sauf lors du clonage, où la première implique
--option locale. Voir git-clone(1) pour plus de détails.

Lorsque Git ne sait pas comment gérer un certain protocole de transport, il essaie d'utiliser le
à distance- assistant à distance, s'il existe. Pour demander explicitement un assistant à distance,
la syntaxe suivante peut être utilisée :

· ::

où peut être un chemin, un serveur et un chemin, ou une chaîne arbitraire de type URL
reconnu par l'assistant à distance spécifique invoqué. Voir aides-gitremote(1) pour
détails.

S'il existe un grand nombre de référentiels distants portant le même nom et que vous souhaitez utiliser un
format différent pour eux (de sorte que les URL que vous utilisez seront réécrites en URL qui
travail), vous pouvez créer une section de configuration du formulaire :

[url " "]
au lieu de =

Par exemple, avec ceci :

[url "git://git.host.xz/"]
placeOf = host.xz:/chemin/vers/
au lieu de = travail :

une URL comme "work:repo.git" ou comme "host.xz:/path/to/repo.git" sera réécrite dans n'importe quel
contexte qui prend une URL pour être "git://git.host.xz/repo.git".

Si vous souhaitez réécrire les URL pour le push uniquement, vous pouvez créer une section de configuration du
forme:

[url " "]
pushInsteadOf =

Par exemple, avec ceci :

[url "ssh://example.org/"]
pushInsteadOf = git://example.org/

une URL comme "git://example.org/path/to/repo.git" sera réécrite vers
"ssh://example.org/path/to/repo.git" pour les push, mais les pulls utiliseront toujours l'original
URL.

À distance

Le nom de l'un des éléments suivants peut être utilisé à la place d'une URL comme argument:

· une télécommande dans le fichier de configuration Git : $GIT_DIR/config,

· un fichier dans le répertoire $GIT_DIR/remotes, ou

· un fichier dans le répertoire $GIT_DIR/branches.

Tous ces éléments vous permettent également d'omettre la refspec de la ligne de commande car chacun
contiennent une refspec que git utilisera par défaut.

Nommé éloigné in paramétrage filet
Vous pouvez choisir de fournir le nom d'une télécommande que vous aviez précédemment configurée à l'aide
git-distant(1), git-config(1) ou même par une édition manuelle du fichier $GIT_DIR/config. L'URL
de cette télécommande sera utilisé pour accéder au référentiel. La refspec de cette télécommande sera
utilisé par défaut lorsque vous ne fournissez pas de refspec sur la ligne de commande. L'entrée dans le
le fichier de configuration ressemblerait à ceci :

[à distance " "]
URL =
pushurl =
pousser =
chercher =

Les est utilisé uniquement pour les poussées. Il est facultatif et par défaut .

Nommé filet in $GIT_DIR/télécommandes
Vous pouvez choisir de fournir le nom d'un fichier dans $GIT_DIR/remotes. L'URL dans ce fichier
sera utilisé pour accéder au référentiel. La refspec dans ce fichier sera utilisée par défaut
lorsque vous ne fournissez pas de refspec sur la ligne de commande. Ce fichier doit avoir les éléments suivants
Format:

URL : l'un des formats d'URL ci-dessus
Pousser:
Tirer:

Push : les lignes sont utilisées par jet pousser et Pull : les lignes sont utilisées par jet tirer et jet rapporter.
Plusieurs lignes Push : et Pull : peuvent être spécifiées pour des mappages de branches supplémentaires.

Nommé filet in $GIT_DIR/succursales
Vous pouvez choisir de fournir le nom d'un fichier dans $GIT_DIR/branches. L'URL dans ce fichier
sera utilisé pour accéder au référentiel. Ce fichier doit avoir le format suivant :

#

est requis; # est facultatif.

En fonction de l'opération, git utilisera l'une des refspecs suivantes, si vous ne le faites pas
fournissez-en un sur la ligne de commande. est le nom de ce fichier dans $GIT_DIR/branches
et par défaut, maître.

git fetch utilise :

refs/chefs/ :refs/têtes/

git push utilise :

HEAD:refs/heads/

SORTIE

La sortie de « git push » dépend de la méthode de transport utilisée ; cette section décrit les
sortie lors de la poussée sur le protocole Git (soit localement, soit via ssh).

L'état du push est affiché sous forme de tableau, chaque ligne représentant l'état
d'une seule réf. Chaque ligne est de la forme :

-> ( )

Si --porcelain est utilisé, alors chaque ligne de la sortie est de la forme :

\t : \t ( )

L'état des références à jour n'est affiché que si l'option --porcelain ou --verbose est utilisée.

drapeau
Un seul caractère indiquant le statut de la réf :

(espace)
pour une avance rapide réussie ;

+
pour une mise à jour forcée réussie ;

-
pour une référence supprimée avec succès ;

*
pour une nouvelle référence poussée avec succès ;

!
pour une arbitre qui a été rejetée ou n'a pas réussi à pousser ; et

=
pour une référence qui était à jour et n'avait pas besoin de pousser.

Sommaire
Pour une référence poussée avec succès, le résumé affiche les anciennes et nouvelles valeurs de la référence dans
une forme appropriée à utiliser comme argument pour git log (c'est .. dans la plupart
cas, et ... pour les mises à jour forcées sans avance rapide).

Pour une mise à jour échouée, plus de détails sont donnés :

rejeté
Git n'a pas du tout essayé d'envoyer la référence, généralement parce qu'il ne s'agit pas d'une avance rapide
et vous n'avez pas forcé la mise à jour.

télécommande rejetée
L'extrémité distante a refusé la mise à jour. Habituellement causé par un crochet du côté distant, ou
car le référentiel distant a l'une des options de sécurité suivantes en vigueur :
receive.denyCurrentBranch (pour les push vers la branche extraite),
receive.denyNonFastForwards (pour les mises à jour forcées sans avance rapide),
receive.denyDeletes ou receive.denyDeleteCurrent. Voir git-config (1).

panne à distance
L'extrémité distante n'a pas signalé la mise à jour réussie de la référence, peut-être à cause de
une erreur temporaire du côté distant, une interruption de la connexion réseau ou autre
erreur transitoire.

A partir de
Le nom de la référence locale poussée, moins ses références/ / préfixe. Dans le cas d
suppression, le nom de la référence locale est omis.

à
Le nom de la référence distante en cours de mise à jour, moins ses références/ / préfixe.

raison
Une explication lisible par l'homme. Dans le cas de références poussées avec succès, aucune explication
est nécessaire. Pour une ref échouée, la raison de l'échec est décrite.

REMARQUE À PROPOS AVANCES RAPIDE

Lorsqu'une mise à jour modifie une branche (ou plus généralement une référence) qui pointait sur le commit A
pour pointer vers un autre commit B, cela s'appelle une mise à jour rapide si et seulement si B est un
descendant d'A.

Dans une mise à jour rapide de A à B, l'ensemble de commits que le commit d'origine A a construit
au-dessus se trouve un sous-ensemble des commits sur lesquels le nouveau commit B s'appuie. Par conséquent, il ne
perdre toute histoire.

En revanche, une mise à jour non rapide perdra l'historique. Par exemple, supposons que vous et
quelqu'un d'autre a commencé au même commit X, et vous avez construit un historique menant au commit B
tandis que l'autre personne a construit un historique menant au commit A. L'historique ressemble à ceci :

B
/
----X---A

Supposons en outre que l'autre personne a déjà poussé les changements menant à A vers le
référentiel d'origine à partir duquel vous avez obtenu le commit X d'origine.

Le push effectué par l'autre personne a mis à jour la branche qui pointait sur commit X vers
pointez sur commit A. C'est une avance rapide.

Mais si vous essayez de pousser, vous tenterez de mettre à jour la branche (qui pointe maintenant vers A) avec
commettre B. Cela fait pas avance rapide. Si vous l'avez fait, les changements introduits par le commit A
sera perdu, car tout le monde va maintenant commencer à construire sur B.

La commande par défaut ne permet pas une mise à jour qui n'est pas une avance rapide pour empêcher de tels
perte de l'histoire.

Si vous ne voulez pas perdre votre travail (historique de X à B) ou le travail de l'autre personne
(historique de X à A), vous devez d'abord récupérer l'historique du référentiel,
créer un historique contenant les modifications apportées par les deux parties et repousser le résultat.

Vous pouvez effectuer "git pull", résoudre les conflits potentiels et "git push" le résultat. Un " idiot
pull" créera un commit de fusion C entre les commits A et B.

AVANT JC
/ /
----X---A

La mise à jour de A avec le commit de fusion résultant accélérera et votre push sera
accepté.

Alternativement, vous pouvez rebaser votre changement entre X et B au-dessus de A, avec "git pull
--rebase", et repousser le résultat. Le rebase créera un nouveau commit D qui construira le
changer entre X et B au-dessus de A.

BD
/ /
----X---A

Encore une fois, la mise à jour de A avec ce commit avancera rapidement et votre push sera accepté.

Il existe une autre situation courante dans laquelle vous pouvez rencontrer un rejet non accéléré lorsque
vous essayez de pousser, et c'est possible même lorsque vous poussez dans un référentiel personne
d'autre pousse dans. Après avoir poussé le commit A vous-même (dans la première image de cette section),
remplacez-le par "git commit --amend" pour produire le commit B, et vous essayez de le pousser,
parce que vous avez oublié que vous avez déjà repoussé A. Dans un tel cas, et seulement si vous êtes
certain que personne entre-temps n'a récupéré votre commit A précédent (et a commencé à construire sur
dessus), vous pouvez exécuter "git push --force" pour l'écraser. En d'autres termes, "git push
--force" est une méthode réservée aux cas où vous voulez vraiment perdre l'historique.

EXEMPLES

git push
Fonctionne comme git push , où est la télécommande de la branche actuelle (ou
origin, si aucune télécommande n'est configurée pour la branche courante).

git push origine
Sans configuration supplémentaire, pousse la branche courante vers l'amont configuré
(variable de configuration remote.origin.merge) si elle porte le même nom que la
branche, et les erreurs sans pousser autrement.

Le comportement par défaut de cette commande lorsqu'aucun est donné peut être configuré par
en définissant l'option push de la télécommande, ou la variable de configuration push.default.

Par exemple, pour ne pousser par défaut que la branche actuelle vers l'origine, utilisez git config
remote.origin.push HEAD. Tout valide (comme ceux des exemples ci-dessous) peut
être configuré par défaut pour git push origin.

git push origine :
Poussez les branches "correspondantes" vers l'origine. Voir dans la section OPTIONS ci-dessus pour un
description des branches « correspondantes ».

git pousser le maître d'origine
Trouvez une référence qui correspond à master dans le référentiel source (très probablement, elle trouvera
refs/heads/master), et mettre à jour la même ref (par exemple refs/heads/master) dans origin
référentiel avec lui. Si le maître n'existait pas à distance, il serait créé.

git push origine HEAD
Un moyen pratique de pousser la branche actuelle vers le même nom sur la télécommande.

git push vaisseau mère master:satellite/master dev:satellite/dev
Utilisez la référence source qui correspond au maître (par exemple refs/heads/master) pour mettre à jour la référence
qui correspond au satellite/maître (très probablement refs/remotes/satellite/master) dans le
référentiel de vaisseau-mère ; faire de même pour dev et satellite/dev.

Il s'agit d'émuler git fetch exécuté sur le vaisseau mère en utilisant git push qui est exécuté dans le
sens inverse afin d'intégrer le travail effectué sur satellite, et est souvent
nécessaire lorsque vous ne pouvez établir une connexion que dans un seul sens (c'est-à-dire que le satellite peut ssh dans
vaisseau-mère mais le vaisseau-mère ne peut pas initier la connexion au satellite car ce dernier
est derrière un pare-feu ou n'exécute pas sshd).

Après avoir exécuté ce git push sur la machine satellite, vous devez ssh dans le
Mothership et exécutez git merge pour terminer l'émulation de git pull qui a été exécuté
sur le vaisseau-mère pour extraire les modifications apportées sur le satellite.

git push origin HEAD:maître
Poussez la branche actuelle vers le maître de correspondance de référence distant dans le référentiel d'origine.
Ce formulaire est pratique pour pousser la branche courante sans penser à son local
nom.

git push origin master:refs/heads/expérimental
Créer la branche experimental dans le dépôt d'origine en copiant le master actuel
branche. Ce formulaire n'est nécessaire que pour créer une nouvelle branche ou un nouveau tag dans la télécommande
référentiel lorsque le nom local et le nom distant sont différents ; sinon, la réf
le nom tout seul fonctionnera.

git push origin : expérimental
Trouvez une référence qui correspond à expérimentale dans le référentiel d'origine (par exemple
refs/heads/experimental) et supprimez-le.

git push origin +dev:maître
Mettre à jour la branche master du référentiel d'origine avec la branche dev, permettant
mises à jour non rapides. Ce Vous pouvez quitter non référencé commits balançant in le origine
dépôt. Considérez la situation suivante, où une avance rapide n'est pas possible :

o---o---o---A---B origine/maître
\
Développeur X---Y---Z

La commande ci-dessus changerait le référentiel d'origine en

A---B (branche sans nom)
/
o---o---o---X---Y---Z maître

Les commits A et B n'appartiendraient plus à une branche avec un nom symbolique, et donc
être inaccessible. En tant que tels, ces commits seraient supprimés par une commande git gc sur le
référentiel d'origine.

GIT

Une partie de l' jet(1) Suite

Utilisez git-push en ligne en utilisant les services onworks.net