linux/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst

125 lines
8.4 KiB
ReStructuredText
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

.. include:: ../disclaimer-zh_CN.rst
:Original: :ref:`Documentation/process/7.AdvancedTopics.rst <development_advancedtopics>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
.. _cn_development_advancedtopics:
高级主题
========
现在,希望您能够掌握开发流程的工作方式。然而,还有更多的东西要学!本节将介绍
一些主题这些主题对希望成为Linux内核开发过程常规部分的开发人员有帮助。
使用Git管理补丁
---------------
内核使用分布式版本控制始于2002年初当时Linus首次开始使用专有的Bitkeeper应用
程序。虽然bitkeeper存在争议但它所体现的软件版本管理方法却肯定不是。分布式
版本控制可以立即加速内核开发项目。在当前的时代,有几种免费的比特保持器替代品。
无论好坏内核项目都将Git作为其选择的工具。
使用Git管理补丁可以使开发人员的生活更加轻松尤其是随着补丁数量的增加。Git
也有其粗糙的边缘和一定的危险,它是一个年轻和强大的工具,仍然在其开发人员完善
中。本文档不会试图教会读者如何使用git这会是个巨长的文档。相反这里的重点
将是Git如何特别适合内核开发过程。想要加快Git的开发人员可以在以下网站上找到
更多信息:
http://git-scm.com/
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
在尝试使用它使补丁可供其他人使用之前第一要务是阅读上述站点对Git的工作
方式有一个扎实的了解。使用Git的开发人员应该能够获得主线存储库的副本探索
修订历史提交对树的更改使用分支等。了解Git用于重写历史的工具如Rebase
也很有用。Git有自己的术语和概念Git的新用户应该了解refs、远程分支、索引、
快进合并、推拉、分离头等。一开始可能有点吓人,但这些概念不难通过一点学习来
理解。
使用git生成通过电子邮件提交的补丁是提高速度的一个很好的练习。
当您准备好开始安装Git树供其他人查看时您当然需要一个可以从中提取的服务器。
如果您有一个可以访问Internet的系统那么使用git守护进程设置这样的服务器相
对简单。否则免费的公共托管网站例如github开始出现在网络上。成熟的开发
人员可以在kernel.org上获得一个帐户但这些帐户并不容易找到有关更多信息
请参阅 http://kernel.org/faq/
正常的Git工作流程涉及到许多分支的使用。每一条开发线都可以分为单独的“主题
分支”并独立维护。Git的分支机构很便宜没有理由不免费使用它们。而且
任何情况下,您都不应该在任何您打算让其他人从中受益的分支中进行开发。应该
小心地创建公开可用的分支;当它们处于完整的形式并准备好运行时(而不是之前),
合并开发分支的补丁。
Git提供了一些强大的工具可以让您重写开发历史。一个不方便的补丁比如说
一个打破二分法的补丁,或者有其他一些明显的缺陷)可以在适当的位置修复,或者
完全从历史中消失。一个补丁系列可以被重写,就好像它是在今天的主线之上写的
一样,即使你已经花了几个月的时间在写它。可以透明地将更改从一个分支转移到另
一个分支。等等。明智地使用git修改历史的能力可以帮助创建问题更少的干净补丁集。
然而,过度使用这种能力可能会导致其他问题,而不仅仅是对创建完美项目历史的
简单痴迷。重写历史将重写该历史中包含的更改,将经过测试(希望)的内核树变
为未经测试的内核树。但是,除此之外,如果开发人员没有对项目历史的共享视图,
他们就无法轻松地协作;如果您重写了其他开发人员拉入他们存储库的历史,您将
使这些开发人员的生活更加困难。因此,这里有一个简单的经验法则:被导出到其他
人的历史在此后通常被认为是不可变的。
因此,一旦将一组更改推送到公开可用的服务器上,就不应该重写这些更改。如果您
尝试强制进行不会导致快进合并即不共享同一历史记录的更改的更改Git将尝
试强制执行此规则。可以重写此检查,有时可能需要重写导出的树。在树之间移动变
更集以避免Linux-next中的冲突就是一个例子。但这种行为应该是罕见的。这就是为
什么开发应该在私有分支中进行(必要时可以重写)并且只有在公共分支处于合理的
高级状态时才转移到公共分支中的原因之一。
当主线(或其他一组变更所基于的树)前进时,很容易与该树合并以保持领先地位。
对于一个私有的分支rebasing 可能是一个很容易跟上另一棵树的方法,但是一旦
一棵树被导出到全世界rebasing就不是一个选项。一旦发生这种情况就必须进行
完全合并merge。合并有时是很有意义的但是过于频繁的合并会不必要地扰乱
历史。在这种情况下,建议的技术是不经常合并,通常只在特定的发布点(如主线-rc
发布)合并。如果您对特定的更改感到紧张,则可以始终在私有分支中执行测试合并。
在这种情况下git rerere 工具很有用;它记住合并冲突是如何解决的,这样您就
不必重复相同的工作。
关于Git这样的工具的一个最大的反复抱怨是补丁从一个存储库到另一个存储库的
大量移动使得很容易陷入错误建议的变更中,这些变更避开审查雷达进入主线。当内
核开发人员看到这种情况发生时他们往往会感到不高兴在Git树上放置未查看或
主题外的补丁可能会影响您将来获取树的能力。引用Linus:
::
你可以给我发补丁但要我从你哪里取一个Git补丁我需要知道你知道
你在做什么,我需要能够相信事情而不去检查每个个人改变。
http://lwn.net/articles/224135/)。
为了避免这种情况,请确保给定分支中的所有补丁都与相关主题紧密相关;“驱动程序
修复”分支不应更改核心内存管理代码。而且最重要的是不要使用Git树来绕过
审查过程。不时的将树的摘要发布到相关的列表中,当时间合适时,请求
Linux-next 中包含该树。
如果其他人开始发送补丁以包含到您的树中,不要忘记查看它们。还要确保您维护正确
的作者信息; ``git am`` 工具在这方面做得最好,但是如果它通过第三方转发给您,
您可能需要在补丁中添加“From”行。
请求pull操作时请务必提供所有相关信息树的位置、要拉的分支以及拉操作将导致
的更改。在这方面git request pull 命令非常有用;它将按照其他开发人员的预期
格式化请求,并检查以确保您记住了将这些更改推送到公共服务器。
审查补丁
--------
一些读者当然会反对将本节与“高级主题”放在一起,因为即使是刚开始的内核开发人员
也应该检查补丁。当然,学习如何在内核环境中编程没有比查看其他人发布的代码更好
的方法了。此外,审阅者永远供不应求;通过查看代码,您可以对整个流程做出重大贡献。
审查代码可能是一个令人生畏的前景,特别是对于一个新的内核开发人员来说,他们
可能会对公开询问代码感到紧张,而这些代码是由那些有更多经验的人发布的。不过,
即使是最有经验的开发人员编写的代码也可以得到改进。也许对评审员(所有评审员)
最好的建议是:把评审评论当成问题而不是批评。询问“在这条路径中如何释放锁?”
总是比说“这里的锁是错误的”更好。
不同的开发人员将从不同的角度审查代码。一些主要关注的是编码样式以及代码行是
否有尾随空格。其他人将主要关注补丁作为一个整体实现的变更是否对内核有好处。
然而,其他人会检查是否存在锁定问题、堆栈使用过度、可能的安全问题、在其他
地方发现的代码重复、足够的文档、对性能的不利影响、用户空间ABI更改等。所有
类型的检查,如果它们导致更好的代码进入内核,都是受欢迎和值得的。