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

Source file repositories/reference/linux-study-clean/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/zh_CN/process/7.AdvancedTopics.rst
Extension
.rst
Size
9665 bytes
Lines
148
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. include:: ../disclaimer-zh_CN.rst

:Original: :ref:`Documentation/process/7.AdvancedTopics.rst <development_advancedtopics>`

:Translator:

 时奎亮 Alex Shi <alex.shi@linux.alibaba.com>

:校译:

 吴想成 Wu XiangCheng <bobwxc@email.cn>

.. _cn_development_advancedtopics:

高级主题
========

现在，希望您能够掌握开发流程的工作方式。然而，还有更多的东西要学！本节将介绍
一些主题，这些主题对希望成为Linux内核开发过程常规部分的开发人员有帮助。

使用Git管理补丁
---------------

内核使用分布式版本控制始于2002年初，当时Linus首次开始使用专有的Bitkeeper应用
程序。虽然BitKeeper存在争议，但它所体现的软件版本管理方法却肯定不是。分布式
版本控制可以立即加速内核开发项目。现在有好几种免费的BitKeeper替代品。
但无论好坏，内核项目都已经选择了Git作为其工具。

使用Git管理补丁可以使开发人员的生活更加轻松，尤其是随着补丁数量的增长。Git也
有其粗糙的边角和一定的危险性，它是一个年轻和强大的工具，仍然在其开发人员完善
中。本文档不会试图教会读者如何使用git；这会是个巨长的文档。相反，这里的重点
将是Git如何特别适合内核开发过程。想要加快用Git速度的开发人员可以在以下网站上
找到更多信息：

	https://git-scm.com/

	https://www.kernel.org/pub/software/scm/git/docs/user-manual.html

同时网上也能找到各种各样的教程。

在尝试使用它生成补丁供他人使用之前，第一要务是阅读上述网页，对Git的工作方式
有一个扎实的了解。使用Git的开发人员应能进行拉取主线存储库的副本，查询修订
历史，提交对树的更改，使用分支等操作。了解Git用于重写历史的工具（如rebase）
也很有用。Git有自己的术语和概念；Git的新用户应该了解引用、远程分支、索引、
快进合并、推拉、游离头等。一开始可能有点吓人，但这些概念不难通过一点学习来
理解。

使用git生成通过电子邮件提交的补丁是提高速度的一个很好的练习。

当您准备好开始建立Git树供其他人查看时，无疑需要一个可以从中拉取的服务器。
如果您有一个可以访问因特网的系统，那么使用git-daemon设置这样的服务器相对
简单。同时，免费的公共托管网站（例如github）也开始出现在网络上。成熟的开发
人员可以在kernel.org上获得一个帐户，但这些帐户并不容易得到；更多有关信息，
请参阅 https://kernel.org/faq/ 。

正常的Git工作流程涉及到许多分支的使用。每一条开发线都可以分为单独的“主题
分支”，并独立维护。Git的分支很容易使用，没有理由不使用它们。而且，在任何
情况下，您都不应该在任何您打算让其他人从中拉取的分支中进行开发。应该小心地
创建公开可用的分支；当开发分支处于完整状态并已准备好时(而不是之前）才合并
开发分支的补丁。

Git提供了一些强大的工具，可以让您重写开发历史。一个不方便的补丁（比如说，
一个打破二分法的补丁，或者有其他一些明显的缺陷）可以在适当的位置修复，或者
完全从历史中消失。一个补丁系列可以被重写，就好像它是在今天的主线上写的一样，
即使你已经花了几个月的时间在写它。可以透明地将更改从一个分支转移到另一个
分支。等等。明智地使用git修改历史的能力可以帮助创建问题更少的干净补丁集。

然而，过度使用这种功能可能会导致其他问题，而不仅仅是对创建完美项目历史的
简单痴迷。重写历史将重写该历史中包含的更改，将经过测试（希望如此）的内核树
变为未经测试的内核树。除此之外，如果开发人员没有共享项目历史，他们就无法

Annotation

Implementation Notes