bogan
image
C8CF6D76-B282-42E6-ABAF-E481223835FB.png
新疆培训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⽂件还原出来。
本部分⽤于介绍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-only命令
除⾮当前HEAD节点已经up-to-date（更新指向到最新节点）或者能够使⽤fast-forward模式进⾏合并，否则的话将拒绝合并，并返回⼀个失败状态。
2.5 --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>
the gossip-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和 --verbo
显⽰详细的合并结果信息。
2.14 --progress和 --no-progress
切换是否显⽰合并的进度信息。如果⼆者都没有指定，那么在标准错误发⽣时，将在连接的终端显⽰信息。请注意，并不是所有的合并策略都⽀持进度报告。
2.15-S[<keyid>]和 --gpg-sign[=<keyid>]
GPG签名。
2.16-m <msg>
设置⽤于创建合并节点时的提交信息。
如果指定了--log参数，那么commit节点的短⽇志将会附加在提交信息⾥。
2.17--[no-]rerere-autoupdate
rerere即reu recorded resolution，重复使⽤已经记录的解决⽅案。它允许你让 Git 记住解决⼀个块冲突的⽅法，这样在下⼀次看到相同冲突时，Git 可以为你⾃动地解决它。
2.18--abort
hey jude什么意思抛弃当前合并冲突的处理过程并尝试重建合并前的状态。
3.1合并前的检测
在合并外部分⽀时，你应当保持⾃⼰分⽀的整洁，否则的话当存在合并冲突时将会带来很多⿇烦。
为了避免在合并提交时记录不相关的⽂件，如果有任何在index所指向的HEAD节点中登记的未提交⽂件，git-pull和git-merge命令将会停⽌。
3.2fast-forward合并
通常情况下分⽀合并都会产⽣⼀个合并节点，但是在某些特殊情况下例外。例如调⽤git pull命令更新远端代码时，如果本地的分⽀没有任何的提交，那么没有必要产⽣⼀个合并节点。这种情况下将不会产⽣⼀个合并节点，HEAD直接指向更新后的顶端代码，这种合并的策略就是fast-forward合并。
3.3合并细节
除了上⽂所提到的fast-forward合并模式以外，被合并的分⽀将会通过⼀个合并节点和当前分⽀绑在⼀起，该合并节点同时拥有合并前的当前分⽀顶部节点和对⽅分⽀顶部节点，共同作为⽗节点。
⼀个合并了的版本将会使所有相关分⽀的变化⼀致，包括提交节点，HEAD节点和index指针以及节点树都会被更新。只要这些节点中的⽂件没有重叠的地⽅，那么这些⽂件的变化都会在节点树中改动并更新保存。
doolan
freestyle是什么意思如果⽆法明显地合并这些变化，将会发⽣以下的情况：
1. HEAD指针所指向的节点保持不变
2. MERGE_HEAD指针被置于其他分⽀的顶部
3. 已经合并⼲净的路径在index⽂件和节点树中同时更新
4. 对于冲突路径，index⽂件记录了三个版本：版本1记录了⼆者共同的祖先节点，版本2记录了当前分⽀的顶部，即HEAD，版本3记录
truck了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冲突是如何表⽰的
当产⽣合并冲突时，该部分会以<<<<<<<, =======和 >>>>>>>表⽰。在=======之前的部分是当前分⽀这边的情况，在=======之后的部分是对⽅分⽀的情况。
3.6如何解决冲突
>take after
