java 补丁差异

如果您曾经使用分布式开发模型开发大型代码库,那么您可能已经听说过有人说“ Sue刚发送了补丁”或“ Rajiv正在检查差异”之类的事情。 也许这些术语对您来说是陌生的,您想知道它们的含义。 开源在这里产生了影响,因为从Apache Web服务器到Linux内核的大型项目的主要开发模型一直是“基于补丁”的开发项目。 实际上,您是否知道Apache的名称源自收集的补丁集,并与原始NCSA HTTPd服务器源代码进行了对照?

您可能会认为这是民间传说,但是Apache网站的早期捕获声称该名称是从原始的“补丁”集合中获得的。 因此是APA t CH y服务器,然后简化为Apache。

但是历史琐事就足够了。 开发人员谈论的这些补丁差异到底是什么?

首先,为了本文的方便,我们假设这两个术语引用的是同一件事。 “ Diff”仅是“差异”的缩写; 一个同名的Unix实用程序揭示了一个或多个文件之间的差异。 我们将在下面看一个diff实用程序示例。

“补丁”是指文件之间的差异的特定集合,这些文件可以使用Unix diff实用程序应用于源代码树。 因此,我们可以使用diff工具创建差异文件(或补丁),然后使用补丁程序工具将其应用于相同源代码的未补丁版本。 顺便说一句(并且打破了我不再历史琐事的规则),“补丁”一词来自穿Kong卡的物理覆盖,用于在早期的计算时代对软件进行更改,当时穿Kong卡代表了计算机处理器执行的程序。 下图显示在此Wikipedia页面上,描述了软件补丁,它显示了原始的“补丁”概念:




java给应用打补丁 java 补丁_java给应用打补丁


既然您对补丁和差异有所了解,那么让我们探索软件开发人员如何使用这些工具。 如果您还没有使用过像GitSubversion这样的源代码控制系统,那么我将为大多数非平凡的软件项目的开发打下基础。 如果您将软件项目的生命视为沿着时间轴的一系列操作,则可能会看到对软件的更改(例如在源代码文件中添加功能或功能或修复错误),这些更改会显示在时间轴,每个离散点代表当时所有源代码文件的状态。 我们将使用与当今最流行的源代码控制工具Git相同的命名法来将这些更改点称为“提交”。 如果您想查看某个提交前后的源代码之间的差异,或者要查看许多提交之间的差异,可以使用工具向我们显示差异或差异。

如果使用相同的源代码控制工具Git开发软件,则可能需要在本地系统中进行更改,以供其他人潜在地添加到自己的树中。 向其他人提供本地更改的一种方法是创建本地树的更改的差异,然后将此“补丁”发送给使用相同源代码的其他人。 这使其他人可以修补其树并查看应用了更改的源代码树。

Linux,Git和GitHub

这种共享补丁文件的模型是Linux内核社区针对当今提议的更改进行操作的方式。 如果你看一下档案任何流行的Linux内核邮件lists-的LKML是主要的,但其他的包括Linux的容器FS-devel的NETDEV ,仅举几例-你找到很多开发商发布补丁,他们希望让其他人进行审查,测试,并可能将其引入正式的Linux内核Git树。 更详细地讨论Linus Torvalds编写的源代码控制系统Git不在本文讨论范围之内,但值得注意的是,Git启用了这种分布式开发模型,允许修补程序与主存储库分开存在,从而推动了并引入不同的树中并遵循其特定的开发流程。

在继续之前,我们不能忽略与补丁和差异相关的最受欢迎的服务: GitHub 。 有了它的名字,您可能会猜到GitHub是基于Git的,但是它围绕Git工具提供了一个基于Web和API的工作流,用于分布式开源项目开发。 在GitHub上共享补丁的主要方式之一不是通过电子邮件(例如Linux内核),而是通过创建拉取请求 。 当您在自己的源代码树副本上提交更改时,可以通过针对该软件项目的通用共享存储库创建拉取请求来共享这些更改。 当今,GitHub被许多活跃且流行的开源项目所使用,例如KubernetesDocker容器网络接口(CNI)Istio等。 在GitHub世界中,用户倾向于使用基于Web的界面来查看构成拉取请求的差异或补丁,但是您仍然可以访问原始补丁文件,并在命令行中使用补丁实用程序来使用它们。

开始做生意

既然我们已经介绍了补丁和差异,以及它们在流行的开源社区或工具中的使用方式,那么让我们看一些示例。

第一个示例包括源树的两个副本,其中一个具有我们要使用diff实用工具可视化的更改。 在我们的示例中,我们将研究“统一”差异,因为这是大多数现代软件开发领域中补丁程序的预期视图。 查看diff手册页以获取有关选项和产生差异的方法的更多信息。 原始源代码位于sources-orig中,第二个经过修改的代码库位于名为sources-fixed的目录中。 要在终端中以统一的差异格式显示差异,请使用以下命令:

