Dans git, merge signifie "fusionner". Cette commande est utilisée pour fusionner deux ou plusieurs historiques de développement ; la commande de fusion peut être utilisée dans git-pull pour intégrer un autre référentiel de code ; d'une branche à l'autre.

Qu'est-ce que la fusion dans git

L'environnement d'exploitation de ce tutoriel : système Windows 7, Git version 2.30.0, ordinateur Dell G3.

Analyse complète de git-merge

Git-merge est une commande fréquemment utilisée dans Git Beaucoup de gens pensent que git merge est une chose très gênante, si vous ne faites pas attention, vous rencontrerez le problème de la perte de code. Être ainsi découragé de git. Cet article fournit une introduction complète et détaillée à la commande git-merge basée sur Git 2.8.2, notamment en ce qui concerne le problème de perte de code causé par la fusion croisée. Je donne mes propres suggestions à la fin de l'article, dans l'espoir d'aider les utilisateurs de git. . Le contenu présenté dans cet article est basé sur Git 2.8.2

La commande git-merge est une opération utilisée pour fusionner deux ou plusieurs historiques de développement. Elle peut aussi généralement être écrite sous la forme : git merge.

Paramètres d'option liés à 1.git-merge

Résumé 1.1

Dans la commande git-merge, il y a les trois paramètres suivants :

git merge [-n] [--stat] [- - no-commit] [--squash] [--[no-]edit] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] [-- [ no-]rerere-autoupdate] [-m <msg>] [<commit>...]</commit></msg></keyid></strategy-option></strategy>

git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] [--[no-]rerere-autoupdate] [-m <msg>] [<commit>...]</commit></msg></keyid></strategy-option></strategy>

git merge <msg> HEAD <commit>...</commit></msg>
git merge --abort

1.2git-merge简介

git-merge命令是用于从指定的commit(s)合并到当前分支的操作。

注：这里的指定commit(s)是指从这些历史commit节点开始，一直到当前分开的时候。

git-merge命令有以下两种用途：

用于git-pull中，来整合另一代码仓库中的变化（即：git pull = git fetch + git merge）
用于从一个分支到另一个分支的合并

假设下面的历史节点存在，并且当前所在的分支为“master”：

Quest-ce que la fusion dans git

那么git merge topic命令将会把在master分支上二者共同的节点（E节点）之后分离的节点（即topic分支的A B C节点）重现在master分支上，直到topic分支当前的commit节点（C节点），并位于master分支的顶部。并且沿着master分支和topic分支创建一个记录合并结果的新节点，该节点带有用户描述合并变化的信息。

即下图中的H节点，C节点和G节点都是H节点的父节点。

Quest-ce que la fusion dans git

1.3`git merge <msg> HEAD <commit>...</commit></msg>`命令

该命令的存在是由于历史原因，在新版本中不应该使用它，应该使用git merge -m <msg> <commit>....</commit></msg>进行替代

1.4`git merge --abort`命令

该命令仅仅在合并后导致冲突时才使用。git merge --abort将会抛弃合并过程并且尝试重建合并前的状态。但是，当合并开始时如果存在未commit的文件，git merge --abort在某些情况下将无法重现合并前的状态。（特别是这些未commit的文件在合并的过程中将会被修改时）

警告：运行git-merge时含有大量的未commit文件很容易让你陷入困境，这将使你在冲突中难以回退。因此非常不鼓励在使用git-merge时存在未commit的文件，建议使用git-stash命令将这些未commit文件暂存起来，并在解决冲突以后使用git stash pop把这些未commit文件还原出来。

2.参数

本部分用于介绍git-merge命令中使用的参数

2.1`--commit`和`--no-commit`

--commit参数使得合并后产生一个合并结果的commit节点。该参数可以覆盖--no-commit。
--no-commit参数使得合并后，为了防止合并失败并不自动提交，能够给使用者一个机会在提交前审视和修改合并结果。

2.2`--edit`和`-e`以及`--no-edit`

--edit和-e用于在成功合并、提交前调用编辑器来进一步编辑自动生成的合并信息。因此使用者能够进一步解释和判断合并的结果。
--no-editgit merge <msg> HEAD <commit>.. . </commit></msg>

git merge --abort🎜1.2 Introduction à git-merge🎜🎜La commande git-merge est utilisée pour supprimer le commit spécifié ( s) L'opération de fusion dans la branche actuelle. 🎜🎜🎜Remarque : le ou les commits spécifiés ici font référence à partir de ces nœuds de commit historiques jusqu'à la séparation actuelle. 🎜🎜🎜La commande git-merge a les deux utilisations suivantes : 🎜

