CN106933591A - 代码合并的方法及装置 - Google Patents

Abstract

本发明公开了一种代码合并的方法及装置，涉及数据处理技术领域，解决了现有的代码合并效率低的问题。本发明的方法包括：获取待修改的代码库对应的补丁文件；在所述待修改的代码库中查找与所述补丁文件对应的目录文件；按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并，得到修改后的代码库。本发明应用于大量代码合并的过程中。

Description

代码合并的方法及装置

技术领域

本发明涉及数据处理技术领域，尤其涉及一种代码合并的方法及装置。

背景技术

在安卓Android项目开发中，经常会遇到Android平台升级或其他代码合并的场景。对于上述的场景，通常是需要将补丁文件与待修改的代码库进行合并，比如对于Android平台的升级，当由低的版本升级到更高的版本后，需要将之前在该平台上进行的修改的代码迁移到新的版本中。目前，常用的做法是工程师重新在高的版本对应的新代码库中修改，具体是将一个一个补丁patch(修改的代码文件)合并到新的代码库中完成代码的迁移，具体的合并的流程为通过输入代码命令获取补丁文件，再通过输入代码命令进行代码的合并，并且每一个补丁文件都需要重复上述过程，但是当补丁很多的情况下，需要重复的输入代码命令执行非常的浪费时间和人力。

发明内容

鉴于上述问题，本发明提供一种代码合并的方法及装置，用以解决现有的代码合并效率低的问题。

为解决上述技术问题，第一方面，本发明提供了一种代码合并的方法，所述方法包括：

获取待修改的代码库对应的补丁文件；

在所述待修改的代码库中查找与所述补丁文件对应的目录文件；

按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并，得到修改后的代码库。

第二方面，本发明提供了一种代码合并的装置，所述装置包括：

获取单元，用于获取待修改的代码库对应的补丁文件；

第一查找单元，用于在所述待修改的代码库中查找与所述补丁文件对应的目录文件；

合并单元，用于按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并，得到修改后的代码库。

借由上述技术方案，本发明提供的代码合并的方法及装置，通过一个脚本程序自动实现获取补丁文件以及将对应的补丁文件合并到待修改的代码库中的过程，不需要重复的输入代码命令进行补丁的获取和合并，节省了时间和人力。而且自动化的实现代码合并的方式中完全按照补丁文件的提交的时序进行合并，可以避免人工操作过程中的补丁遗漏以及补丁顺序错乱的问题，提高了代码合并的效率。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提供的一种代码合并的方法的流程图；

图2示出了本发明实施例提供的另一种代码合并的方法的流程图；

图3示出了本发明实施例提供的一种代码合并的装置的组成框图；

图4示出了本发明实施例提供的另一种代码合并的装置的组成框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为解决现有的代码合并效率低的问题，本发明实施例提供了一种代码合并的方法，如图1所示，该方法包括：

101、获取待修改的代码库对应的补丁文件。

在获取待修改的代码库对应的补丁文件之前首先需要获取待修改的代码库。通常待修改的代码库是由代码管理服务器存储和管理的，常用的代码管理服务器有Gerrit服务器、Subversion(SVN)服务器等。代码管理服务器中存储有不同的代码库，当需要在某一代码库基础上进行开发或者修改时，该代码库就作为待修改的代码库，对应的对待修改的代码库进行修改的文件为对应的补丁文件patch。补丁文件与待修改的代码库存在对应关系，因此可以通过待修改的代码库获取到对应的补丁文件，补丁文件通常也存储在代码管理服务器上。

另外，需要说明的是，实际应用中待修改的代码库以及对应的补丁文件也可能有其他的存储路径，这时需要根据具体的存储路径来获取对应的待修改的代码库以及对应的补丁文件。

102、在待修改的代码库中查找与补丁文件对应的目录文件。

