Analyse détaillée de git-merge (organisée et partagée)

Cet article vous apporte des connaissances pertinentes sur Git, qui présente principalement des problèmes liés à git-merge. La commande git-merge est utilisée pour fusionner des commits spécifiés vers la branche actuelle, j'espère utile à tout le monde.

Étude recommandée : "Tutoriel Git"

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>...]
git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] [--[no-]rerere-autoupdate] [-m <msg>] [<commit>...]
• git merge <msg> HEAD <commit>...
• git merge --abort

1.2git-merge简介

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

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

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

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

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

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

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

1.4git 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-edit参数能够用于接受自动合并的信息（通常情况下并不鼓励这样做）。

如果你在合并时已经给定了-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-onlygit merge <msg> commit>...

git merge --abort

1.2 Introduction à git-merge

🎜La commande git-merge est utilisée à L'opération de fusion du ou des commits spécifiés 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)🎜Pour fusionner d'une branche à une autre

🎜Ensuite, la commande git merge topic fusionnera le nœud commun (nœuds E) séparés après (c'est-à-dire les nœuds A B C de la branche topic) réapparaissent sur la branche master jusqu'au nœud de commit actuel de la branche topic (nœud C), et se situent en haut de la branche master. 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. 🎜🎜Commande 1.3git merge <msg> HEAD <commit>... 🎜🎜L'existence de cette commande est due à des raisons historiques. Elle ne devrait pas être utilisée dans la nouvelle version. utilisez git merge -m <msg> <commit>.... pour remplacer la commande 🎜🎜1.4git merge --abort🎜🎜Cette commande ne provoque des conflits qu'après utilisation fusionnée. 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 : exécuter git-merge avec un grand nombre de fichiers non validés peut facilement vous causer des ennuis, ce qui le rendra difficile pour vous de vous replier dans 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 -- Le paramètre no-commit🎜🎜--commit 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), utilisez --edit (ou -e) est toujours utile, ce qui modifiera davantage le contenu contenu dans -m dans l'éditeur. 🎜

🎜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. 🎜🎜2.4 Commande --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 mode avance rapide, la fusion sera être refusé et renvoie un statut d'échec. 🎜

2.5 --log[=<n>] et --no-log--log[=<n>]和 --no-log

--log[=<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>

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

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

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

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

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

用于验证被合并的节点是否带有GPG签名，并在合并中忽略那些不带有GPG签名验证的节点。
(以下引用摘自一篇转载的文章，由于我没有找到原作者，因此无法提供原作者信息和原文链接，如果有所侵权请私信或者评论告知，我将删除以下引用内容。)

GPG是加密软件，可以使用GPG生成的公钥在网上安全的传播你的文件、代码。
为什么说安全的？以Google所开发的repo为例，repo即采用GPG验证的方式，每个里程碑tag都带有GPG加密验证，假如在里程碑v1.12.3处你想要做修改，修改完后将这个tag删除，然后又创建同名tag指向你的修改点，这必然是可以的。但是，在你再次clone你修改后的项目时，你会发现，你对此里程碑tag的改变不被认可，验证失败，导致你的修改在这里无法正常实现。这就是GPG验证的作用，这样就能够保证项目作者（私钥持有者）所制定的里程碑别人将无法修改。那么，就可以说，作者的代码是安全传播的。
为什么会有这种需求？一个项目从开发到发布，再到后期的更新迭代，一定会存在若干的稳定版本与开发版本（存在不稳定因素）。作为项目发起者、持有者，有权定义他（们）所认可的稳定版本，这个稳定版本，将不允许其他开发者进行改动。还以Google的repo项目为例，项目所有者定义项目开发过程中的点A为稳定版v1.12.3，那么用户在下载v1.12.3版本后，使用的肯定是A点所生成的项目、产品，就算其他开发者能够在本地对v1.12.3进行重新指定，指定到他们修改后的B点，但是最终修改后的版本给用户用的时候，会出现GPG签名验证不通过的问题，也就是说这样的修改是不生效的。

2.11 —summary,--no-summary

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

2.12 -q和 --quiet

静默操作，不显示合并进度信息。

2.13 -v和 --verbose

--log[=<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épertorie pas ces informations.

2.6 Commande --stat, -n, --no-stat 🎜🎜 Paramètres --stat L'état des différences de fichiers sera affiché à 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.
En revanche, les paramètres -n, --no-stat n'afficheront pas cette information. 🎜🎜2.7 --squash et --no-squash🎜🎜--squash Lorsqu'une fusion se produit, branchez à partir de la branche actuelle et du autre branche L'autre nœud de branche après le nœud ancêtre commun et le nœud supérieur de l'autre branche seront compressés ensemble. L'utilisateur peut le soumettre après examen pour générer un nouveau nœud. 🎜

🎜Remarque 1 : Ce paramètre est en conflit avec --no-ff🎜

🎜Remarque 2 : Le résultat de l'utilisation de ce paramètre est similaire à la soumission d'un nouveau sur le nœud de branche actuel. 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> et --strategy=<strategy>🎜🎜-s <strategy> et --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 : 🎜

1. 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) ).
2. 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> et --strategy-option=<option>🎜🎜 dans -s &lt ;strategy> spécifie les paramètres spécifiques de la stratégie (décrits ci-dessous). 🎜🎜2.10 --verify-signatures, --no-verify-signatures🎜🎜 est utilisé pour vérifier si le nœud fusionné a une signature GPG et est ignoré dans la fusion Ces nœuds sans 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 de violation, veuillez me le faire savoir par message privé ou commentez, 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🎜🎜 et --stat et --no- stat est similaire et sera supprimé dans une future version. 🎜🎜2.12 -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--progress和 --no-progress