🎜 est utilisée dans git-pull pour intégrer les modifications dans un autre référentiel de code (c'est-à-dire : git pull = git fetch + git merge) 🎜Utilisé pour fusionner d'une branche à une autre🎜Supposons que le nœud historique suivant existe et que la branche actuelle est "master":
🎜

Quest-ce que la fusion dans git 🎜🎜 Puis le git La commande merge topic reproduira les nœuds séparés après le nœud commun (nœud E) sur la branche maître (c'est-à-dire les nœuds A B C de la branche sujet) sur la branche maître jusqu'à la branche sujet actuelle. Le nœud de validation (C nœud) et est situé en haut de la branche principale. Et créez un nouveau nœud le long de la branche principale et de la branche thématique pour enregistrer les résultats de la fusion. Ce nœud contient les informations de l'utilisateur décrivant les modifications de la fusion. 🎜🎜🎜C'est-à-dire que le nœud H dans la figure ci-dessous, le nœud C et le nœud G sont tous deux les nœuds parents du nœud H. 🎜🎜

Quest-ce que la fusion dans git 🎜🎜1.3 Commande git merge <msg> HEAD <commit>...</commit></msg>🎜🎜Cette commande existe pour des raisons historiques et ne doit pas être utilisée dans les nouvelles versions. Elle devrait être remplacé par git merge -m <msg> <commit>....</commit></msg>🎜🎜1.4git merge --abort command🎜🎜Cette commande est simplement à utiliser uniquement si des conflits surviennent après la fusion. git merge --abort abandonnera le processus de fusion et tentera de reconstruire l'état d'avant la fusion. Cependant, s'il y a des fichiers non validés au démarrage de la fusion, git merge --abort ne pourra pas reproduire l'état d'avant la fusion dans certains cas. (Surtout lorsque ces fichiers non validés seront modifiés pendant le processus de fusion) 🎜🎜🎜Attention : il est facile d'avoir des ennuis lors de l'exécution de git-merge avec un grand nombre de fichiers non validés. difficile pour vous de vous retirer d'un conflit. Par conséquent, il est fortement déconseillé d'avoir des fichiers non validés lors de l'utilisation de git-merge. Il est recommandé d'utiliser la commande git-stash pour stocker temporairement ces fichiers non validés et résoudre les conflits. . Utilisez git stash pop pour restaurer ces fichiers non validés. 🎜🎜🎜2. Paramètres🎜🎜Cette section est utilisée pour présenter les paramètres utilisés dans la commande git-merge🎜🎜2.1--commit et --no -commit 🎜🎜--commitLe paramètre provoque la génération d'un nœud de validation du résultat fusionné après la fusion. Ce paramètre peut remplacer --no-commit. Le paramètre
--no-commit empêche la soumission automatique de la fusion afin d'éviter tout échec de la fusion, donnant à l'utilisateur la possibilité d'examiner et de modifier les résultats de la fusion avant la soumission. 🎜🎜2.2 --edit et -e et --no-edit🎜🎜--edit et -e est utilisé pour appeler l'éditeur afin de modifier davantage les informations de fusion générées automatiquement avant une fusion et une soumission réussies. Par conséquent, les utilisateurs peuvent interpréter et juger davantage les résultats de la fusion. Le paramètre
--no-edit peut être utilisé pour accepter les informations fusionnées automatiquement (ceci est généralement déconseillé). 🎜

Si vous avez donné le paramètre -m lors de la fusion (décrit ci-dessous), utiliser --edit (ou -e) est toujours utile , cela modifiera davantage le contenu contenu dans -m dans l'éditeur. -m参数（下文介绍），使用 --edit（或-e）依然是有用的，这将在编辑器中进一步编辑-m所含的内容。

旧版本的节点可能并不允许用户去编辑合并日志信息。

2.3`--ff`命令

--ff是指fast-forward命令。当使用fast-forward模式进行合并时，将不会创造一个新的commit节点。默认情况下，git-merge采用fast-forward模式。
关于fast-forward模式的详细解释，请看我的另一篇文章：一个成功的Git分支模型的“关于fast forward”一节。

2.4`--no-ff`命令

即使可以使用fast-forward模式，也要创建一个新的合并节点。这是当git merge在合并一个tag时的默认行为。

2.5`--ff-only`命令

除非当前HEAD节点已经up-to-date（更新指向到最新节点）或者能够使用fast-forward模式进行合并，否则的话将拒绝合并，并返回一个失败状态。

2.5 `--log[=<n>]</n>`和 `--no-log`

--log[=<n>]</n>将在合并提交时，除了含有分支名以外，还将含有最多n个被合并commit节点的日志信息。
--no-log并不会列出该信息。

2.6 `--stat`, `-n`, `--no-stat`命令

--stat参数将会在合并结果的末端显示文件差异的状态。文件差异的状态也可以在git配置文件中的merge.stat配置。
相反，-n, --no-stat参数将不会显示该信息。

2.7`--squash` 和`--no-squash`

--squash 当一个合并发生时，从当前分支和对方分支的共同祖先节点之后的对方分支节点，一直到对方分支的顶部节点将会压缩在一起，使用者可以经过审视后进行提交，产生一个新的节点。

注意1:该参数和--no-ff冲突

注意2:该参数使用后的结果类似于在当前分支提交一个新节点。在某些情况下这个参数非常有用，例如使用Git Flow时（关于Git Flow，请参考：一个成功的Git分支模型），功能分支在进行一个功能需求的研发时，开发者可能在本地提交了大量且无意义的节点，当需要合并到develop分支时，可能仅仅需要用一个新的节点来表示这一长串节点的修改内容，这时--squash命令将会发挥作用。此外，如果功能分支的多次提交并不是琐碎而都是有意义的，使用--no-ff命令更为合适。
--no-squash的作用正好相反。

2.8 `-s <strategy></strategy>`和 `--strategy=<strategy></strategy>`

-s <strategy></strategy>和 --strategy=<strategy></strategy>用于指定合并的策略。默认情况如果没有指定该参数，git将按照下列情况采用默认的合并策略：

合并节点只含有单个父节点时（如采用fast-forward模式时），采用recursive策略（下文介绍）。
合并节点含有多个父节点时(如采用no-fast-forward模式时)，采用octopus策略（下文介绍）。

2.9 `-X <option></option>`和 `--strategy-option=<option></option>`

在-s <strategy></strategy>时指定该策略的具体参数（下文介绍）。

2.10 `--verify-signatures`, `--no-verify-signatures`

Les anciennes versions des nœuds peuvent ne pas permettre aux utilisateurs de modifier les informations du journal de fusion.

2.3 Commande `--ff` 🎜`--ff` fait référence à la commande d'avance rapide. Lors de la fusion en mode avance rapide, aucun nouveau nœud de validation ne sera créé. Par défaut, `git-merge` utilise le mode avance rapide. 🎜Pour une explication détaillée du mode avance rapide, veuillez consulter la section « À propos de l'avance rapide » de mon autre article : Un modèle de branchement Git réussi. 🎜Commande

2.4`--no-ff`🎜🎜Créez un nouveau nœud de fusion même si le mode avance rapide peut être utilisé. C'est le comportement par défaut lorsque `git merge` fusionne une balise. 🎜Commande

2.5`--ff-only`🎜🎜À moins que le nœud HEAD actuel n'ait été à jour (mis à jour avec le dernier nœud) ou qu'il puisse être fusionné en utilisant le mode avance rapide, sinon il rejettera la fusion et renverra un statut d'échec. 🎜

2.5 `--log[=<n>]</n>` et `--no-log`🎜🎜`--log[=<n>] </n>`Lors de la fusion et de la soumission, en plus du nom de la branche, il contiendra également les informations de journal d'un maximum de n nœuds de validation fusionnés. 🎜`--no-log` ne répertoriera pas ces informations. 🎜

2.6 Commandes `--stat`, `-n`, `--no-stat`🎜🎜`--stat`Le paramètre affichera l'état des différences de fichiers à la fin du résultat fusionné. L'état des différences de fichiers peut également être configuré dans merge.stat dans le fichier de configuration git. 🎜Au contraire, les paramètres `-n`, `--no-stat` n'afficheront pas cette information. 🎜

2.7`--squash` et `--no-squash`🎜🎜`--squash` Lorsqu'une fusion se produit, à partir de la branche actuelle et L'autre nœud de branche après le nœud ancêtre commun de l'autre branche jusqu'à ce que le nœud supérieur de l'autre branche soit compressé ensemble. L'utilisateur peut le soumettre après examen pour générer un nouveau nœud. 🎜🎜🎜Note 1 : Ce paramètre est en conflit avec `--no-ff`🎜🎜🎜Note 2 : Le résultat de l'utilisation de ce paramètre est similaire à la soumission d'un nouveau nœud sur la branche actuelle. Ce paramètre est très utile dans certains cas, comme lors de l'utilisation de Git Flow (à propos de Git Flow, veuillez vous référer à : Un modèle de branche Git réussi. Lorsque la branche de fonction développe une exigence fonctionnelle, le développeur peut en soumettre un grand nombre localement). .Et les nœuds dénués de sens, lorsqu'ils doivent être fusionnés dans la branche de développement, vous n'aurez peut-être besoin que d'un nouveau nœud pour représenter le contenu de modification de cette longue liste de nœuds. À ce stade, le `--squashLa commande code> entrera en jeu. De plus, si les multiples soumissions de la branche de fonctionnalité ne sont pas triviales mais significatives, l'utilisation de la commande <code>--no-ff` est plus appropriée. 🎜`--no-squash` fait exactement le contraire. 🎜

2.8 `-s <strategy></strategy>` et `--strategy=<strategy></strategy>`🎜🎜-s et --strategy=<strategy></strategy> sont utilisés pour spécifier la stratégie de fusion. Par défaut, si ce paramètre n'est pas spécifié, git utilisera la stratégie de fusion par défaut selon les conditions suivantes : 🎜 Lorsque le nœud de fusion ne contient qu'un seul nœud parent (comme lors de l'utilisation du mode avance rapide) , la stratégie récursive (décrite ci-dessous) ). Lorsque le nœud fusionné contient plusieurs nœuds parents (par exemple lors de l'utilisation du mode sans avance rapide), la stratégie Octopus (décrite ci-dessous) est utilisée. 2.9 -X <option></option> et --strategy-option=<option></option>🎜🎜 dans - s <strategy></strategy> lors de la spécification des paramètres spécifiques de la stratégie (décrits ci-dessous). 🎜 2.10 --verify-signatures, --no-verify-signatures🎜🎜 Utilisé pour vérifier si le nœud fusionné a une signature GPG et le fusionner Ignorer les nœuds qui n'ont pas de vérification de signature GPG. 🎜(La citation suivante est tirée d'un article réimprimé. Comme je n'ai pas trouvé l'auteur original, je ne peux pas fournir les informations sur l'auteur original ni le lien original. En cas d'infraction, veuillez me le faire savoir par message privé ou par commentaire, et Je supprimerai la citation suivante.)🎜GPG est un logiciel de cryptage Vous pouvez utiliser la clé publique générée par GPG pour diffuser en toute sécurité vos fichiers et codes sur Internet. Pourquoi dites-vous sûr ? Prenons l'exemple du dépôt développé par Google. Le dépôt utilise la vérification GPG. Chaque balise de jalon a une vérification de cryptage GPG. Si vous souhaitez apporter des modifications au jalon v1.12.3, supprimez la balise après la modification, puis il est tout à fait possible de le faire. créez une balise du même nom pour pointer vers votre point de modification. Cependant, lorsque vous clonez à nouveau votre projet modifié, vous constaterez que vos modifications apportées à cette balise de jalon ne sont pas reconnues et que la vérification échoue, ce qui empêche vos modifications d'être implémentées normalement ici. C'est le rôle de la vérification GPG, qui garantit que les jalons fixés par l'auteur du projet (détenteur de la clé privée) ne peuvent pas être modifiés par d'autres. On peut alors dire que le code de l'auteur est diffusé en toute sécurité. Pourquoi y a-t-il un tel besoin ? Du développement à la publication en passant par les itérations de mise à jour ultérieures d'un projet, il y aura certainement un certain nombre de versions stables et de versions de développement (il existe des facteurs d'instabilité). En tant qu'initiateurs et porteurs de projets, ils ont le droit de définir une version stable qu'ils reconnaissent. Cette version stable ne permettra pas aux autres développeurs d'y apporter des modifications. Prenons l'exemple du projet de dépôt de Google. Le propriétaire du projet définit le point A dans le processus de développement du projet comme la version stable v1.12.3. Ensuite, une fois que les utilisateurs auront téléchargé la version v1.12.3, ils utiliseront définitivement les projets et produits générés par le point A. Même si d'autres développeurs peuvent respécifier la v1.12.3 localement et la spécifier à leur point B modifié, lorsque la version modifiée sera finalement utilisée par les utilisateurs, il y aura un problème d'échec de la vérification de la signature GPG, c'est-à-dire que c'est le cas. la modification ne prendra pas effet. 2.11 —résumé, --no-summary—summary,--no-summary



