Effectuer la fusion et valider le résultat. Cette option peut être utilisée pour passer outre --no-commit.

Avant de procéder à une fusion automatisée réussie, lancer un éditeur pour modifier le message de fusion généré automatiquement, afin que l’utilisateur puisse expliquer et justifier la fusion. L’option --no-edit peut être utilisée pour accepter le message généré automatiquement (ce qui est généralement déconseillé).

Cette option détermine comment le message de fusion sera nettoyé avant d’être envoyé. Voir git-commit[1] pour plus de détails. De plus, si le <mode> a la valeur scissors, les ciseaux seront ajoutés à MERGE_MSG avant d’être transmis à la machinerie de commit dans le cas d’un conflit de fusion.

Précise comment une fusion est traitée lorsque l’historique fusionné est déjà un descendant de l’historique actuel. --ff est la valeur par défaut, sauf si l’on fusionne une étiquette annotée (et éventuellement signée) qui n’est pas stockée à sa place naturelle dans la hiérarchie refs/tags/, auquel cas --no-ff est supposé.

Signer le commit résultant de la fusion avec GPG. L’argument idclé est optionnel avec par défaut l’identité du validateur ; si spécifiée, elle doit être collée à l’option sans aucun espace. --no-gpg-sign est utile pour annuler l’effet de la variable de configuration commit.gpgSign ainsi que tout --gpg-sign précédent.

En plus des noms de branches, remplir le message du journal avec les descriptions d’une ligne depuis au maximum <n> commits réels qui sont en train d’être fusionnés. Voir aussi git-fmt-merge-msg[1].

