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 仓库还包含 标签。这些是自 1.0 版以来生成 Django 打包版本的精确版本。
一些标签也存在于 archive/ 前缀下，用于 存档的工作。
Djangoproject.com 网站的源代码可以在 github.com/django/djangoproject.com 找到。
主分支¶
如果您想试用 Django 下一个版本的开发代码，或者想通过修复错误或开发新功能来为 Django 做出贡献，您需要从主分支获取代码。
注意
在 2021 年 3 月之前，主分支称为 master。
请注意，这将获取所有 Django：除了包含 Python 代码的顶层 django 模块外，您还将获得 Django 文档、测试套件、打包脚本和其他杂项内容的副本。Django 的代码将作为名为 django 的目录存在于您的克隆中。
要使用自己的应用程序试用开发代码，请将包含克隆的目录放在 Python 导入路径上。然后，查找 Django 的 import 语句将在您的克隆中找到 django 模块。
如果您要处理 Django 的代码（例如，修复错误或开发新功能），您可能可以停止阅读此处，并转到 为 Django 做出贡献的文档，其中介绍了首选编码风格以及如何生成和提交补丁。
稳定分支¶
Django 使用分支来准备 Django 的发布。每个主要发布系列都有自己的稳定分支。
这些分支可以在存储库中找到，作为 stable/A.B.x 分支，并且将在第一个 alpha 版本被标记后立即创建。
例如，在Django 1.5 alpha 1 被标记后，立即创建了 stable/1.5.x 分支，并且所有进一步准备代码以进行最终 1.5 版本发布的工作都在那里完成。
这些分支还提供错误修复和安全支持，如 受支持的版本 中所述。
例如，在 Django 1.5 发布后，stable/1.5.x 分支仅接收安全性和关键稳定性错误的修复，这些修复最终会作为 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 版本提供非官方支持。
标签¶
每个 Django 版本都由发布者标记和签名。
这些标签可以在 GitHub 的 标签 页面上找到。
已归档的功能开发工作¶
历史信息
自从 Django 在 2012 年迁移到 Git 以来，任何人都可以克隆存储库并创建自己的分支，从而无需在源代码存储库中使用官方分支。
以下部分主要在您浏览存储库的历史记录时有用，例如，如果您尝试了解某些功能的设计方式。
功能开发分支本质上往往是临时的。一些分支产生了成功的功能，这些功能被合并回 Django 的主分支，成为官方版本的一部分，但其他分支则没有；无论哪种情况，都会有一个时间点，开发人员不再积极地处理该分支。此时，该分支被视为已关闭。
Django 曾经使用 Subversion 版本控制系统进行维护，该系统没有标准的方法来指示这一点。作为变通方法，已关闭且不再维护的 Django 分支被移动到 attic 中。
一些标签存在于 archive/ 前缀下，以维护对这部分内容和其他具有历史意义的工作的引用。
以下 archive/attic/ 前缀下的标签引用了最终成为 Django 本身一部分的分支的顶端
boulder-oracle-sprint：为 Django 的对象关系映射器添加了对 Oracle 数据库的支持。这已成为 Django 自 1.0 版本以来的组成部分。gis：为 Django 的对象关系映射器添加了对地理/空间查询的支持。这已成为 Django 自 1.0 版本以来的组成部分，作为捆绑的应用程序django.contrib.gis。i18n：为 Django 添加了 国际化支持。这已成为 Django 自 0.90 版本以来的组成部分。magic-removal：对 Django 对象关系映射器的内部结构和公共 API 进行了重大重构。这已成为 Django 自 0.95 版本以来的组成部分。multi-auth：对 Django 的捆绑身份验证框架 进行了重构，增加了对 身份验证后端 的支持。这已成为 Django 自 0.95 版本以来的组成部分。new-admin：对 Django 的捆绑管理应用程序 进行了重构。这在 Django 0.91 版本中成为一部分，但在 Django 1.0 版本发布之前被另一次重构取代（请参阅下一列表）。newforms-admin：Django 捆绑管理应用程序的第二次重构。这在 Django 1.0 版本中成为一部分，并且是django.contrib.admin当前版本的依据。queryset-refactor：对 Django 对象关系映射器的内部结构进行了重构。这在 Django 1.0 版本中成为一部分。unicode：对 Django 的内部结构进行了重构，以便在 Django 和 Django 应用程序中的大多数地方一致地使用基于 Unicode 的字符串。这在 Django 1.0 版本中成为一部分。
此外，在 archive/attic/ 前缀下的以下标签引用了已关闭分支的顶端，但其代码从未合并到 Django 中，并且它们旨在实现的功能也从未完成。
full-historygeneric-authmultiple-db-supportper-object-permissionsschema-evolutionschema-evolution-ngsearch-apisqlalchemy
最后，在 archive/ 前缀下，存储库包含 soc20XX/<project> 标签，这些标签引用了在 2009 年和 2010 年 Google Summer of Code 项目期间参与 Django 开发的学生所使用分支的顶端。
