基于git源代码冲突的文件合并方法及系统的制作方法
【技术领域】
[0001]本发明涉及文件编辑领域，尤其是涉及一种基于git源代码冲突的文件合并方法及系统。
【背景技术】
[0002]目前，当有多人同时对源代码项目文件进行修改时，经常会由于不同的修改方式，以产生不同的新增文件，导致项目文件同一行新增不同内容。这回直接导致合并工具无法自动合并修改后的新增文件。
[0003]现有专利(申请号:201210390805.2)公开了一种网络同步方法和装置，所述方法包括步骤:监控客户端计算机中的源文件目录，收集源文件目录中发生的变化事件；根据所述变化事件发生的时间顺序，获得初始变化事件序列；根据预设规则，将所述初始变化事件序列中的冗余事件进行合并，生成有效变化事件序列；根据所述有效变化事件序列，向云端存储服务器发送同步请求。该专利基于网络对源文件进行合并，同时针对时间的先后顺序实现有序合并，以凸显时序上的差异。但仍没有对一个文件中涉及到的同一位置中出现的新增行的合并。
【发明内容】
[0004]本发明所要解决的技术问题是:
[0005]为了解决上述技术问题，本发明采用的技术方案为:提供一种基于git源代码冲突的文件合并方法，包括如下步骤:
[0006]S1:分别获取对第一文件的修改信息，以生成第二文件及第三文件；
[0007]S2:合并上述三份文件，生成冲突文件；
[0008]S3:参照第一文件，检测所述冲突文件中的新增行，并删除合并标记；
[0009]S4:对所述冲突文件进行编译检查，获得第四文件。
[0010]为了解决上述技术问题，本发明提供一种基于git源代码冲突的文件合并系统，包括:
[0011]修改模块，用于分别获取对第一文件的修改信息，以生成第二文件及第三文件；
[0012]合并模块，用于合并上述三份文件，生成冲突文件；
[0013]删除模块，用于参照第一文件，检测所述冲突文件中的新增行，并删除合并标记；
[0014]结果模块，用于对所述冲突文件进行编译检查，获得第四文件。
[0015]本发明的有益效果在于:区别于现有技术，本发明通过编译检查进行修改文件的自动合并，可以避免在源代码项目配置文件中由于新增文件导致的冲突。可操作性强。
【附图说明】
[0016]图1为本发明方法实施例一的流程示意图；
[0017]图2为本发明方法实施例二的流程示意图；
[0018]图3为本发明的具体实施例的参考图；
[0019]图4为本发明系统实施例三的结构框图；
[0020]图5为本发明系统实施例四的结构框图。
【具体实施方式】
[0021]为详细说明本发明的技术内容、所实现目的及效果，以下结合实施方式并配合附图予以说明。
[0022]本发明最关键的构思在于:通过编译检查代码，实现自动合并。
[0023]请参照图1，本发明实施例一提供一种基于git源代码冲突的文件合并方法，包括如下步骤:
[0024]S1:分别获取对第一文件的修改信息，以生成第二文件及第三文件；
[0025]S2:合并上述三份文件，生成冲突文件；
[0026]S3:参照第一文件，检测所述冲突文件中的新增行，并删除合并标记；
[0027]S4:对所述冲突文件进行编译检查，获得第四文件。
[0028]区别于现有技术，本发明通过编译检查进行修改文件的自动合并，可以避免在源代码项目配置文件中由于新增文件导致的冲突，且可操作性强。
[0029]如图2所示，在实施例一的基础上，本发明实施例二中步骤S2具体为:
[0030]S21:参照第一文件，分别逐行比较第二文件与第三文件，检测出新增行；
[0031]S22:使用合并工具将第二文件及第三文件中的新增行合并到第一文件的对应位置中，生成冲突文件。
[0032]其中，步骤S3具体为:
[0033]S31:参照第一文件，分别逐行检测冲突文件中的新增行，以定位合并标记；
[0034]S32:删除冲突文件的合并标记。
[0035]其中，步骤S4具体为:
[0036]S41:调用编译命令对所述冲突文件进行编译检查；
[0037]S42:判断编译检查是否通过；
[0038]若是，则执行S43:确认合并成功，标记所述冲突文件为第四文件；
[0039]反之，则执行S44:确认合并失败；并返回执行步骤SI。
[0040]区别于现有技术，本发明参照第一文件，在生成的冲突文件中一一比对新增行，在合并的时候，将对应的新增行添加到第一文件对应的位置。若出现同样的新增行，两个文件的新增内容不完全相同，则会出现标记，如下例子所示。这里，没有比对周期，只是触发合并代码，自动合并。在这种情况下，有可能出现合并无法进行，因此需要定位到标记后，将其删除，最后使用编译器对代码进行编译检查，若检查通过，则表示合并正确。因此采用这种方式可以避免在源代码项目配置文件中由于新增文件导致的冲突，实际可操作性强。
[0041]举个例子，如图3所示，在一个具体的实施例中，可选择版本I文件作为原始文件，即第一文件，版本2文件、版本3文件都是对应在版本I文件上所做的修改，即第二文件及第三文件。版本2文件及版本3文件都是在版本I的对应位置出现新增行，分别是“〈item〉/文件l〈/item>”、“〈item>/文件2〈/item>”在通过合并工具，如例子所示的git merge命令合并成临时文件3(即冲突文件)。这里，应当理解的是，合并工具可以是除了 git自带的git merge命令外，还可以是一些文件的比对工具，例如Araxis Merge等。
[0042]在生成临时文件3后，由于新增行内容不完全相同，因此出现了合并标记:“〈〈〈〈〈〈〈HEAD” 和“= = = = = = =”和 “>>>>>>>master”，参照图 3 所示，版本 2 文件、版本3文件分列与版本I文件的左右侧，因此出现的〈〈〈〈〈〈〈及 >>>>>>> 符号标记，这些是用于与版本I文件的名称进行区分定位。其中的HEAD或master是版本2文件及版本3文件的文件名。“ = = = = = = = ”是两个不同内容新增行的分隔符。
[0043]当计算机检测到上述含有合并标记格式的行时，可自动删除合并标记，则最后生成合并的文件，即第四文件。具体地，可使用微软的编译工具进行编译检查，如对最终合并文件MyApp.csproj进行编译检查。可使用编译脚本MSBuildMyApp.csproj/t:Clean/P:Configurat1n = Debug ；/p:Platform = x86 ；TargetFrameworkVers1n = v3.50 如果执行编译脚本成功，则表示合并正确，否则表示合并失败。