切换是否显示合并的进度信息。如果二者都没有指定，那么在标准错误发生时，将在连接的终端显示信息。请注意，并不是所有的合并策略都支持进度报告。

2.15-S[<keyid>]和 --gpg-sign[=<keyid>]

GPG签名。

2.16-m <msg>

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

2.17--[no-]rerere-autoupdate

rerere即reuse recorded resolution，重复使用已经记录的解决方案。它允许你让 Git 记住解决一个块冲突的方法，这样在下一次看到相同冲突时，Git 可以为你自动地解决它。

2.18--abort

抛弃当前合并冲突的处理过程并尝试重建合并前的状态。

3.关于合并的其他概念

3.1合并前的检测

在合并外部分支时，你应当保持自己分支的整洁，否则的话当存在合并冲突时将会带来很多麻烦。
为了避免在合并提交时记录不相关的文件，如果有任何在index所指向的HEAD节点中登记的未提交文件，git-pull和git-merge命令将会停止。

3.2fast-forward合并

通常情况下分支合并都会产生一个合并节点，但是在某些特殊情况下例外。例如调用git pull命令更新远端代码时，如果本地的分支没有任何的提交，那么没有必要产生一个合并节点。这种情况下将不会产生一个合并节点，HEAD直接指向更新后的顶端代码，这种合并的策略就是fast-forward合并。

3.3合并细节

除了上文所提到的fast-forward合并模式以外，被合并的分支将会通过一个合并节点和当前分支绑在一起，该合并节点同时拥有合并前的当前分支顶部节点和对方分支顶部节点，共同作为父节点。
一个合并了的版本将会使所有相关分支的变化一致，包括提交节点，HEAD节点和index指针以及节点树都会被更新。只要这些节点中的文件没有重叠的地方，那么这些文件的变化都会在节点树中改动并更新保存。
如果无法明显地合并这些变化，将会发生以下的情况：

1. HEAD指针所指向的节点保持不变
2. MERGE_HEAD指针被置于其他分支的顶部
3. 已经合并干净的路径在index文件和节点树中同时更新
4. 对于冲突路径，index文件记录了三个版本：版本1记录了二者共同的祖先节点，版本2记录了当前分支的顶部，即HEAD，版本3记录了MERGE_HEAD。节点树中的文件包含了合并程序运行后的结果。例如三路合并算法会产生冲突。
5. 其他方面没有任何变化。特别地，你之前进行的本地修改将继续保持原样。
   如果你尝试了一个导致非常复杂冲突的合并，并想重新开始，那么可以使用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冲突是如何表示的

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

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>] et --gpg-sign[=<keyid>]

Signature GPG. 🎜🎜2.16-m <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.
Afin d'é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 pas être fusionnées explicitement, ce qui suit se produira : 🎜

1. Le nœud pointé par le pointeur HEAD reste inchangé
2. MERGE_HEAD Le le pointeur est placé au-dessus des autres branches
3. Le chemin propre fusionné est mis à jour simultanément dans le fichier d'index et l'arborescence des nœuds
4. Pour les chemins en conflit, le fichier d'index enregistre trois versions : Version 1 Le nœud ancêtre commun des deux est enregistré. 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.
5. Aucun autre changement. En particulier, les modifications locales que vous avez apportées précédemment resteront intactes.
   Si vous avez tenté une fusion qui a provoqué un conflit très compliqué et que vous souhaitez recommencer, vous pouvez utiliser git merge --abort

🎜Environ trois Algorithme de fusion routière :
L'algorithme de fusion à trois voies 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 du conflit local. autre branche, et le nœud B de l'autre branche, le nœud ancêtre commun A le plus proche du nœud 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 <<<<<<<, ==== = == et . La partie avant ======= est la situation sur la branche actuelle, et la partie après ======== est la situation sur l'autre branche. branche du côté. 🎜🎜3.6 Comment résoudre les conflits🎜🎜Après avoir vu le conflit, vous pouvez choisir les deux méthodes suivantes :🎜

