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