一个待修改的代码库中包含不同的目录文件，补丁文件是针对不同的目录下的文件进行的修改，因此需要在待修改的代码库中查找与补丁文件对应的目录文件。需要说明的是，这里的修改包括对目录文件中原有的代码进行改动，也包括在目录文件下添加新的代码文件。具体关于查找对应的目录文件的方式为：从不同补丁文件的文件名标识中查找对应的目录文件的标识，然后根据查找到的目录文件的标识查找到对应补丁文件的目录文件。

103、按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并，得到修改后的代码库。

需要说明的是，大多数的补丁文件是有顺序的，因为一个补丁文件的产生，有可能是在其他的一个或几个补丁文件的基础上修改得到的，因此为了保证最终代码逻辑的正确性，必须按照代码修改的顺序进行合并，即按照补丁文件的提交时间顺序，先合并提交时间在前的补丁文件，每合并一个补丁文件后，在合并后的文件基础上继续按照提交时间的先后顺序合并下一个补丁文件，最终将所有的补丁文件合并到待修改的代码库中后，完成对待修改代码库的修改，得到修改后的代码库。具体代码合并时，通常是调用代码合并工具自动合并的。

对于上述代码合并的方法流程中，还需要说明的是，对于步骤101中获取待修改的代码库的补丁文件时，可以一次性获取所有的补丁文件，也可以分批获取，比如按照补丁文件的提交时间的顺序分批获取。但是无论按照什么样的方式获取，必须保证步骤102中的合并顺序是按时间顺序进行的。

本发明提供的代码合并的方法，通过一个脚本程序自动实现获取补丁文件以及将对应的补丁文件合并到待修改的代码库中的过程，不需要重复的输入代码命令进行补丁的获取和合并，节省了时间和人力。而且自动化的实现代码合并的方式中完全按照补丁文件的提交的时序进行合并，可以避免人工操作过程中的补丁遗漏以及补丁顺序错乱的问题，提高了代码合并的效率。

另外，上述代码合并的方法是完全按照补丁文件的提交时间顺序进行自动化合并的，因此可以避免人工合并时发生的补丁文件的遗漏以及历史错乱的现象。

对图1所示方法的细化及扩展，本发明实施例还提供了一种代码合并的方法，如图2所示：

201、获取待修改的代码库对应的补丁文件。

该步骤的实现方式与图1步骤101中的实现方式相同，此处不再赘述。需要说明的是，本步骤中获取的补丁文件包括待修改的代码库的所有的补丁文件。

202、将待修改的代码库中的目录文件进行分类。

通常对目录文件进行分类时，是按照不同的功能进行分类的，不同的功能之间的目录文件是指彼此之间没有相互的制约和关联性，即一个功能对应的目录文件中包含的补丁文件并不是基于其他某一个或几个功能对应的目录文件中的代码进行的修改。

203、查找不同类型的目录文件对应的补丁文件。

在由步骤201获取的所有补丁文件中，查找不同类型的目录文件对应的补丁文件。具体的查找方式为：在补丁文件的文件标识中查找对应的目录文件的标识，然后根据目录文件的标识查找到对应补丁文件的目录文件。

204、在不同类型的目录文件中按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并。

由于不同类型的目录文件之间彼此之间没有相互的制约和关联性，因此在每个类型的目录文件内部可以分别按照各自对应的补丁文件的提交时间的顺序进行代码的合并，具体是按照提交时间的先后顺序进行合并的，即先合并提交时间在前的补丁文件，后合并提交时间在后的补丁文件。

具体的在进行代码的合并时，是通过调用代码合并工具进行的，常用的代码合并合并工具包括Git、Subversion(SVN)等。本实施例中以调用Git工具进行代码的合并。具体的是通过调用Git接口实现的，在Git中实现代码合并功能的有两种方式，一种是git merge方式，另一种是git rebase方式。git merge方式在进行代码合并时是一下子处理多个补丁文件的合并，到最后再一并的处理所有出现的冲突；而git rebase方式在进行代码合并时是出现一个合并冲突就解决一个合并冲突，处理之后继续进行下一个补丁文件的处理。两种代码合并方式有所区别，因此也分别对应不同的使用情境。通常对于冲突较多的目录文件，会选择git rebase方式进行合并，通常对于冲突较少的目录文件，会选择git merge方式进行合并。而冲突的多少通常与目录文件对应的补丁文件的多少成正比关系，补丁文件越多，通常对目录文件的修改越多，在合并代码的过程存在的冲突也会较多。因此，在进行代码合并之前，首先需要判断需要进行代码合并的目录文件对应的补丁文件的数量是否超过预设阈值；若超过预设阈值，则调用代码合并方式git rebase方式对该目录文件以及对应的补丁文件进行代码的合并；若未超过预设阈值，则调用代码合并方式git merge方式对该目录文件以及对应的补丁文件进行代码的合并。其中预设阈值可以根据实际需求自由设定。