• J'ai décidé de ne pas fusionner. Pour le moment, la seule chose à faire est de réinitialiser l'index sur le nœud HEAD. git merge --abort est utilisé dans ce cas.
git merge --abort用于这种情况。
• 解决冲突。Git会标记冲突的地方，解决完冲突的地方后使用git add加入到index中，然后使用git commit产生合并节点。
  你可以用以下工具来解决冲突:
• 使用合并工具。git mergetool将会调用一个可视化的合并工具来处理冲突合并。
• 查看差异。git diff将会显示三路差异（三路合并中所采用的三路比较算法）。
• 查看每个分支的差异。git log --merge -p <path>将会显示HEAD版本和MERGE_HEAD版本的差异。
• 查看合并前的版本。git show :1:文件名显示共同祖先的版本，git show :2:文件名显示当前分支的HEAD版本，git show :3:文件名显示对方分支的MERGE_HEAD版本。

4.合并策略

Git可以通过添加-s参数来指定合并的策略。一些合并策略甚至含有自己的参数选项，通过-X<option>设置这些合并策略的参数选项。(不要忘记，合并可以在git merge和git pull命令中发生，因此该合并策略同样适用于git pull)。

4.1resolve

仅仅使用三路合并算法合并两个分支的顶部节点（例如当前分支和你拉取下来的另一个分支）。这种合并策略遵循三路合并算法，由两个分支的HEAD节点以及共同子节点进行三路合并。
当然，真正会困扰我们的其实是交叉合并（criss-cross merge）这种情况。所谓的交叉合并，是指共同祖先节点有多个的情况，例如在两个分支合并时，很有可能出现共同祖先节点有两个的情况发生，这时候无法按照三路合并算法进行合并（因为共同祖先节点不唯一）。resolve策略在解决交叉合并问题时是这样处理的，这里参考《Version Control with Git》：

In criss-cross merge situations, where there is more than one possible merge basis, the resolve strategy works like this: pick one of the possible merge bases, and hope for the best. This is actually not as bad as it sounds. It often turns out that the users have been working on different parts of the code. In that case, Git detects that it's remerging some changes that are already in place and skips the duplicate changes, avoiding the conflict. Or, if these are slight changes that do cause conflict, at least the conflict should be easy for the developer to handle

这里简单翻译一下：在交叉合并的情况时有一个以上的合并基准点（共同祖先节点），resolve策略是这样工作的：选择其中一个可能的合并基准点并期望这是合并最好的结果。实际上这并没有听起来的那么糟糕。通常情况下用户修改不同部分的代码，在这种情况下，很多的合并冲突其实是多余和重复的。而使用resolve进行合并时，产生的冲突也较易于处理，真正会遗失代码的情况很少。

4.2recursive

仅仅使用三路合并算法合并两个分支。和resolve不同的是，在交叉合并的情况时，这种合并方式是递归调用的，从共同祖先节点之后两个分支的不同节点开始递归调用三路合并算法进行合并，如果产生冲突，那么该文件不再继续合并，直接抛出冲突；其他未产生冲突的文件将一直执行到顶部节点。额外地，这种方式也能够检测并处理涉及修改文件名的操作。这是git合并和拉取代码的默认合并操作。
recursive合并策略有以下参数：

4.2.1 ours

该参数将强迫冲突发生时，自动使用当前分支的版本。这种合并方式不会产生任何困扰情况，甚至git都不会去检查其他分支版本所包含的冲突内容这种方式会抛弃对方分支任何冲突内容。

4.2.2 theirs

正好和ours相反。
theirs和ours参数都适用于合并二进制文件冲突的情况。

4.2.2 patience

在这种参数下，git merge-recursive花费一些额外的时间来避免错过合并一些不重要的行（如函数的括号）。如果当前分支和对方分支的版本分支分离非常大时，建议采用这种合并方式。

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

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

4.2.4 ignore-space-change, ignore-all-space, ignore-space-at-eolRésoudre les conflits. Git marquera le conflit. Après avoir résolu le conflit, utilisez git add pour l'ajouter à l'index, puis utilisez git commit pour générer un nœud de fusion.
Vous pouvez utiliser les outils suivants pour résoudre les conflits :

Utilisez l'outil de fusion. git mergetool appellera un outil de fusion visuelle pour gérer les fusions conflictuelles.