和--stat与 --no-stat相似，并将在未来版本移除。
2.12 -q和 --quiet

静默操作，不显示合并进度信息。
2.13 -v和 --verbose

显示详细的合并结果信息。
2.14 --progress和 --no-progress

切换是否显示合并的进度信息。如果二者都没有指定，那么在标准错误发生时，将在连接的终端显示信息。请注意，并不是所有的合并策略都支持进度报告。
2.15-S[<keyid>]</keyid>和 --gpg-sign[=<keyid>]</keyid>

GPG签名。
2.16-m <msg></msg>

设置用于创建合并节点时的提交信息。
如果指定了--log参数，那么commit节点的短日志将会附加在提交信息里。
2.17--[no-]rerere-autoupdate

rerere即reuse recorded resolution，重复使用已经记录的解决方案。它允许你让 Git 记住解决一个块冲突的方法，这样在下一次看到相同冲突时，Git 可以为你自动地解决它。
2.18--abort
 et --stat et --no-stat code code> est similaire et sera supprimé dans une prochaine version. <p></p>2.12 <code>-q et --quiet
Fonctionnement silencieux, aucune information sur la progression de la fusion n'est affichée. 
2.13 -v et --verbose
Affichez des informations détaillées sur le résultat de la fusion. 
2.14 --progress et --no-progress

