.. include:: ../disclaimer-zh_CN.rst
:Original: :ref:`Documentation/process/7.AdvancedTopics.rst <development_advancedtopics>`
-:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+
+:Translator:
+
+ 时奎亮 Alex Shi <alex.shi@linux.alibaba.com>
+
+:校译:
+
+ 吴想成 Wu XiangCheng <bobwxc@email.cn>
.. _cn_development_advancedtopics:
---------------
内核使用分布式版本控制始于2002年初，当时Linus首次开始使用专有的Bitkeeper应用
-程序。虽然bitkeeper存在争议，但它所体现的软件版本管理方法却肯定不是。分布式
-版本控制可以立即加速内核开发项目。在当前的时代，有几种免费的比特保持器替代品。
-无论好坏，内核项目都将Git作为其选择的工具。
+程序。虽然BitKeeper存在争议，但它所体现的软件版本管理方法却肯定不是。分布式
+版本控制可以立即加速内核开发项目。现在有好几种免费的BitKeeper替代品。
+但无论好坏，内核项目都已经选择了Git作为其工具。
-使用Git管理补丁可以使开发人员的生活更加轻松，尤其是随着补丁数量的增加。Git
-也有其粗糙的边缘和一定的危险，它是一个年轻和强大的工具，仍然在其开发人员完善
+使用Git管理补丁可以使开发人员的生活更加轻松，尤其是随着补丁数量的增长。Git也
+有其粗糙的边角和一定的危险性，它是一个年轻和强大的工具，仍然在其开发人员完善
中。本文档不会试图教会读者如何使用git；这会是个巨长的文档。相反，这里的重点
-将是Git如何特别适合内核开发过程。想要加快Git的开发人员可以在以下网站上找到
-更多信息：
+将是Git如何特别适合内核开发过程。想要加快用Git速度的开发人员可以在以下网站上
+æ\89¾å\88°æ\9b´å¤\9aä¿¡æ\81¯ï¼\9a
https://git-scm.com/
https://www.kernel.org/pub/software/scm/git/docs/user-manual.html
-在尝试使用它使补丁可供其他人使用之前，第一要务是阅读上述站点，对Git的工作
-方式有一个扎实的了解。使用Git的开发人员应该能够获得主线存储库的副本，探索
-修订历史，提交对树的更改，使用分支等。了解Git用于重写历史的工具（如Rebase）
-也很有用。Git有自己的术语和概念；Git的新用户应该了解refs、远程分支、索引、
-快进合并、推拉、分离头等。一开始可能有点吓人，但这些概念不难通过一点学习来
+同时网上也能找到各种各样的教程。
+
+在尝试使用它生成补丁供他人使用之前，第一要务是阅读上述网页，对Git的工作方式
+有一个扎实的了解。使用Git的开发人员应能进行拉取主线存储库的副本，查询修订
+历史，提交对树的更改，使用分支等操作。了解Git用于重写历史的工具（如rebase）
+也很有用。Git有自己的术语和概念；Git的新用户应该了解引用、远程分支、索引、
+快进合并、推拉、游离头等。一开始可能有点吓人，但这些概念不难通过一点学习来
理解。
使用git生成通过电子邮件提交的补丁是提高速度的一个很好的练习。
-å½\93æ\82¨å\87\86å¤\87好å¼\80å§\8bå®\89è£\85Gitæ \91ä¾\9bå\85¶ä»\96人æ\9f¥ç\9c\8bæ\97¶ï¼\8cæ\82¨å½\93ç\84¶é\9c\80è¦\81ä¸\80个å\8f¯ä»¥ä»\8eä¸æ\8f\90取的服务器。
-如果您有一个可以访问Internet的系统，那么使用git守护进程设置这样的服务器相
-对简单。否则，免费的公共托管网站（例如github）开始出现在网络上。成熟的开发
-人员可以在kernel.org上获得一个帐户，但这些帐户并不容易找到；有关更多信息，
-请参阅 https://kernel.org/faq/
+å½\93æ\82¨å\87\86å¤\87好å¼\80å§\8b建ç«\8bGitæ \91ä¾\9bå\85¶ä»\96人æ\9f¥ç\9c\8bæ\97¶ï¼\8cæ\97 ç\96\91é\9c\80è¦\81ä¸\80个å\8f¯ä»¥ä»\8eä¸æ\8b\89取的服务器。
+如果您有一个可以访问因特网的系统，那么使用git-daemon设置这样的服务器相对
+简单。同时，免费的公共托管网站（例如github）也开始出现在网络上。成熟的开发
+人员可以在kernel.org上获得一个帐户，但这些帐户并不容易得到；更多有关信息，
+请参阅 https://kernel.org/faq/ 。
正常的Git工作流程涉及到许多分支的使用。每一条开发线都可以分为单独的“主题
-分支”，并独立维护。Git的分支机构很便宜，没有理由不免费使用它们。而且，在
-任何情况下，您都不应该在任何您打算让其他人从中受益的分支中进行开发。应该
-å°\8få¿\83å\9c°å\88\9b建å\85¬å¼\80å\8f¯ç\94¨ç\9a\84å\88\86æ\94¯ï¼\9bå½\93å®\83们å¤\84äº\8eå®\8cæ\95´ç\9a\84å½¢å¼\8f并å\87\86å¤\87好è¿\90è¡\8cæ\97¶(è\80\8cä¸\8dæ\98¯ä¹\8bå\89\8dï¼\89ï¼\8c
-å\90\88并å¼\80å\8f\91å\88\86æ\94¯ç\9a\84è¡¥ä¸\81ã\80\82
+分支”，并独立维护。Git的分支很容易使用，没有理由不使用它们。而且，在任何
+情况下，您都不应该在任何您打算让其他人从中拉取的分支中进行开发。应该小心地
+å\88\9b建å\85¬å¼\80å\8f¯ç\94¨ç\9a\84å\88\86æ\94¯ï¼\9bå½\93å¼\80å\8f\91å\88\86æ\94¯å¤\84äº\8eå®\8cæ\95´ç\8a¶æ\80\81并已å\87\86å¤\87好æ\97¶(è\80\8cä¸\8dæ\98¯ä¹\8bå\89\8dï¼\89æ\89\8då\90\88并
+开发分支的补丁。
Git提供了一些强大的工具，可以让您重写开发历史。一个不方便的补丁（比如说，
一个打破二分法的补丁，或者有其他一些明显的缺陷）可以在适当的位置修复，或者
-å®\8cå\85¨ä»\8eå\8e\86å\8f²ä¸æ¶\88失ã\80\82ä¸\80个补ä¸\81ç³»å\88\97å\8f¯ä»¥è¢«é\87\8då\86\99ï¼\8c就好å\83\8få®\83æ\98¯å\9c¨ä»\8a天ç\9a\84主线ä¹\8bä¸\8aå\86\99ç\9a\84
-一样，即使你已经花了几个月的时间在写它。可以透明地将更改从一个分支转移到另
-一个分支。等等。明智地使用git修改历史的能力可以帮助创建问题更少的干净补丁集。
+å®\8cå\85¨ä»\8eå\8e\86å\8f²ä¸æ¶\88失ã\80\82ä¸\80个补ä¸\81ç³»å\88\97å\8f¯ä»¥è¢«é\87\8då\86\99ï¼\8c就好å\83\8få®\83æ\98¯å\9c¨ä»\8a天ç\9a\84主线ä¸\8aå\86\99ç\9a\84ä¸\80æ ·ï¼\8c
+即使你已经花了几个月的时间在写它。可以透明地将更改从一个分支转移到另一个
+分支。等等。明智地使用git修改历史的能力可以帮助创建问题更少的干净补丁集。
-然而，过度使用这种能力可能会导致其他问题，而不仅仅是对创建完美项目历史的
-简单痴迷。重写历史将重写该历史中包含的更改，将经过测试（希望）的内核树变
-为未经测试的内核树。但是，除此之外，如果开发人员没有对项目历史的共享视图，
-他们就无法轻松地协作；如果您重写了其他开发人员拉入他们存储库的历史，您将
-使è¿\99äº\9bå¼\80å\8f\91人å\91\98ç\9a\84ç\94\9fæ´»æ\9b´å\8a å\9b°é\9a¾ã\80\82å\9b æ¤ï¼\8cè¿\99é\87\8cæ\9c\89ä¸\80个ç®\80å\8d\95ç\9a\84ç»\8féª\8cæ³\95å\88\99ï¼\9a被导å\87ºå\88°å\85¶ä»\96
-人的历史在此后通常被认为是不可变的。
+然而，过度使用这种功能可能会导致其他问题，而不仅仅是对创建完美项目历史的
+简单痴迷。重写历史将重写该历史中包含的更改，将经过测试（希望如此）的内核树
+变为未经测试的内核树。除此之外，如果开发人员没有共享项目历史，他们就无法
+轻松地协作；如果您重写了其他开发人员拉入他们存储库的历史，您将使这些开发
+人å\91\98ç\9a\84ç\94\9fæ´»æ\9b´å\8a å\9b°é\9a¾ã\80\82å\9b æ¤ï¼\8cè¿\99é\87\8cæ\9c\89ä¸\80个ç®\80å\8d\95ç\9a\84ç»\8féª\8cæ³\95å\88\99ï¼\9a被导å\87ºå\88°å\85¶ä»\96å\9c°æ\96¹ç\9a\84å\8e\86å\8f²
+在此后通常被认为是不可变的。
因此，一旦将一组更改推送到公开可用的服务器上，就不应该重写这些更改。如果您
-尝试强制进行不会导致快进合并（即不共享同一历史记录的更改）的更改，Git将尝
-试强制执行此规则。可以重写此检查，有时可能需要重写导出的树。在树之间移动变
-更集以避免Linux-next中的冲突就是一个例子。但这种行为应该是罕见的。这就是为
-什么开发应该在私有分支中进行（必要时可以重写）并且只有在公共分支处于合理的
-高级状态时才转移到公共分支中的原因之一。
+尝试强制进行无法快进合并的更改（即不共享同一历史记录的更改），Git将尝试强制
+执行此规则。这可能覆盖检查，有时甚至需要重写导出的树。在树之间移动变更集以
+避免linux-next中的冲突就是一个例子。但这种行为应该是罕见的。这就是为什么
+开发应该在私有分支中进行（必要时可以重写）并且只有在公共分支处于合理的较新
+状态时才转移到公共分支中的原因之一。
当主线（或其他一组变更所基于的树）前进时，很容易与该树合并以保持领先地位。
对于一个私有的分支，rebasing 可能是一个很容易跟上另一棵树的方法，但是一旦
-ä¸\80棵æ \91被导å\87ºå\88°å\85¨ä¸\96ç\95\8cï¼\8crebasingå°±ä¸\8dæ\98¯ä¸\80个é\80\89项ã\80\82ä¸\80æ\97¦å\8f\91ç\94\9fè¿\99ç§\8dæ\83\85å\86µï¼\8cå°±å¿\85é¡»è¿\9bè¡\8c
-å®\8cå\85¨å\90\88并ï¼\88mergeï¼\89ã\80\82å\90\88并æ\9c\89æ\97¶æ\98¯å¾\88æ\9c\89æ\84\8fä¹\89ç\9a\84ï¼\8cä½\86æ\98¯è¿\87äº\8eé¢\91ç¹\81ç\9a\84å\90\88并ä¼\9aä¸\8då¿\85è¦\81å\9c°æ\89°ä¹±
-å\8e\86å\8f²ã\80\82å\9c¨è¿\99ç§\8dæ\83\85å\86µä¸\8bï¼\8c建议ç\9a\84æ\8a\80æ\9c¯æ\98¯ä¸\8dç»\8f常å\90\88并ï¼\8cé\80\9a常å\8fªå\9c¨ç\89¹å®\9aç\9a\84å\8f\91å¸\83ç\82¹ï¼\88å¦\82主线-rc
-å\8f\91å¸\83ï¼\89å\90\88并ã\80\82å¦\82æ\9e\9cæ\82¨å¯¹ç\89¹å®\9aç\9a\84æ\9b´æ\94¹æ\84\9få\88°ç´§å¼ ï¼\8cå\88\99å\8f¯ä»¥å§\8bç»\88å\9c¨ç§\81æ\9c\89å\88\86æ\94¯ä¸æ\89§è¡\8cæµ\8bè¯\95å\90\88并ã\80\82
-在这种情况下，git rerere 工具很有用；它记住合并冲突是如何解决的，这样您就
-不必重复相同的工作。
+ä¸\80棵æ \91被导å\87ºå\88°å¤\96ç\95\8cï¼\8crebasingå°±ä¸\8då\8f¯å\8f\96äº\86ã\80\82ä¸\80æ\97¦å\8f\91ç\94\9fè¿\99ç§\8dæ\83\85å\86µï¼\8cå°±å¿\85é¡»è¿\9bè¡\8cå®\8cå\85¨
+å\90\88并ï¼\88mergeï¼\89ã\80\82å\90\88并æ\9c\89æ\97¶æ\98¯å¾\88æ\9c\89æ\84\8fä¹\89ç\9a\84ï¼\8cä½\86æ\98¯è¿\87äº\8eé¢\91ç¹\81ç\9a\84å\90\88并ä¼\9aä¸\8då¿\85è¦\81å\9c°æ\89°ä¹±å\8e\86å\8f²ã\80\82
+å\9c¨è¿\99ç§\8dæ\83\85å\86µä¸\8b建议ç\9a\84å\81\9aæ³\95æ\98¯ä¸\8dè¦\81é¢\91ç¹\81å\90\88并ï¼\8cé\80\9a常å\8fªå\9c¨ç\89¹å®\9aç\9a\84å\8f\91å¸\83ç\82¹ï¼\88å¦\82主线-rcå\8f\91å¸\83ï¼\89
+å\90\88并ã\80\82å¦\82æ\9e\9cæ\82¨å¯¹ç\89¹å®\9aç\9a\84æ\9b´æ\94¹æ\84\9få\88°ç´§å¼ ï¼\8cå\88\99å\8f¯ä»¥å§\8bç»\88å\9c¨ç§\81æ\9c\89å\88\86æ\94¯ä¸æ\89§è¡\8cæµ\8bè¯\95å\90\88并ã\80\82å\9c¨
+这种情况下，git“rerere”工具很有用；它能记住合并冲突是如何解决的，这样您
+就不必重复相同的工作。
关于Git这样的工具的一个最大的反复抱怨是：补丁从一个存储库到另一个存储库的
大量移动使得很容易陷入错误建议的变更中，这些变更避开审查雷达进入主线。当内
-核开发人员看到这种情况发生时，他们往往会感到不高兴；在Git树上放置未查看或
-主é¢\98å¤\96ç\9a\84è¡¥ä¸\81å\8f¯è\83½ä¼\9aå½±å\93\8dæ\82¨å°\86æ\9d¥è\8e·å\8f\96æ \91ç\9a\84è\83½å\8a\9bã\80\82å¼\95ç\94¨Linus:
+核开发人员看到这种情况发生时，他们往往会感到不高兴；在Git树上放置未审阅或
+主é¢\98å¤\96ç\9a\84è¡¥ä¸\81å\8f¯è\83½ä¼\9aå½±å\93\8dæ\82¨å°\86æ\9d¥è®©æ \91被æ\8b\89å\8f\96ç\9a\84è\83½å\8a\9bã\80\82å¼\95ç\94¨Linusç\9a\84è¯\9d:
::
- 你可以给我发补丁，但要我从你哪里取一个Git补丁，我需要知道你知道
- 你在做什么，我需要能够相信事情而不去检查每个个人改变。
+ 你可以给我发补丁，但当我从你那里拉取一个Git补丁时，我需要知道你清楚
+ 自己在做什么，我需要能够相信事情而 *无需* 手动检查每个单独的更改。
（http://lwn.net/articles/224135/）。
为了避免这种情况，请确保给定分支中的所有补丁都与相关主题紧密相关；“驱动程序
修复”分支不应更改核心内存管理代码。而且，最重要的是，不要使用Git树来绕过
-审æ\9f¥è¿\87ç¨\8bã\80\82ä¸\8dæ\97¶ç\9a\84å°\86æ \91ç\9a\84æ\91\98è¦\81å\8f\91å¸\83å\88°ç\9b¸å\85³ç\9a\84å\88\97表ä¸ï¼\8cå½\93æ\97¶é\97´å\90\88é\80\82æ\97¶ï¼\8c请æ±\82
-Linux-next 中包含该树。
+审æ\9f¥è¿\87ç¨\8bã\80\82ä¸\8dæ\97¶ç\9a\84å°\86æ \91ç\9a\84æ\91\98è¦\81å\8f\91å¸\83å\88°ç\9b¸å\85³ç\9a\84å\88\97表ä¸ï¼\8cå\9c¨å\90\88é\80\82æ\97¶å\80\99请æ±\82linux-nextä¸
+包含该树。
-如果其他人开始发送补丁以包含到您的树中，不要忘记查看它们。还要确保您维护正确
-的作者信息； ``git am`` 工具在这方面做得最好，但是如果它通过第三方转发给您，
-您可能需要在补丁中添加“From：”行。
+如果其他人开始发送补丁以包含到您的树中，不要忘记审阅它们。还要确保您维护正确
+的作者信息； git “am”工具在这方面做得最好，但是如果补丁通过第三方转发给您，
+您可能需要在补丁中添加“From:”行。
-请求pull操作时，请务必提供所有相关信息：树的位置、要拉的分支以及拉操作将导致
-的更改。在这方面，git request pull 命令非常有用；它将按照其他开发人员的预期
-格式化请求，并检查以确保您记住了将这些更改推送到公共服务器。
+请求拉取时，请务必提供所有相关信息：树的位置、要拉取的分支以及拉取将导致的
+更改。在这方面 git request-pull 命令非常有用；它将按照其他开发人员所期望的
+格式化请求，并检查以确保您已记得将这些更改推送到公共服务器。
-审查补丁
+审阅补丁
--------
-一些读者当然会反对将本节与“高级主题”放在一起，因为即使是刚开始的内核开发人员
-也应该检查补丁。当然，学习如何在内核环境中编程没有比查看其他人发布的代码更好
-的方法了。此外，审阅者永远供不应求；通过查看代码，您可以对整个流程做出重大贡献。
+一些读者显然会反对将本节与“高级主题”放在一起，因为即使是刚开始的内核开发人员
+也应该审阅补丁。当然，没有比查看其他人发布的代码更好的方法来学习如何在内核环境
+中编程了。此外，审阅者永远供不应求；通过审阅代码，您可以对整个流程做出重大贡献。
-审查代码可能是一个令人生畏的前景，特别是对于一个新的内核开发人员来说，他们
+审查代码可能是一副令人生畏的图景，特别是对一个新的内核开发人员来说，他们
可能会对公开询问代码感到紧张，而这些代码是由那些有更多经验的人发布的。不过，
-即使是最有经验的开发人员编写的代码也可以得到改进。也许对评审员（所有评审员）
-最好的建议是：把评审评论当成问题而不是批评。询问“在这条路径中如何释放锁？”
+即使是最有经验的开发人员编写的代码也可以得到改进。也许对（所有）审阅者最好
+的建议是：把审阅评论当成问题而不是批评。询问“在这条路径中如何释放锁？”
总是比说“这里的锁是错误的”更好。
-不同的开发人员将从不同的角度审查代码。一些主要关注的是编码样式以及代码行是
-否有尾随空格。其他人将主要关注补丁作为一个整体实现的变更是否对内核有好处。
-然而，其他人会检查是否存在锁定问题、堆栈使用过度、可能的安全问题、在其他
-å\9c°æ\96¹å\8f\91ç\8e°ç\9a\84代ç \81é\87\8då¤\8dã\80\81足å¤\9fç\9a\84æ\96\87æ¡£ã\80\81对æ\80§è\83½ç\9a\84ä¸\8då\88©å½±å\93\8dã\80\81ç\94¨æ\88·ç©ºé\97´ABIæ\9b´æ\94¹ç\89ã\80\82æ\89\80æ\9c\89
-ç±»å\9e\8bç\9a\84æ£\80æ\9f¥ï¼\8cå¦\82æ\9e\9cå®\83们导è\87´更好的代码进入内核，都是受欢迎和值得的。
+不同的开发人员将从不同的角度审查代码。部分人会主要关注代码风格以及代码行是
+否有尾随空格。其他人会主要关注补丁作为一个整体实现的变更是否对内核有好处。
+同时也有人会检查是否存在锁问题、堆栈使用过度、可能的安全问题、在其他地方
+å\8f\91ç\8e°ç\9a\84代ç \81é\87\8då¤\8dã\80\81足å¤\9fç\9a\84æ\96\87æ¡£ã\80\81对æ\80§è\83½ç\9a\84ä¸\8då\88©å½±å\93\8dã\80\81ç\94¨æ\88·ç©ºé\97´ABIæ\9b´æ\94¹ç\89ã\80\82æ\89\80æ\9c\89ç±»å\9e\8b
+ç\9a\84æ£\80æ\9f¥ï¼\8cå\8fªè¦\81å®\83们è\83½å¼\95导更好的代码进入内核，都是受欢迎和值得的。
projects / linux-2.6-microblaze.git / commitdiff