Django源代码库¶
当将Django应用程序部署到真实的生产环境中时，你几乎总是想使用“Django的正式打包发行版”。
不过，如果你想尝试即将发布的开发版本中的代码，或者想参与Django的开发，就需要克隆一个Django源代码库。
本文介绍了代码存储库的布局方式，以及如何使用和查找其中的内容。
高级概述¶
Django 源代码仓库使用 Git 跟踪代码随时间的变化，因此您需要在计算机上安装 Git 客户端（一个名为 git 的程序），并熟悉 Git 的基本工作原理。
Git 的网站提供了各种操作系统的下载。该网站还包含大量的 文档。
Django 的 Git 仓库位于在线地址 github.com/django/django。它包含了所有 Django 版本的完整源代码，您可以在线浏览。
Git 仓库包含了几个 分支 :
main包含了即将成为下一个打包发布版本的 Django 的主要开发代码。这是大多数开发活动的焦点所在。stable/A.B.x是进行发布准备工作的分支。它们也用于在功能版本的初始发布后根据需要进行的错误修复和安全发布。
Git 仓库也包含 tags 。这些是 Django 从 1.0 版本开始打包发行的确切版本。
archive/ 前缀下还存在许多标签，用于 已归档的工作。
Djangoproject.com 网站的源代码可以在 github.com/django/djangoproject.com 上找到。
主要分支¶
如果你想尝试下一版 Django 的开发代码，或者想通过修复错误或开发新功能来贡献于 Django，你需要从主要分支获取代码。
Note
在 2021 年 3 月之前，主要分支被称为 master。
请注意，这将获取 完整 的 Django：除了包含 Python 代码的顶级 django 模块外，你还将获得 Django 的文档、测试套件、打包脚本和其他各种组件的副本。Django 的代码将在你的克隆中作为一个名为 django 的目录存在。
要尝试使用你自己的应用程序来运行开发中的代码，请将包含克隆的目录放在你的 Python 导入路径上。然后，import 语句寻找 Django 的时候会在你的克隆中找到 django 模块。
如果你打算在 Django 的代码上工作（比如修复错误或开发新功能），你可以停在这里阅读，然后转到 Django 贡献文档，其中包括首选的编码风格以及如何生成和提交补丁等内容。
稳定分支¶
Django 使用分支来准备 Django 的发布。每个主要发布系列都有自己的稳定分支。
这些分支可以在仓库中找到，以 stable/A.B.x 分支的形式存在，并将在第一个 alpha 版本被标记后创建。
例如，在 Django 1.5 alpha 1 被标记后不久，分支 stable/1.5.x 被创建，所有进一步准备代码以发布最终版本 1.5 的工作都在那里进行。
这些分支还提供 bug 修复和安全支持，如 支持的版本策略 中所描述的那样。
例如，在发布 Django 1.5 后，分支 stable/1.5.x 只接收安全性和关键稳定性 bug 的修复，最终以 Django 1.5.1 等版本发布。而 stable/1.4.x 只接收安全性和数据丢失问题的修复，而 stable/1.3.x 则不再接收任何更新。
历史信息
这个处理 stable/A.B.x 分支的策略是从 Django 1.5 发布周期开始采用的。
以前，这些分支直到发布后才会创建，而稳定工作是在主仓库分支上进行的。因此，在最终发布之前，无法提交关于下一版 Django 的新功能开发工作。
例如，在 Django 1.3 发布不久之后，分支 stable/1.3.x 被创建。该版本的官方支持已经到期，因此不再由 Django 项目直接维护。然而，所有类似命名的分支仍然存在，有兴趣的社区成员偶尔会使用它们来提供旧版 Django 的非官方支持。
标签(Tags)¶
每个 Django 发布版本都会被发布者打上标签并签名。
这些标签可以在 GitHub 的 tags 页面上找到。
已归档的特性开发工作¶
历史信息
自从 Django 在 2012 年转向 Git 后，任何人都可以克隆仓库并创建自己的分支，从而减轻了在源代码仓库中创建官方分支的需要。
如果您正在探索存储库的历史，例如，如果您试图了解一些功能是如何设计的，则下面的部分非常有用。
由于特性开发分支的性质，它们往往是临时的。有些特性分支会产生成功的功能，这些功能会合并到 Django 的主分支中，成为官方版本的一部分，但也有些不会；无论哪种情况，总会有一个时间点，分支不再由任何开发人员积极维护。在这个时候，分支被视为已关闭。
Django 曾经使用 Subversion 版本控制系统进行维护，但这个系统没有标准的方法来表示已关闭的分支。作为一种解决方法，不再维护的 Django 分支被移动到了 attic 中。
在 archive/ 前缀下存在许多标签，以维护对这些以及其他具有历史兴趣的工作的引用。
以下在 archive/attic/ 前缀下的标签引用了最终成为 Django 本身一部分的分支的末尾：
boulder-oracle-sprint: 为 Django 的对象关系映射器添加了对 Oracle 数据库的支持。这个功能自 1.0 版本以来一直是 Django 的一部分。gis: 为 Django 的对象关系映射器添加了对地理/空间查询的支持。这已经是自 1.0 版本以来的 Django 的一部分，作为捆绑的应用程序django.contrib.gis。i18n: 为 Django 添加了 国际化支持。这已经是自 0.90 版本以来的 Django 的一部分。magic-removal:对Django的对象关系映射器的内部和公共api进行了重大重构。从0.95版本开始，Django就加入了这个功能。multi-auth: 对 Django 捆绑的身份验证框架 进行了重构，添加了对 身份验证后端 的支持。这已经是自 0.95 版本以来的 Django 的一部分。new-admin: 对 Django 捆绑的管理应用程序 进行了重构。这从 Django 0.91 版本开始成为 Django 的一部分，但在 Django 1.0 版本发布之前被另一个重构所取代。newforms-admin: Django 捆绑的管理应用程序的第二次重构。这从 Django 1.0 版本开始成为 Django 的一部分，并且是当前版本的django.contrib.admin的基础。queryset-refactor: Django 对象关系映射器内部的重构。这从 Django 1.0 版本开始成为 Django 的一部分。unicode: Django 内部的重构，以在 Django 和 Django 应用程序的大多数地方一致使用基于 Unicode 的字符串。这从 Django 1.0 版本开始成为 Django 的一部分。
此外，在 archive/attic/ 前缀下的以下标签引用了已关闭的分支的末尾，但其代码从未合并到 Django 中，它们旨在实现的功能也从未完成：
full-historygeneric-authmultiple-db-supportper-object-permissionsschema-evolutionschema-evolution-ngsearch-apisqlalchemy
最后，在 archive/ 前缀下，仓库包含了 soc20XX/<project> 标签，引用了在 2009 年和 2010 年 Google 夏季编程活动期间为 Django 工作的学生使用的分支末尾。