Choisissez d'afficher ou non les informations de progression fusionnées. Si aucun des deux n'est spécifié, un message s'affichera sur le terminal connecté lorsqu'une erreur standard se produit. Notez que toutes les stratégies de fusion ne prennent pas en charge les rapports de progression. 
2.15-S[<keyid>]</keyid> et --gpg-sign[=<keyid>]</keyid>

Signature GPG. 

2.16-m <msg></msg>
🎜Définissez les informations de validation utilisées lors de la création de nœuds de fusion. 🎜Si le paramètre --log est spécifié, le court journal du nœud de validation sera ajouté au message de validation. 🎜🎜2.17-[no-]rerere-autoupdate🎜🎜rerere consiste à réutiliser la résolution enregistrée et à réutiliser la solution enregistrée. Il vous permet de demander à Git de se rappeler comment résoudre un conflit de blocage, afin que la prochaine fois que vous verrez le même conflit, Git puisse le résoudre automatiquement pour vous. 🎜🎜2.18--abort🎜🎜Abandonnez le processus actuel de gestion des conflits de fusion et essayez de reconstruire l'état d'avant la fusion. 🎜🎜3. Autres concepts sur la fusion🎜🎜3.1 Détection avant la fusion🎜🎜Lors de la fusion de branches externes, vous devez garder vos propres branches propres, sinon cela causera beaucoup de problèmes en cas de conflits de fusion. 🎜Pour éviter d'enregistrer des fichiers non pertinents lors de la fusion des validations, les commandes git-pull et git-merge s'arrêteront s'il y a des fichiers non validés enregistrés dans le nœud HEAD pointé par index. 🎜🎜3.2fusion rapide🎜🎜Normalement, la fusion de branches produira un nœud de fusion, mais il existe des exceptions dans certains cas particuliers. Par exemple, lors de l'appel de la commande git pull pour mettre à jour le code distant, si la branche locale n'a aucun commit, il n'est pas nécessaire de générer un nœud de fusion. Dans ce cas, aucun nœud de fusion ne sera généré et HEAD pointe directement vers le code supérieur mis à jour. Cette stratégie de fusion est une fusion rapide. 🎜🎜3.3 Détails de la fusion🎜🎜En plus du mode de fusion rapide mentionné ci-dessus, la branche fusionnée sera liée à la branche actuelle via un nœud de fusion, qui a également le nœud supérieur de la branche actuelle avant la fusion et le nœud supérieur nœud de l’autre branche, ensemble en tant que nœud parent. 🎜Une version fusionnée rendra cohérentes les modifications dans toutes les branches associées, y compris le nœud de validation, le nœud HEAD et le pointeur d'index, et l'arborescence des nœuds sera mise à jour. Tant que les fichiers de ces nœuds ne se chevauchent pas, les modifications apportées à ces fichiers seront modifiées et mises à jour dans l'arborescence des nœuds. 🎜Si ces modifications ne peuvent évidemment pas être fusionnées, ce qui suit se produira : 🎜
Le nœud pointé par le pointeur HEAD reste inchangé
Le pointeur MERGE_HEAD est placé au-dessus des autres branchesMERGE_HEAD指针被置于其他分支的顶部
已经合并干净的路径在index文件和节点树中同时更新
对于冲突路径，index文件记录了三个版本：版本1记录了二者共同的祖先节点，版本2记录了当前分支的顶部，即HEAD，版本3记录了MERGE_HEAD。节点树中的文件包含了合并程序运行后的结果。例如三路合并算法会产生冲突。
其他方面没有任何变化。特别地，你之前进行的本地修改将继续保持原样。
如果你尝试了一个导致非常复杂冲突的合并，并想重新开始，那么可以使用git merge --abort