另外，在选择git merge方式或者git rebase方式进行代码合并时，也可以根据实际经验，去判断对哪些目录文件通常会修改较大，对哪些目录文件通常修改较少。比如在Android平台升级时，需要将代码迁移到新的平台的代码库中时，对于Frameworks库文件，通常的修改较大，就可以选择git rebase方式；对于编译库文件，通常有较少的修改，因此可以选择git merge方式。

205、实时监控代码合并的进程。

因为在代码合并的过程中，通常会遇到合并冲突，当出现合并冲突时，需要进行冲突的解决，以使继续进行代码的合并。因此在代码合并的过程中，需要实时监控代码合并的进程，获取代码合并是否成功以及到目前为止已经合并的补丁文件占总的补丁文件的百分比。

206、当监测到代码合并冲突时，输出冲突提示框。

使用代码合并工具进行代码合并时，当监测到有合并冲突时，输出冲突提示框，以使工程师手动进行冲突的解决。冲突提示框中至少包含了出现合并冲突对应的代码文件。另外，对于合并冲突的提示，也可以通过除提示框之外的其他形式进行展示，本实施例对冲突提示的展示形式不作限制。

需要说明的是，对于不同的代码合并方式git merge方式和git rebase方式，每次检测到的合并冲突的数量是不同，对于git merge方式通常监测到的是多个合并冲突，而git rebase方式每次监测到的合并冲突通常为一个。

207、当冲突解决后，继续执行代码的合并。

接收到冲突解决的确认消息后，确定冲突已经解决，则继续执行代码的合并，直到所有的补丁文件被合并完毕，得到修改后的代码库。

另外，对于上述步骤203中获取不同类型目录文件对应的补丁文件时，可以直接从代码管理服务器上获取，而不是从由步骤201获取到的全部补丁文件中查找获取。在这种情况下，就可以省去步骤201。

进一步的，作为对上述各实施例的实现，本发明实施例的另一实施例还提供了一种代码合并的装置，用于实现上述图1以及图2所述的方法。如图3所示，该装置包括：获取单元31、第一查找单元32以及合并单元33。

获取单元31，用于获取待修改的代码库对应的补丁文件；

在获取待修改的代码库对应的补丁文件之前首先需要获取待修改的代码库。通常待修改的代码库是由代码管理服务器存储和管理的，常用的代码管理服务器有Gerrit服务器、Subversion(SVN)服务器等。代码管理服务器中存储有不同的代码库，当需要在某一代码库基础上进行开发或者修改时，该代码库就作为待修改的代码库，对应的对待修改的代码库进行修改的文件为对应的补丁文件patch。补丁文件与待修改的代码库存在对应关系，因此可以通过待修改的代码库获取到对应的补丁文件，补丁文件通常也存储在代码管理服务器上。

另外，需要说明的是，实际应用中待修改的代码库以及对应的补丁文件也可能有其他的存储路径，这时需要根据具体的存储路径来获取对应的待修改的代码库以及对应的补丁文件。

第一查找单元32，用于在待修改的代码库中查找与补丁文件对应的目录文件；

一个待修改的代码库中包含不同的目录文件，补丁文件是针对不同的目录下的文件进行的修改，因此需要在待修改的代码库中查找与补丁文件对应的目录文件。需要说明的是，这里的修改包括对目录文件中原有的代码进行改动，也包括在目录文件下添加新的代码文件。具体关于查找对应的目录文件的方式为：从不同补丁文件的文件名标识中查找对应的目录文件的标识，然后根据查找到的目录文件的标识查找到对应补丁文件的目录文件。

