Django 源代码库 — Django 文档

来自菜鸟教程
Django/docs/3.2.x/internals/git
跳转至:导航、​搜索

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 的 all:除了包含 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 的 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-adminDjango 捆绑的管理应用程序 的重构。 从 0.91 版本开始,这成为 Django 的一部分,但在 Django 1.0 版本之前被另一个重构(参见下一个清单)所取代。
  • newforms-admin:Django 捆绑的管理应用程序的第二次重构。 从 1.0 版本开始,这成为 Django 的一部分,并且是 django.contrib.admin 当前版本的基础。
  • queryset-refactor:Django 对象关系映射器内部结构的重构。 从 1.0 版本开始,这成为 Django 的一部分。
  • unicode:Django 内部结构的重构,以便在 Django 和 Django 应用程序中的大多数地方始终使用基于 Unicode 的字符串。 从 1.0 版本开始,这成为 Django 的一部分。

此外,archive/attic/ 前缀下的以下标签引用了关闭的分支的提示,但其代码从未合并到 Django 中,并且它们旨在实现的功能从未完成:

  • full-history
  • generic-auth
  • multiple-db-support
  • per-object-permissions
  • schema-evolution
  • schema-evolution-ng
  • search-api
  • sqlalchemy

最后,在 archive/ 前缀下,存储库包含 soc20XX/<project> 标记,引用分支的尖端,在 2009 年和 2010 年 Google Summer of Code 计划中使用 Django 的学生。