关于三路合并算法：
三路合并算法是用于解决冲突的一种方式，当产生冲突时，三路合并算法会获取三个节点：本地冲突的B节点，对方分支的C节点，B，C节点的共同最近祖先节点A。三路合并算法会根据这三个节点进行合并。具体过程是，B，C节点和A节点进行比较，如果B，C节点的某个文件和A节点中的相同，那么不产生冲突；如果B或C只有一个和A节点相比发生变化，那么该文件将会采用该变化了的版本；如果B和C和A相比都发生了变化，且变化不相同，那么则需要手动去合并;如果B，C都发生了变化，且变化相同，那么并不产生冲突，会自动采用该变化的版本。最终合并后会产生D节点，D节点有两个父节点，分别为B和C。
3.4合并tag
当合并一个tag时，Git总是创建一个合并的提交，即使这时能够使用fast-forward模式。该提交信息的模板预设为该tag的信息。额外地，如果该tag被签名，那么签名的检测信息将会附加在提交信息模板中。
3.5冲突是如何表示的

当产生合并冲突时，该部分会以, <code>=======和 表示。在=======之前的部分是当前分支这边的情况，在=======之后的部分是对方分支的情况。

3.6如何解决冲突

在看到冲突以后，你可以选择以下两种方式：

决定不合并。这时，唯一要做的就是重置index到HEAD节点。git merge --abort用于这种情况。
解决冲突。Git会标记冲突的地方，解决完冲突的地方后使用git add加入到index中，然后使用git commit产生合并节点。
你可以用以下工具来解决冲突:
使用合并工具。git mergetool将会调用一个可视化的合并工具来处理冲突合并。
查看差异。git diff将会显示三路差异（三路合并中所采用的三路比较算法）。
查看每个分支的差异。git log --merge -p <path></path>将会显示HEAD版本和MERGE_HEAD版本的差异。
查看合并前的版本。git show :1:文件名显示共同祖先的版本，git show :2:文件名显示当前分支的HEAD版本，git show :3:文件名显示对方分支的MERGE_HEAD版本。