合并单元33，用于按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并，得到修改后的代码库。

需要说明的是，大多数的补丁文件是有顺序的，因为一个补丁文件的产生，有可能是在其他的一个或几个补丁文件的基础上修改得到的，因此为了保证最终代码逻辑的正确性，必须按照代码修改的顺序进行合并，即按照补丁文件的提交时间顺序，先合并提交时间在前的补丁文件，每合并一个补丁文件后，在合并后的文件基础上继续按照提交时间的先后顺序合并下一个补丁文件，最终将所有的补丁文件合并到待修改的代码库中后，完成对待修改代码库的修改，得到修改后的代码库。

合并单元33，还用于：

调用代码合并工具按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并。

常用的代码合并合并工具包括Git、Subversion(SVN)等。

如图4所示，合并单元33，包括：

判断模块331，用于代码合并工具为Git，判断目录文件对应的补丁文件的数量是否超过预设阈值；

第一合并模块332，用于若超过预设阈值，则调用代码合并方式git rebase方式进行代码的合并；

第二合并模块333，用于若未超过预设阈值，则调用代码合并方式git merge方式进行代码的合并。

在Git中实现代码合并功能的有两种方式，一种是git merge方式，另一种是gitrebase方式。git merge方式在进行代码合并时是一下子处理多个补丁文件的合并，到最后再一并的处理所有出现的冲突；而git rebase方式在进行代码合并时是出现一个合并冲突就解决一个合并冲突，处理之后继续进行下一个补丁文件的处理。两种代码合并方式有所区别，因此也分别对应不同的使用情境。通常对于冲突较多的目录文件，会选择git rebase方式进行合并，通常对于冲突较少的目录文件，会选择git merge方式进行合并。而冲突的多少通常与目录文件对应的补丁文件的多少成正比关系，补丁文件越多，通常对目录文件的修改越多，在合并代码的过程存在的冲突也会较多。因此，在进行代码合并之前，首先需要判断需要进行代码合并的目录文件对应的补丁文件的数量是否超过预设阈值；若超过预设阈值，则调用代码合并方式git rebase方式对该目录文件以及对应的补丁文件进行代码的合并；若未超过预设阈值，则调用代码合并方式git merge方式对该目录文件以及对应的补丁文件进行代码的合并。其中预设阈值可以根据实际需求自由设定。

另外，在选择git merge方式或者git rebase方式进行代码合并时，也可以根据实际经验，去判断对哪些目录文件通常会修改较大，对哪些目录文件通常修改较少。比如在Android平台升级时，需要将代码迁移到新的平台的代码库中时，对于Frameworks库文件，通常的修改较大，就可以选择git rebase方式；对于编译库文件，通常有较少的修改，因此可以选择git merge方式。

如图4所示，装置还包括：

监控单元34，用于实时监控代码合并的进程；

输出单元35，用于当监测到代码合并冲突时，输出冲突提示框；

使用代码合并工具进行代码合并时，当监测到有合并冲突时，输出冲突提示框，以使工程师手动进行冲突的解决。冲突提示框中至少包含了出现合并冲突对应的代码文件。另外，对于合并冲突的提示，也可以通过除提示框之外的其他形式进行展示，本实施例对冲突提示的展示形式不作限制。

需要说明的是，对于不同的代码合并方式git merge方式和git rebase方式，每次检测到的合并冲突的数量是不同，对于git merge方式通常监测到的是多个合并冲突，而git rebase方式每次监测到的合并冲突通常为一个。

继续合并单元36，用于当冲突解决后，继续执行代码的合并。

接收到冲突解决的确认消息后，确定冲突已经解决，则继续执行代码的合并，直到所有的补丁文件被合并完毕，得到修改后的代码库。

如图4所示，装置还包括：

分类单元37，用于在调用代码合并工具按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并之前，将目录文件进行分类；

