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é). L’option --edit (ou -e) est toujours utile si vous donnez un brouillon de message avec l’option -m de la ligne de commande et que vous voulez l’éditer dans l’éditeur.

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 finale Signed-off-by du validateur à la fin du message de validation. La signification de signoff dépend du projet sur lequel vous validez. Par exemple, cela peut certifier que le validateur a le droit de soumettre son travail sous la licence du projet ou accepte une certaine représentation du contributeur, tel qu’un Certificat d’Origine de Développeur. (Voir https://developercertificate.org/ pour celui utilisé par les projet du noyau Linux ou de Git). Consultez la documentation ou la direction du projet auquel vous contribuez pour comprendre comment les signatures sont utilisées dans ce projet.

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).

Par défaut, les crochets pre-merge et commit-msg sont exécutés. Lorsque --no-verify est donné, ils sont contournés. 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 (ort lors de la fusion d’une seule tête, 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.

Mode Silencieux. Implique --no-progress.

Mode bavard.

Activer/désactiver explicitement l’affichage du progrès. Si aucun des deux n’est spécifié, la progression est indiquée si l’erreur standard est connectée à un terminal. Notez que toutes les stratégies de fusion peuvent ne pas prendre en charge le rapport d’avancement.

Créer automatiquement une entrée temporaire de remisage avant le début de l’opération, l’enregistrer dans la réf MERGE_AUTOSTASH 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.

Définir le message de commit à utiliser pour le commit de fusion (dans le cas où un commit est créé).

Préparer le message de fusion par défaut comme si la fusion se faisait vers la branche <branche>, au lieu du nom de la branche réelle vers laquelle la fusion est faite.

Lire le message de commit à utiliser pour le commit de fusion (dans le cas où un commit est créé).

Après que le mécanisme rerere réutilise une résolution enregistrée sur le conflit actuel pour mettre à jour les fichiers dans l’arbre de travail, lui permettre de mettre également à jour l’index avec le résultat de la résolution. --no-rerere-autoupdate est un bon moyen de revérifier ce que rerere a fait et de détecter des erreurs de fusion potentielles, avant de valider le résultat dans l’index avec un git add séparé.

Écraser silencieusement les fichiers ignorés du résultat de la fusion. C’est le comportement par défaut. Utilisez --no-overwrite-ignore pour abandonner.

Abandonner le processus actuel de résolution des conflits, et essayer de reconstruire l’état antérieur à la fusion. Si une entrée de remisage automatique est présente, l’appliquer à l’arbre de travail.

Oublier la fusion en cours. Laisser l’index et l’arbre de travail en l’ếtat. Si MERGE_AUTOSTASH est présent, l’entrée de la remisage sera sauvegardée dans la liste des remisages.

Après l’arrêt d’un git merge en raison de conflits, vous pouvez conclure la fusion en lançant git merge --continue (voir la section "COMMENT RÉSOUDRE LES CONFLITS" ci-dessous).

Les commits, généralement les sommets des autres branches, à fusionner avec notre branche. En spécifiant plus d’un commit, on crée une fusion avec plus de deux parents (affectueusement appelée fusion Octopus).

C’est la stratégie de fusion par défaut lors du tirage ou de la fusion d’une branche. Cette stratégie ne peut résoudre que deux têtes en utilisant un algorithme de fusion à trois voies. Lorsqu’il y a plus d’un ancêtre commun qui peut être utilisé pour la fusion à trois, il crée un arbre fusionné des ancêtres communs et l’utilise comme arbre de référence pour la fusion à trois. Il a été rapporté que cela permettait de réduire les conflits de fusion sans provoquer de fausses fusions, grâce à des tests effectués sur de vraies fusions tirées de l’historique de développement du noyau Linux 2.6. En outre, cette stratégie permet de détecter et de gérer les fusions impliquant des renommages. Elle ne peut actuellement pas utiliser les copies détectées. Le nom de cet algorithme est un acronyme ("Ostensibly Recursive’s Twin" : Jumeau ostensible de recurse) et vient du fait qu’il a été écrit pour remplacer l’algorithme par défaut précédent, recursive.

Cela ne peut résoudre que deux têtes en utilisant un algorithme de fusion à trois voies. Lorsqu’il y a plus d’un ancêtre commun qui peut être utilisé pour la fusion à trois, il crée un arbre fusionné des ancêtres communs et l’utilise comme arbre de référence pour la fusion à trois. Il a été rapporté que cela permettait de réduire les conflits de fusion sans provoquer de fausses fusions, grâce à des tests effectués sur de vraies fusions tirées de l’historique de développement du noyau Linux 2.6. En outre, cela permet de détecter et de gérer les fusions impliquant des renommages. Cela n’utilise les copies détectées. C’était la stratégie par défaut lors de la résolution de deux sommets pour Git depuis la version v0.99.9k jusqu’à v2.33.0.

Cela ne peut résoudre que deux têtes (c’est-à-dire la branche actuelle et une autre branche dont vous avez tiré) en utilisant un algorithme de fusion à trois points. Cela essaie de détecter avec soin les ambiguïtés de la fusion croisée. Les renommages ne sont pas gérés.

Cela permet de résoudre les cas à plus de deux têtes, mais refuse de faire une fusion complexe qui nécessite une résolution manuelle. C’est principalement destiné à être utilisé pour regrouper les têtes de branches thématiques. C’est la stratégie de fusion par défaut lorsque l’on tire ou fusionne plusieurs branches.

Cela résout un nombre quelconque de têtes, mais l’arbre résultant de la fusion est toujours celui de la tête de la branche actuelle, ignorant effectivement toutes les modifications provenant de toutes les autres branches. C’est censé être utilisé pour remplacer l’ancienne historique du développement des branches latérales. Notez que cette stratégie est différente de l’option -Xours de la stratégie de fusion recursive.

Il s’agit d’une stratégie ort modifiée. Lors de la fusion des arbres A et B, si B correspond à un sous-arbre de A, B est d’abord ajusté pour correspondre à la structure arborescente de A, au lieu de lire les arbres au même niveau. Cet ajustement est également effectué sur l’arbre de l’ancêtre commun.

Définir les options par défaut pour la fusion dans la branche <nom>. La syntaxe et les options prises en charge sont les mêmes que celles de git merge, mais les valeurs d’options contenant des espaces ne sont actuellement pas prises en charge.