4.合并策略

Git可以通过添加-s参数来指定合并的策略。一些合并策略甚至含有自己的参数选项，通过-X<option></option>

Le chemin propre fusionné est mis à jour simultanément dans le fichier d'index et l'arborescence des nœuds

Pour les chemins conflictuels, le fichier d'index enregistre trois versions : la version 1 enregistre le nœud ancêtre commun des deux, la version 2 enregistre le haut de la branche actuelle, c'est-à-dire HEAD, et la version 3 enregistre MERGE_HEAD. Les fichiers de l'arborescence des nœuds contiennent les résultats de l'exécution du programme de fusion. Par exemple, l'algorithme de fusion à trois peut provoquer des conflits.

Aucun autre changement. En particulier, les modifications locales que vous avez apportées précédemment resteront intactes.

Si vous avez essayé une fusion qui a abouti à un conflit très complexe et que vous souhaitez recommencer, vous pouvez utiliser git merge --abort🎜

🎜À propos de l'algorithme de fusion à trois voies : 🎜Trois L'algorithme de fusion de chemins est un moyen de résoudre les conflits. Lorsqu'un conflit survient, l'algorithme de fusion à trois voies obtiendra trois nœuds : le nœud B du conflit local, le nœud C de l'autre branche et le nœud commun le plus proche. nœud ancêtre A des nœuds B et C. L'algorithme de fusion à trois voies fusionnera en fonction de ces trois nœuds. Le processus spécifique consiste à comparer les nœuds B et C avec le nœud A. Si un fichier dans les nœuds B et C est le même que celui du nœud A, alors il n'y aura pas de conflit si un seul des nœuds B ou C a changé par rapport au nœud ; A, alors le fichier adoptera la version modifiée ; si B et C ont changé par rapport à A et que les modifications ne sont pas les mêmes, alors vous devez les fusionner manuellement si B et C ont changé et que les modifications sont les mêmes ; , alors il n'y aura pas de conflit et la version modifiée sera automatiquement adoptée. Après la fusion finale, un nœud D sera généré. Le nœud D a deux nœuds parents, à savoir B et C. 🎜