$  diff -Naur sources-orig / sources-fixed / 
$  diff -Naur sources-orig / sources-fixed /

...然后显示以下diff命令输出:

diff -Naur sources-orig/officespace/interest.go sources-fixed/officespace/interest.go
     
     

--- sources-orig/officespace/interest.go        2018-08-10 16:39:11.000000000 -0400
     
     

+++ sources-fixed/officespace/interest.go       2018-08-10 16:39:40.000000000 -0400
     
     

@@ -11,15 +11,13 @@
     
     

   InterestRate float64
     
     

 }
     
     


+// compute the rounded interest for a transaction
     
     

 func computeInterest(acct *Account, t Transaction) float64 {
     
     


   interest := t.Amount * t.InterestRate
     
     

   roundedInterest := math.Floor(interest*100) / 100.0
     
     

   remainingInterest := interest - roundedInterest
     
     


-  // a little extra..
     
     

-  remainingInterest *= 1000
     
     

-
     
     

   // Save the remaining interest into an account we control:
     
     

   acct.Balance = acct.Balance + remainingInterest

diff命令输出的前几行可以使用一些解释:三个---符号显示原始文件名; 原始文件中存在但未比较的新文件中存在的任何行都将以一个前缀作为前缀-请注意,此行是从源中“减去”的。 +++符号表示相反的+++ :比较后的新文件和在此文件中找到的附加文件用单个+符号标记,以表示它们已添加到文件的新版本中。 差异补丁文件中的每个“大块”(也就是用@@前缀的部分)都具有上下文行号,可以帮助补丁工具(或其他处理器)知道将更改应用到何处。 您可以从“ Office Space”电影参考功能中看到,我们已纠正(通过删除三行代码)我们其中一位软件开发人员的贪婪,他们对四舍五入的利息计算方法进行了补充,并对我们的功能进行了注释。

如果您希望其他人测试此树中的更改,则可以将diff的输出保存到补丁文件中:

$ diff -Naur sources-orig/ sources-fixed/ >myfixes.patch 
$ diff -Naur sources-orig/ sources-fixed/ >myfixes.patch

现在,您有了一个补丁文件myfixes.patch,可以与其他开发人员共享该补丁文件以应用和测试这组更改。 假设他们当前的工作目录位于源代码树的基础中,那么其他开发人员可以使用补丁工具来应用更改:

$ patch -p1 < ../myfixes.patch
     
     

patching file officespace/interest.go

现在,您的开发人员的源代码树已被修补,可以构建和测试通过修补程序应用的更改。 如果该开发人员单独更改了interest.go怎么办? 只要更改不会直接冲突(例如,更改相同的精确行),修补程序工具就应该能够解决将更改合并到何处。例如,在其中使用了interest.go文件和其他几个更改以下示例运行补丁:

$ patch -p1 < ../myfixes.patch
     
     

patching file officespace/interest.go
     
     

Hunk #1 succeeded at 26 (offset 15 lines).

在这种情况下,补丁程序警告说更改不适用于文件的原始位置,但会偏移15行。 如果文件有大量更改,修补程序可能会放弃尝试查找更改的位置,但是它确实提供了选项(带有文档中的必要警告)以提高匹配的“模糊性”(这不在本文讨论范围之内) 。

如果您使用的是Git和/或GitHub,则可能不会将diff或补丁工具用作独立工具。 Git提供了许多此功能,因此您可以使用内置功能来处理共享源树并合并和提取其他开发人员的更改。 一种类似的功能是使用git diff在本地树中或任何两个引用(提交标识符,标记或分支的名称,等等)之间提供统一的diff输出。 您甚至可以创建一个不使用Git的补丁文件,只需将git diff输出管道到文件即可,只要它使用了补丁可以使用的diff命令的确切格式,就可以发现它有用。 当然,GitHub将这些功能带入了基于Web的用户界面中,因此您可以根据请求请求查看文件更改。 在此视图中,您会注意到它实际上是Web浏览器中的统一差异视图,并且GitHub允许您将这些更改下载为原始补丁文件。

摘要

您已经了解了什么是diff和补丁,以及与之交互的常见Unix / Linux命令行工具。 除非您是仍使用基于补丁文件的开发方法(例如Linux内核)的项目的开发人员,否则您将主要通过诸如Git的源代码控制系统来使用这些功能。 但是,通过GitHub之类的高级工具了解许多开发人员每天使用的功能的背景和基础很有帮助。 谁知道呢?有一天,当您需要使用Linux世界中邮件列表中的补丁程序时,它们可能会派上用场。

翻译自: https://opensource.com/article/18/8/diffs-patches

java 补丁差异