Ajouter une ligne Signed-off-by du validateur à la fin du message de validation. La signification de signoff dépend du projet, mais ceci certifie typiquement que le validateur a les droits de soumettre son travail sous la même licence et accepte un Certificat d’Origine de Développeur (voir http://developercertificate.org/ pour plus d’information).

Afficher un diffstat à la fin de la fusion. Le diffstat est également contrôlé par l’option de configuration merge.stat.

Produire l’arbre de travail et l’état d’index comme si une fusion réelle s’était produite (sauf pour les informations de fusion), mais ne pas faire de commit, déplacer la HEAD, ou enregistrer $GIT_DIR/MERGE_HEAD (pour forcer le prochain git commit à créer un commit de fusion). Cela vous permet de créer un seul commit au-dessus de la branche actuelle dont l’effet est identique à la fusion d’une autre branche (ou plus dans le cas d’une fusion pieuvre).

Cette option court-circuite les crochets pre-merge et commit-msg. Voir aussi githooks[5].

Utiliser la stratégie de fusion donnée ; peut être fourni plus d’une fois pour spécifier l’ordre dans lequel elles doivent être essayées. S’il n’y a pas d’option -s, une liste intégrée de stratégies est utilisée à la place (git merge-recursive lors de la fusion d’une seule tête, git merge-octopus sinon).

Faire passer l’option spécifique de la stratégie de fusion à la stratégie de fusion.

Vérifier que le commit sommet de la branche latérale à fusionner est signé avec une clé valide, c’est-à-dire une clé qui a un uid valide : dans le modèle de confiance par défaut, cela signifie que la clé de signature a été signée par une clé de confiance. Si le commit sommet de la branche latérale n’est pas signé avec une clé valide, la fusion est annulée.

Synonymes de --stat et --no-stat ; ils sont déconseillés et seront supprimés à l’avenir.

Créer automatiquement une entrée temporaire de remisage avant le début de l’opération et l’appliquer après la fin de l’opération. Cela signifie que vous pouvez exécuter l’opération sur un arbre de travail sale. Cependant, utilisez-le avec précaution : l’application finale du remisage après une fusion réussie peut entraîner des conflits non négligeables.

Par défaut, la commande git merge refuse de fusionner les historiques qui ne partagent pas un ancêtre commun. Cette option peut être utilisée pour passer outre cette sécurité lors de la fusion des historiques de deux projets qui ont commencé leur vie indépendamment l’un de l’autre. Comme c’est une occasion très rare, il n’existe pas de variable de configuration pour activer cette option par défaut et elle ne sera pas ajoutée.

Lorsque c’est le cas, rebaser la branche actuelle sur la branche amont après l’avoir récupérée. S’il existe une branche de suivi à distance correspondant à la branche en amont et que la branche en amont a été rebasée depuis la dernière extraction, le rebasage utilise cette information pour éviter de rebaser des modifications non locales.

Écraser le --rebase précédent.

Récupérer tous les distants.

Ajouter les noms de références et les noms d’objets des références récupérées au contenu existant de .git/FETCH_HEAD. Sans cette option, les anciennes données dans .git/FETCH_HEAD seront écrasées.

Limiter la récupération au nombre spécifié de commits à partir du sommet de l’historique de chaque branche distante. Si vous allez chercher dans un dépôt "superficiel" créé par git clone avec l’option --depth=<profondeur> (voir git-clone[1]), approfondir ou raccourcir l’historique jusqu’au nombre spécifié de validations. Les étiquettes pour les commits approfondis ne sont pas récupérées.

Semblable à --depth, sauf que cela précise le nombre de commits à partir de la limite actuelle superficielle au lieu du sommet de l’historique de chaque branche distante.

Approfondir ou raccourcir l’historique d’un dépôt superficiel pour inclure tous les commits accessibles après <date>.

Approfondir ou raccourcir l’historique d’un dépôt superficiel afin d’exclure les commits accessibles depuis une branche ou une étiquette distante spécifiée. Cette option peut être spécifiée plusieurs fois.

Si le dépôt de sources est complet, convertir un dépôt superficiel en un dépôt complet, en supprimant toutes les limitations imposées par les dépôts superficiels.

Par défaut, lors de la récupération d’un dépôt superficiel, git fetch refuse les références qui nécessitent une mise à jour de .git/shallow. Cette option met à jour le fichier .git/shallow et accepte de telles références.

Par défaut, Git signalera au serveur les commits accessibles à partir de toutes les références locales pour trouver les commits communs afin de réduire la taille du fichier de paquet à recevoir. Si ceci est spécifié, Git ne signalera que les commits accessibles à partir des sommets donnés. Ceci est utile pour accélérer les recherches lorsque l’utilisateur sait quelle réf locale est susceptible d’avoir des commits en commun avec la réf amont qui est recherchée.

Montrer ce qui serait fait, sans faire de changements.

Lorsque git fetch est utilisé avec la spécification de référence <src>:<dst>, il peut refuser de mettre à jour la branche locale comme cela a été discuté dans la partie <spécificateur-de-référence> de la documentation git-fetch[1]. Cette option permet de passer outre à ce contrôle.

Conserver le paquet téléchargé.

Avant de récupérer, supprimer toutes les références de suivi à distance qui n’existent plus sur le dépôt distant. Les étiquettes ne sont pas sujettes à l’élagage si elles ne sont récupérées qu’en raison du suivi automatique de l’étiquette par défaut ou en raison d’une option --tags. Cependant, si les étiquettes sont récupérées en raison d’un spécificateur de référence explicite (soit en ligne de commande, soit dans la configuration distante, par exemple si le dépôt distant a été cloné avec l’option --mirror), alors elles sont également sujettes à l’élagage. La fourniture de --prune-tags est une abréviation pour la fourniture du spécificateur de référence d’étiquette.

Par défaut, les étiquettes qui pointent sur des objets téléchargés à partir du dépôt distant sont récupérées et stockées localement. Cette option désactive le suivi automatique des étiquettes. Le comportement par défaut d’un distant peut être spécifié avec le paramètre remote.<nom>.tagOpt. Voir git-config[1].

Lors de la récupération des références listées en ligne de commande, utiliser la spécification de référence (qui peut être donnée plusieurs fois) pour mapper les références sur les branches de suivi à distance, au lieu des valeurs des variables de configuration remote.*.fetch pour le dépôt distant. Fournir un <spécificateur-de-référence> vide à l’option --refmap fait que Git ignore les spécification de référence configurées et se fie entièrement aux spécifications de référence fournies comme arguments de la ligne de commande. Voir la section sur les "Branches de suivi à distance configurées" pour plus de détails.

Récupérer toutes les étiquettes à distance (c’est-à-dire, récupérer les étiquettes refs/tags/* dans les étiquettes locales avec le même nom), en plus de tout ce qui serait récupéré autrement. L’utilisation de cette seule option ne soumet pas les étiquettes à un élagage, même si --prune est utilisé (bien que les étiquettes puissent être élaguées de toute façon si elles sont aussi la destination d’une spécification de référence explicite ; voir --prune).

Nombre d’enfants parallèles à utiliser pour toutes les formes d’extraction.

Si le distant est récupéré avec succès, tirer et ajouter la référence (de suivi) amont , utilisée par les commandes sans argument git-pull[1] et autres. Pour plus d’informations, voir branch.<nom>.merge et branch.<nom>.remote dans git-config[1].

Lorsqu’il est donné, et que le dépôt à récupérer est géré par git fetch-pack, --exec=<upload-pack> est passé à la commande pour spécifier le chemin par défaut pour la commande exécutée à l’autre bout.

L’état d’avancement est affiché sur la sortie d’erreur standard quand elle est attachée à un terminal, à moins que -q soit spécifié. Ce drapeau force l’état d’avancement même si le flux d’erreur standard n’est pas dirigé vers un terminal.

Transmettre la chaîne donnée au serveur lors d’une communication utilisant la version 2 du protocole. La chaîne donnée ne doit pas contenir de caractère NUL ou LF. La gestion par le serveur des options du serveur, y compris les options inconnues, est spécifique au serveur. Lorsque plusieurs ‘---server-option=<option>’ sont donnés, ils sont tous envoyés à l’autre côté dans l’ordre indiqué sur la ligne de commande.

Par défaut, git vérifie si une branche est mise à jour de force pendant la récupération. Cela peut être désactivé via fetch.showForcedUpdates, mais l’option --show-forced-updates garantit que cette vérification a lieu. Voir git-config[1].

Par défaut, git vérifie si une branche est mise à jour de force pendant la récupération. Passer --no-show-forced-updates ou régler fetch.showForcedUpdates à false pour sauter cette vérification pour des raisons de performance. Si elle est utilisée pendant git-pull, l’option --ff-only vérifiera toujours les mises à jour forcées avant de tenter une mise à jour rapide. Voir git-config[1].

Utiliser uniquement les adresses IPv4, en ignorant les adresses IPv6.

Utiliser uniquement les adresses IPv6, en ignorant les adresses IPv4.

Le dépôt "distant" qui est la source d’une opération de récupération ou de tirage. Ce paramètre peut être soit une URL (voir la section URLS GIT ci-dessous) soit le nom d’un remote (voir la section DISTANTS ci-dessous).

Préciser les références à récupérer et les références locales à mettre à jour. Lorsqu’aucun <spéc-de-réf> n’apparaît sur la ligne de commande, les références à récupérer sont lues à partir des variables remote.<dépôt>.fetch à la place (voir la section "[BRANCHES DE SUIVI À DISTANCE CONFIGURÉES]" dans git-fetch[1]).