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

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

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

Permettre au mécanisme rerere de mettre à jour l’index avec le résultat de la résolution automatique des conflits si possible.

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

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 et est considéré comme généralement sûr et rapide.

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, mais ne peut actuellement pas utiliser les copies détectées. C’est la stratégie de fusion par défaut lors de l’extraction ou de la fusion d’une branche.

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 récursive 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.