Voir les différences. git diff affichera les différences à trois voies (l'algorithme de comparaison à trois voies utilisé dans les fusions à trois voies).

Voir les différences pour chaque branche. git log --merge -p <path> affichera la différence entre la version HEAD et la version MERGE_HEAD. 🎜Voir la version pré-fusion. git show :1:File name affiche la version de l'ancêtre commun, git show :2:File name affiche la version HEAD de la branche actuelle, git show :3 :File Name affiche la version MERGE_HEAD de la branche de l'autre partie.

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

🎜Utilisez 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 extraite). 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 la situation de cross-merge (criss-cross merge). 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. Voici une référence au « Contrôle de version avec Git » : 🎜

🎜Dans les situations de fusion croisée, où il existe plusieurs bases de fusion possibles, 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 grave 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 le détecte. qu'il récupère certaines modifications déjà en place et ignore les modifications en double, évitant ainsi le conflit. Ou, s'il s'agit de légers changements qui provoquent un conflit, 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 lorsqu'il y a plus d'un point de référence de fusion (nœud ancêtre commun), la stratégie de résolution fonctionne comme ceci : sélectionnez l'un des points de référence 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.2récursif

🎜Utilisez 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.
Leurs paramètres 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. 🎜

4.2.3diff-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 pour spécifier les paramètres 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 du conflit.
• Si notre version contient des espaces, mais que la version de l'autre partie contient un grand nombre de modifications, alors la version de l'autre partie le fera être utilisé pendant la fusion du conflit
• Utiliser le traitement normal

4.2.5 no-renamesno-renames

关闭重命名检测。

4.2.6subtree[=<path>]

Désactiver la détection de changement de nom.

4.2.6subtree[=<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 multi-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.

5. Quelques opinions personnelles sur l'utilisation de Git

J'ai toujours pensé que Git était un très excellent outil de contrôle de version, mais de nombreuses personnes dans l'entreprise trouvent Git difficile à utiliser. Cette situation s'explique en grande partie par le fait que l'inertie apportée par l'utilisation antérieure de Subversion a un impact sur l'acceptation des nouvelles technologies. D'un autre côté, de nombreuses personnes n'utilisent Git que via le client GUI. Pendant longtemps, la plupart des gens ont pensé que l'utilisation de l'interface graphique était un moyen plus pratique de démarrer. En fait, c'est discutable. D'après mon expérience personnelle, l'utilisation de l'interface graphique peut créer de l'inertie et les opérations peuvent souvent être effectuées en cliquant sur quelques boutons, ce qui fait penser à de nombreuses personnes que l'apprentissage des commandes Git est une perte de temps et d'énergie. Mais en fait, sans une compréhension claire des commandes et des idées de Git, l'utilisation de ces boutons simples causera en réalité beaucoup de problèmes : beaucoup de gens n'ont aucune idée de ce qui se passera après avoir cliqué sur le bouton, et l'interface graphique est trop intelligente pour laisser le même bouton fonctionner. L'événement click peut correspondre à des commandes avec des paramètres différents. En fin de compte, ce sont les utilisateurs pauvres qui sont vraiment blessés car ils n’ont aucune idée de l’origine du problème.
1. Sur la base du contenu du texte intégral, voici un résumé de certaines des conventions que les individus suivent lorsqu'ils utilisent Git. Le soi-disant accord fait référence à un comportement non forcé et volontaire. Le non-respect de ces conventions n’entraînera aucun défaut, mais le respect de ces conventions peut atténuer les difficultés et améliorer l’efficacité lors de l’utilisation de Git.
2. Soumettez plus, poussez moins. Lorsque plusieurs personnes collaborent, le push provoque fréquemment des conflits de fusion, affectant l'efficacité. Par conséquent, essayez d'utiliser autant que possible les commandes de validation et réduisez l'utilisation de la fusion, ce qui vous fera gagner beaucoup de temps.
3. Utilisez Git Flow (Git Flow), voir mon autre article pour plus de détails : Un modèle de branche Git réussi
Utilisez des branches,
4. Gardez la branche principale propre
. C'est quelque chose que je recommande fortement de soumettre sur la branche, puis de passer à la branche principale pour mettre à jour (git pull —rebase), puis de fusionner les branches et de pousser. Un tel processus évitera les fusions croisées (il n’y aura pas plusieurs nœuds ancêtres communs). En fait, la raison pour laquelle de nombreuses personnes se sentent dépassées par l'opération de fusion git est le problème de fusion croisée causé par diverses raisons, qui entraîne la perte d'une partie du code pendant le processus de fusion. Garder la branche principale propre peut éviter les fusions croisées.

Désactivez le mode avance rapide. Utilisez le paramètre rebase lors de l'extraction du code (le principe est de garder la branche principale propre) et utilisez le paramètre -no-ff pour désactiver le mode avance rapide lors de la fusion. Cela peut non seulement garantir la clarté du nœud, mais également éviter. fusion croisée.
Apprentissage recommandé : "

Tutoriel d'apprentissage 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!