🎜3.4 Fusion de balises🎜🎜Lors de la fusion d'une balise, Git crée toujours un commit fusionné, même si le mode avance rapide peut être utilisé. Le modèle des informations de soumission est prédéfini sur les informations de la balise. De plus, si la balise est signée, les informations de détection de signature seront ajoutées au modèle de message de validation. 🎜🎜3.5 Comment les conflits sont exprimés🎜🎜Lorsqu'un conflit de fusion se produit, cette partie sera marquée avec , <code>==== = == et . La partie avant ======= est la situation sur la branche actuelle, et la partie après ======== est la situation sur l'autre branche. branche latérale. 🎜🎜3.6 Comment résoudre les conflits🎜🎜Après avoir vu le conflit, vous pouvez choisir les deux méthodes suivantes : 🎜

git merge --abort

git add

git commit

git mergetool

git diff

git log --merge -p <path></path>

HEAD

MERGE_HEAD

git show :1:File name

git show :2:File name

git show :3 :File Name

MERGE_HEAD

4. Stratégie de fusion

🎜Git peut spécifier la stratégie de fusion en ajoutant le paramètre -s. Certaines stratégies de fusion ont même leurs propres options de paramètres, qui peuvent être définies via -X<option></option>. (N'oubliez pas que la fusion peut se produire à la fois dans les commandes git merge et git pull, donc cette stratégie de fusion s'applique également à git pull). 🎜🎜4.1resolve🎜🎜 utilise uniquement l'algorithme de fusion à trois voies pour fusionner les nœuds supérieurs de deux branches (comme la branche actuelle et une autre branche que vous avez supprimée). Cette stratégie de fusion suit un algorithme de fusion à trois voies, dans lequel les nœuds HEAD des deux branches et les nœuds enfants communs effectuent une fusion à trois voies. 🎜Bien sûr, ce qui nous dérange vraiment, c'est le cas des fusions croisées. La fusion croisée fait référence à la situation dans laquelle il existe plusieurs nœuds ancêtres communs. Par exemple, lorsque deux branches sont fusionnées, il est très probable qu'il existe deux nœuds ancêtres communs. À ce stade, la fusion ne peut pas être effectuée en conséquence. à l'algorithme de fusion à trois voies (car les nœuds ancêtres communs ne sont pas uniques). Voici comment la stratégie de résolution gère les problèmes de fusion croisée. Veuillez vous référer à « Contrôle de version avec Git » ici : 🎜.

Dans les situations de fusion croisée, où il existe plus d'une base de fusion possible, la stratégie de résolution fonctionne comme ceci : choisissez l'une des bases de fusion possibles et espérez le meilleur. Ce n'est en fait pas aussi mauvais qu'il y paraît. Il s'avère souvent que les utilisateurs ont travaillé sur différentes parties du code. Dans ce cas, Git détecte qu'il récupère certaines modifications déjà en place et ignore les modifications en double, évitant ainsi le conflit. qui provoquent des conflits, au moins le conflit devrait être facile à gérer pour le développeur

Voici une traduction simple : dans le cas d'une fusion croisée, il existe plus d'un point de référence de fusion (nœud ancêtre commun), et le La stratégie de résolution fonctionne comme ceci : sélectionnez l'un des points de base de fusion possibles et espérez que ce soit le meilleur résultat de la fusion. Ce n’est en réalité pas aussi grave qu’il y paraît. Habituellement, les utilisateurs modifient différentes parties du code, auquel cas de nombreux conflits de fusion sont en réalité redondants et répétitifs. Lorsque vous utilisez solve pour fusionner, les conflits générés sont plus faciles à gérer et il existe très peu de cas où le code sera réellement perdu.

4.2recursive

utilise uniquement l'algorithme de fusion à trois voies pour fusionner deux branches. Contrairement à la résolution, dans le cas d'une fusion croisée, cette méthode de fusion est appelée de manière récursive. À partir de nœuds différents des deux branches après le nœud ancêtre commun, l'algorithme de fusion à trois voies est appelé de manière récursive pour fusionner. le fichier La fusion ne se poursuivra plus et les conflits seront générés directement ; les autres fichiers sans conflits seront exécutés jusqu'au nœud supérieur. De plus, cette approche est capable de détecter et de gérer les opérations impliquant la modification des noms de fichiers. Il s'agit de l'opération de fusion par défaut pour la fusion et l'extraction de code avec Git.
La stratégie de fusion récursive a les paramètres suivants :

4.2.1 la nôtre

