git pull进行拉回操作时的合并, 在前面的一个博客之处, 我们讲到了非快进式推送的非强制性的又一种解决办法, 那便是先拉回再提交, 这里的拉回实际上涵盖着两个操作: 获取远程仓库的数据。把本地数据加以合并。能够这般来写: git pull = git fetch + git merge。git merge命令用以合并分支, 它的命令行格式为: git merge。
options...
大部分情形下的合并, 我们只需给出一个提交分支就行, 会默认把指定分支合并进当前分支里。可以了, 默认将指定分支合并到当前分支中。合并后的提交, 把当前分支的提交当作第一个父提交, 将其作为第二个父提交, 合并操作还支持多个与当前工作分支进行合并, 默认情形下, 合并后的结果会自动提交, 我们能够通过设置选项来指定手动提交, 借助命令: git merge --no-commit...模式能够指定合并, 先把结果放进暂存区, 让用户手动对合并结果予以检查、更改, 接着手动提交, 合并操作并非总是会成功, 下面会详细介绍。
自动合并这一类, 不会报错, 无需用户处理相应错误, 主要分三种。若两个或多个, 这里以两个为例, user1/user2 各自本地提交中, 修改的是不同文件, 第二次合并推送提交可正确合并并提交, 不存在麻烦。若修改相同文件不同区域, 要说明文件修改可细分到行, 且能通过 cat＞fileName.suffix 命令逐行修改。当 user1 用户修改 index.txt 文件第一行第二行并提交与上游推送, user2 用户修改 index.txt 文件第三行第四行, 执行 git pull 命令可正常合并无麻烦。若同时更改文件名和文件内容, user1 用户将 index.txt 文件重命名为 index2.txt 并删除原文件提交与上游推送, user2 用户执行 git pull 获取合并信息后能正常合并, 之后推送 git push origin master 成功, 查看远程仓库内容, 会发现 git 对这情况处理方式是: user2 用户最终修改的是 user1 用户对应重命名后的文件。这种自动合并存在逻辑冲突, 以 C 语言编程举例: 在 main.c 文件中调用 head.h 文件, 另一用户重命名为 head2.h 文件, 使用 main.c 文件会编译错误: 找不到 head.h 头文件。所以处于这种情形下, 我们应当慎重地合并, 或者在此次提交操作之上增添一些关键的注释。
合并二: 当两个用户同时对同一个文件的相同区域内容进行修改时, 冲突事件便会发生。看如下例子: 首先, 为确保两个用户的本地版本库与远程版本库保持一致, 需分别执行命令: git pull。然后, 先将user1用户对文件hello.txt的修改内容设置成如下情况并予以提交:
然后user2用户进行同样的修改操作如下：
下面, 我们来开展user2用户的并非快进式的合并推送, 届时, 将会发觉合并是失败的。
在这种状况下, 是由于两个用户针对相同文件的相同区域予以了同时修改, 进而致使所产生的冲突, 去凭借命令查看当下状态时, 会察觉到其所输出的日志明确告知我们, 针对一个名为hello.txt的文件进行了同时修改。
此后我们借由一条命令去弄明白究竟是哪一些文件出现了合并冲突, 这条命令便是: git ls-files -s , 仅当该命令输出的第二列的值是0的时候才代表与之相对应的文件不存在冲突, 且合并顺利成功；要是该值并非0的话, 那就意味着产生了合并的冲突, 当中具体的值所对应的意义包含: 1诠释为两位用户早前某一个共同版本下的对应文件内容, 2意为当前用户所对应的文件版本, 3表示合并之后的文件所对应的远程版本。
采用命令，即git show :n:filename这点, 去查看对应文件的对应版本的有关内容。
咱们知晓了三个版本的那个, 文件的内容之后, 就能够手动地针对冲突的文件实施手动修改这一操作。这里需要留意的是, 与之对应的冲突文件的内容已然发生了变化, 该情况之下, 里面对应的冲突区域的内容将同时存有当前分支的内容以及远程版本的内容, 就如同下面这张图所示。我们能够手动针对该文件开展修改操作, 接着在手动进行add、commit、还有push这些步骤就没问题了。
然后, 我们借助之前用于查看版本区别的命令, 进而能够看到, 对应的冲突文件已然不存在冲突了。
上面文件冲突处理时, 除借助命令git ls-files -s // git show :n:filename去解决, 可经由git内里内置的图形界面工具来开展操作, 借由命令git mergetool开启工具, 默认git给出的是kdiff3, 当中上方三个界面按从左至右顺序依次是: 那两个版本的前一个共同版本的文件版本, 当前处本地的版本所对应的文件版本, 合并之后的文件版本。
如果一个用户把某个文件进行改名操作, 另一个用户同样对该文件进行了改名, 当对这两个用户的提交做合并操作的时候, 树冲突就会出现, 这是由于git没办法替用户做出选择。下面会对树冲突展开测试并给出解决办法, 同样为保证两个用户的当前版本信息跟远程版本保持一致, 分别针对两个用户执行命令: git pull, 首先user1用户把hello.txt文件改名为user1.txt。
然后进行提交
随后, user2用户, 针对那相同的hello.txt文件, 实施改名操作, 将其改名为user2.txt。
然后进行user2用户推送后提交
接着察觉到合并之时出现了冲突, 这是源于多个用户对相同文件的文件名进行了修改, 去查看当前分支的状态。
我们能够借助命令: git ls-files -s, 去查看当下版本的冲突文件相对应的状态, 当中1所代表的是当前合并之前版本的文件所对应的文件名, 2代表的是当前分支的文件名, 3代表的是合并版本的文件名。
同样在我们知晓了这些信息之后, 便能够着手开展手动修改相关操作了。首先, 要将需要进行改名的与之对应的文件予以删除, 在这里具体而言就是把文件hello.txt给删除掉, 接着, 要么将user1.txt文件删除掉, 要么把user2.txt文件删除掉, 如此一来便能够进行提交以及上游注册了。
git合并操作存在着能够指定所使用合并策略的情况, 而那缺省状态下会去挑选最为适配的合并策略。举例进行说明, 像是处于两个分支合并的状况下, 则默认采用recursive合并策略, 还有当涉及两个以上分支合并时, 便是默认运用octpus合并策略。经传递参数, 我们可指定所运用的合并策略, 命令行模式如下: gig merge -s 合并策略, -x 合并策略参数, 后面跟着一系列内容。resolve策略: 仅能用于两个分支的合并, 此合并策略被视作最安全且最快的, 用于特定情况。recursive策略: 同样只能用于两个分支的合并, 两个分支合并时默认就采用该策略, 并且该策略还能够使用选项: ours, 即在遭遇冲突之际, 选取当前分支的版本, 而将远程合并过来的版本忽略掉。theirs选项: 与ours选项呈现相反的情况, subtree: 采用子树合并的这种策略, octpus策略: 其乃是用于对上两个以上分支予以合并的策略, 而此策略会拒绝去执行那些需要通过手动方式加以解决的复杂合并操作, ours: 它属于那种能够用于任意多个分支进行合并的策略范畴, 所合并出来的结果始终是采用当前分支的相关内容并且会舍弃掉从远程合并过来的版本内容, subtree: 此乃是一个经过调整之后的recursive策略, 关于子树合并策略的相关内容能够前往百度进行查找, 这里就不在此做出详细解释了（主要是博主本人也并不知晓~~）
经由命令git config, 能够设置跟合并相关的配置变量, 以此对合并开展那些跟合并有关的设置, 实现合并相关设置的合并。merge.conflictstyle: 此配置变量对冲突文件当中冲突内容的标记风格予以定义, 存在两种可用风格, 其一为默认的merge, 其二为diff3, 默认的merge风格借助标准的冲突分界符对冲突内容开展标识, 两个文字块, 其一为本地的修改, 其二为他人的修改, diff3风格在冲突文件里会出现三个文字块, >, 分别代表本地更改版本、共同的原始版本、他人更改的版本, merge.tool: 用以设置执行命令git mergetool开展冲突解决之际调用的图形化工具, merge..path: 用来设置对应的图形化工具的安装位置。