通常对目录文件进行分类时，是按照不同的功能进行分类的，不同的功能之间的目录文件是指彼此之间没有相互的制约和关联性，即一个功能对应的目录文件中包含的补丁文件并不是基于其他某一个或几个功能对应的目录文件中的代码进行的修改。

第二查找单元38，用于查找不同类型的目录文件对应的补丁文件；

具体的查找方式为：在补丁文件的文件标识中查找对应的目录文件的标识，然后根据目录文件的标识查找到对应补丁文件的目录文件。

合并单元33，还用于在不同类型的目录文件中按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并。

由于不同类型的目录文件之间彼此之间没有相互的制约和关联性，因此在每个类型的目录文件内部可以分别按照各自对应的补丁文件的提交时间的顺序进行代码的合并，具体是按照提交时间的先后顺序进行合并的，即先合并提交时间在前的补丁文件，后合并提交时间在后的补丁文件。

本发明提供的代码合并的装置，通过一个脚本程序自动实现获取补丁文件以及将对应的补丁文件合并到待修改的代码库中的过程，不需要重复的输入代码命令进行补丁的获取和合并，节省了时间和人力。而且自动化的实现代码合并的方式中完全按照补丁文件的提交的时序进行合并，可以避免人工操作过程中的补丁遗漏以及补丁顺序错乱的问题，提高了代码合并的效率。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟***或者其它设备固有相关。各种通用***也可以与基于在此的示教一起使用。根据上面的描述，构造这类***所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的发明名称(如代码合并的装置)中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (10)

1.一种代码合并的方法，其特征在于，包括：

获取待修改的代码库对应的补丁文件；

在所述待修改的代码库中查找与所述补丁文件对应的目录文件；

按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并，得到修改后的代码库。

2.根据权利要求1所述的方法，其特征在于，所述按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并包括：

调用代码合并工具按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并。

3.根据权利要求1或2所述的方法，其特征在于，所述代码合并工具为Git，所述调用代码合并工具按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并，包括：

判断目录文件对应的补丁文件的数量是否超过预设阈值；

若超过预设阈值，则调用代码合并方式git rebase方式进行代码的合并；

若未超过预设阈值，则调用代码合并方式git merge方式进行代码的合并。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

实时监控代码合并的进程；

当监测到代码合并冲突时，输出冲突提示框；

当冲突解决后，继续执行代码的合并。

5.根据权利要求1或2所述的方法，其特征在于，在调用代码合并工具按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并之前，所述方法还包括：

将目录文件进行分类；

查找不同类型的目录文件对应的补丁文件；

在不同类型的目录文件中按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并。

6.一种代码合并的装置，其特征在于，包括：

获取单元，用于获取待修改的代码库对应的补丁文件；

第一查找单元，用于在所述待修改的代码库中查找与所述补丁文件对应的目录文件；

合并单元，用于按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并，得到修改后的代码库。

7.根据权利要求6所述的装置，其特征在于，所述合并单元，还用于：

调用代码合并工具按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并。

8.根据权利要求6或7所述的装置，其特征在于，所述合并单元，包括：

判断模块，用于所述代码合并工具为Git，判断目录文件对应的补丁文件的数量是否超过预设阈值；

第一合并模块，用于若超过预设阈值，则调用代码合并方式git rebase方式进行代码的合并；

第二合并模块，用于若未超过预设阈值，则调用代码合并方式git merge方式进行代码的合并。

9.根据权利要求8所述的装置，其特征在于，所述装置还包括：

监控单元，用于实时监控代码合并的进程；

输出单元，用于当监测到代码合并冲突时，输出冲突提示框；

继续合并单元，用于当冲突解决后，继续执行代码的合并。

10.根据权利要求6或7所述的装置，其特征在于，所述装置还包括：

分类单元，用于在调用代码合并工具按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并之前，将目录文件进行分类；

第二查找单元，用于查找不同类型的目录文件对应的补丁文件；

所述合并单元，还用于在不同类型的目录文件中按照补丁文件的提交时间顺序将补丁文件中的代码与对应的目录文件中的代码进行合并。