如果你想找人来测试你的代码改动,你可以将差异保存到一个补丁里:
$ diff -Naur sources-orig/ sources-fixed/ >myfixes.patch
现在你有补丁 myfixes.patch 了,你能把它分享给别的开发者,他们可以将这个补丁打在他们自己的源代码树上从而得到和你一样的代码并测试他们。如果一个开发者的当前工作目录就是他的源代码树的根的话,他可以用下面的命令来打补丁:
$ patch -p1 < ../myfixes.patch patching file officespace/interest.go
现在这个开发者的源代码树已经打好补丁并准备好构建和测试文件的修改了。那么如果这个开发者在打补丁之前已经改动过了怎么办?只要这些改动没有直接冲突(LCTT 译注:比如改在同一行上),补丁工具就能自动的合并代码的改动。例如下面的interest.go 文件,它有其它几处改动,然后它想打上 myfixes.patch 这个补丁:
$ patch -p1 < ../myfixes.patch patching file officespace/interest.go Hunk #1 succeeded at 26 (offset 15 lines).
在这个例子中,补丁警告说代码改动并不在文件原来的地方而是偏移了 15 行。如果你文件改动的很厉害,补丁可能干脆说找不到要应用的地方,还好补丁程序提供了提供了打开“模糊”匹配的选项(这个选项在文档里有预置的警告信息,对其讲解已经超出了本文的范围)。
如果你使用 Git 或者 GitHub 的话,你可能不会直接使用补丁或差异。Git 已经内置了这些功能,你能使用这些功能和共享一个源代码树的其他开发者交互,拉取或合并代码。Git 一个比较相近的功能是可以使用 git diff 来对你的本地代码树生成全局差异,又或者对你的任意两次”引用“(可能是一个代表提交的数字,或一个标记或分支的名字,等等)做全局补丁。你甚至能简单的用管道将 git diff 的输出到一个文件里(这个文件必须严格符合将要被使用它的程序的输入要求),然后将这个文件交给一个并不使用 Git 的开发者应用到他的代码上。当然,GitHub 把这些功能放到了 Web 上,你能直接在 Web 页面上查看一个拉取请求的文件变动。在 Web 上你能看到所展示的合并差异,GitHub 还允许你将这些代码改动下载为原始的补丁文件。
总结 (编辑:西安站长网)
【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!
|