Ce paramètre forcera l'utilisation automatique de la version de la branche actuelle lorsqu'un conflit survient. Cette méthode de fusion ne posera aucun problème, et même git ne vérifiera pas le contenu en conflit contenu dans les autres versions de branche. Cette méthode éliminera tout contenu en conflit dans l'autre branche.

4.2.2 le leur

est exactement le contraire du nôtre.
Les leurs et les nôtres conviennent à la fusion des conflits de fichiers binaires.

4.2.2 patience

Avec ce paramètre, git merge-recursive passe un peu plus de temps pour éviter de manquer des lignes sans importance (comme les parenthèses de fonctions). Si la séparation entre les branches de version de la branche actuelle et de l'autre branche est très grande, il est recommandé d'utiliser cette méthode de fusion. git merge-recursive花费一些额外的时间来避免错过合并一些不重要的行（如函数的括号）。如果当前分支和对方分支的版本分支分离非常大时，建议采用这种合并方式。

4.2.3`diff-algorithm=[patience|minimal|histogram|myers]`

告知git merge-recursive使用不同的比较算法。

4.2.4 `ignore-space-change`, `ignore-all-space`, `ignore-space-at-eol`

根据指定的参数来对待空格冲突。

如果对方的版本仅仅添加了空格的变化，那么冲突合并时采用我们自己的版本
如果我们的版本含有空格，但是对方的版本包含大量的变化，那么冲突合并时采用对方的版本
采用正常的处理过程

4.2.5 `no-renames`

关闭重命名检测。

4.2.6`subtree[=<path>]</path>`

4.2.3 diff-algorithm=[patience|minimal|histogram|myers]

indique à git merge-recursive d'utiliser un algorithme de comparaison différent.

4.2.4 ignore-space-change, ignore-all-space, ignore-space-at-eol

Selon le Paramètres spécifiés pour traiter les conflits d’espaces.

Si la version de l'autre partie ajoute uniquement des modifications dans les espaces, alors notre propre version sera utilisée lors de la fusion des conflits

Si notre version contient des espaces, mais que la version de l'autre partie en contient un grand nombre des modifications, puis utilisez la version de l'autre partie lors de la fusion des conflits

Adoptez les procédures de traitement normales

4.2.5 pas de renommage

Désactivez le renommage détection.

4.2.6subtree[=<path>]</path>

Cette option est une forme avancée de stratégie de fusion de sous-arbres, qui devinera comment les deux arbres de nœuds se déplacent pendant le processus de fusion. La différence est que le chemin spécifié sera supprimé au début de la fusion, afin que d'autres chemins puissent être mis en correspondance lors de la recherche de sous-arbres. (Voir ci-dessous pour plus de détails sur la stratégie de fusion de sous-arbres)

4.3octopus

Cette méthode de fusion est utilisée pour plus de deux branches, mais elle refusera de fusionner lorsque des conflits nécessitent une fusion manuelle. Cette méthode de fusion est plus adaptée au regroupement de plusieurs branches et constitue également la stratégie de fusion par défaut pour les fusions de plusieurs branches. 4.4ours

Cette méthode peut fusionner n'importe quel nombre de branches, mais le résultat fusionné de l'arborescence des nœuds est toujours la partie en conflit de la branche actuelle. Cette méthode peut être très efficace lors du remplacement d’anciennes versions. Veuillez noter que cette méthode est différente du paramètre nôtre dans le cadre de la stratégie récursive.

4.5subtree

subtree est une version modifiée de la stratégie récursive. Lors de la fusion de l'arbre A et de l'arbre B, si B est un sous-arbre de A, B s'ajuste d'abord pour correspondre à la structure arborescente de A au lieu de lire le même nœud. 🎜🎜4.5 Résumé🎜🎜Lors de l'utilisation de la stratégie de fusion à trois voies (faisant référence à la stratégie récursive par défaut), si un fichier (ou une ligne de code) change à la fois dans la branche actuelle et dans l'autre branche, mais revient ensuite sur l'une des branches , 🎜Ensuite, ce changement de repli sera reflété dans les résultats🎜. Ce point peut dérouter certaines personnes. En effet, lors du processus de fusion, git se concentre uniquement sur le nœud ancêtre commun et le nœud HEAD des deux branches, plutôt que sur tous les nœuds des deux branches. Par conséquent, l'algorithme de fusion considérera la partie annulée comme 🎜inchangée🎜, de sorte que le résultat fusionné deviendra la partie modifiée de l'autre branche. 🎜🎜Apprentissage recommandé : "🎜Tutoriel Git🎜"🎜

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!