Skip to main content

Django源代码存储库

当将Django应用程序部署到真实的生产环境中时,您几乎总是希望使用 an official packaged release of Django

但是,如果您想从即将发布的版本中尝试开发中代码,或者为Django的开发做出贡献,那么您需要获取Django的源代码存储库的克隆。

本文档涵盖了代码存储库的布局方式以及如何使用和查找其中的内容。

高级概述

Django源代码库使用 Git 跟踪代码随时间的变化,因此您需要在计算机上有一个Git客户端(一个名为 git 的程序)的副本,并且您需要熟悉如何Git工程。

Git的网站提供各种操作系统的下载。该网站还包含大量的 documentation

Django Git存储库位于 github.com/django/django 在线。它包含所有Django版本的完整源代码,您可以在线浏览。

Git仓库包括几个 branches

  • master 包含主要的开发中代码,将成为Django的下一个打包版本。这是大多数开发活动集中的地方。

  • stable/A.B.x 是发布准备工作发生的分支。它们还用于在功能版本的初始发布之后根据需要发生的错误修复和安全版本。

  • soc20XX/<project> 分支机构由在2009年和2010年Google夏季代码计划期间使用Django的学生使用。

  • attic/<project> 分支用于开发主要或实验的新功能,而不影响Django的代码的其余部分。

Git仓库还包含 tags。这些是从版本1.0开始生成封装Django版本的确切修订版本。

djangoproject.com 网站的源代码可以在 github.com/django/djangoproject.com 找到。

主分支

如果你想尝试下一个版本的Django的开发中代码,或者如果你想通过修复bug或开发新的功能来贡献Django,你将需要从主分支。

注意,这将获得Django的 all:除了包含Python代码的顶级 django 模块之外,您还将获得Django的文档,测试套件,打包脚本和其他各种位的副本。 Django的代码将作为名为 django 的目录存在于您的克隆中。

要使用自己的应用程序试用开发中代码,只需将包含克隆的目录放在Python导入路径中。然后,查找Django的 import 语句将在您的克隆中找到 django 模块。

如果你打算使用Django的代码(比如修复一个bug或开发一个新的功能),你可以在这里停止阅读,并转移到 用于贡献Django的文档,它涵盖了首选的编码风格,如何生成和提交补丁。

其他分支

Django使用分支来准备Django的发布。

在过去,当Django托管在Subversion上时,分支也用于功能开发。现在Django托管在Git和功能开发是在贡献者的叉,但Subversion功能分支保持在Git的历史参考。

稳定的分支

这些分支可以作为 stable/A.B.x 分支在存储库中找到,并且将在第一个alpha标记之后创建。

例如,在 Django 1.5 alpha 1 被标记之后,立即创建分支 stable/1.5.x,并且在那里进行关于准备最终1.5版本的代码的所有进一步的工作。

这些分支还为最新发布的Django版本提供有限的bug修复支持,并为最近发布的两个Django版本提供安全支持。

例如,在发布Django 1.5之后,分支 stable/1.5.x 只接收针对安全性和关键稳定性错误的修复,这些错误最终作为Django 1.5.1等发布,stable/1.4.x 仅接收安全修复,stable/1.3.x 不再接收任何更新。

历史信息

从Django 1.5发布周期开始,采用了处理 stable/A.B.x 分支的这项政策。

以前,这些分支直到发布之后才会创建,并且稳定工作发生在主存储库分支上。因此,在发布最终版本之前,不会提交下一个版本的Django的新功能开发工作。

例如,在Django 1.3发布后不久,创建了分支 stable/1.3.x。对该版本的官方支持已过期,因此它不再接受来自Django项目的直接维护。然而,该和所有其他类似命名的分支继续存在,感兴趣的社区成员偶尔使用它们为旧的Django版本提供非官方支持。

功能开发分支

历史信息

自从Django在2012年搬到Git之后,任何人都可以克隆存储库并创建自己的分支,从而减少对源代码库中官方分支的需求。

如果您要探索存储库的历史记录,以下部分最为有用,例如,如果您想了解某些功能的设计方式。

功能开发分支的性质往往是暂时的。一些产生成功的特性,被合并回Django的主人成为正式版本的一部分,但其他人不会;在任一情况下,有一个时间,当分支不再由任何开发人员积极工作。此时分支被认为是关闭的。

不幸的是,Django以前是用Subversion版本控制系统维护的,没有标准的方式来指示这一点。作为解决方法,关闭并且不再维护的Django的分支被移动到 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-authDjango的捆绑认证框架 的重构,增加了对 认证后端 的支持。这是自从0.95版本以来Django的一部分。

  • new-adminDjango的捆绑管理应用程序 的重构。这成为Django的一部分,从0.91版本,但在Django 1.0版本之前被另一个重构(见下面的清单)所取代。

  • newforms-admin:Django的捆绑管理应用程序的第二次重构。这成为1.0版本中Django的一部分,并且是当前 django.contrib.admin 化身的基础。

  • queryset-refactor:Django的对象关系映射器的内部重构。这成为Django从1.0版本开始的一部分。

  • unicode:重构Django的内部结构,以在Django和Django应用程序中的大多数地方始终使用基于Unicode的字符串。这成为Django从1.0版本开始的一部分。

当Django从SVN移动到Git时,关于分支合并的信息未保留在源代码存储库中。这意味着Django的 master 分支不包含上述分支的合并提交。

但是,此信息是 available as a grafts file。您可以通过将以下行放在本地克隆中的 .git/info/grafts 中进行还原:

ac64e91a0cadc57f4bc5cd5d66955832320ca7a1 553a20075e6991e7a60baee51ea68c8adc520d9a 0cb8e31823b2e9f05c4ae868c19f5f38e78a5f2e
79e68c225b926302ebb29c808dda8afa49856f5c d0f57e7c7385a112cb9e19d314352fc5ed5b0747 aa239e3e5405933af6a29dac3cf587b59a099927
5cf8f684237ab5addaf3549b2347c3adf107c0a7 cb45fd0ae20597306cd1f877efc99d9bd7cbee98 e27211a0deae2f1d402537f0ebb64ad4ccf6a4da
f69cf70ed813a8cd7e1f963a14ae39103e8d5265 d5dbeaa9be359a4c794885c2e9f1b5a7e5e51fb8 d2fcbcf9d76d5bb8a661ee73dae976c74183098b
aab3a418ac9293bb4abd7670f65d930cb0426d58 4ea7a11659b8a0ab07b0d2e847975f7324664f10 adf4b9311d5d64a2bdd58da50271c121ea22e397
ff60c5f9de3e8690d1e86f3e9e3f7248a15397c8 7ef212af149540aa2da577a960d0d87029fd1514 45b4288bb66a3cda401b45901e85b645674c3988
9dda4abee1225db7a7b195b84c915fdd141a7260 4fe5c9b7ee09dc25921918a6dbb7605edb374bc9 3a7c14b583621272d4ef53061287b619ce3c290d
a19ed8aea395e8e07164ff7d85bd7dff2f24edca dc375fb0f3b7fbae740e8cfcd791b8bccb8a4e66 42ea7a5ce8aece67d16c6610a49560c1493d4653
9c52d56f6f8a9cdafb231adf9f4110473099c9b5 c91a30f00fd182faf8ca5c03cd7dbcf8b735b458 4a5c5c78f2ecd4ed8859cd5ac773ff3a01bccf96
953badbea5a04159adbfa970f5805c0232b6a401 4c958b15b250866b70ded7d82aa532f1e57f96ae 5664a678b29ab04cad425c15b2792f4519f43928
471596fc1afcb9c6258d317c619eaf5fd394e797 4e89105d64bb9e04c409139a41e9c7aac263df4c 3e9035a9625c8a8a5e88361133e87ce455c4fc13
9233d0426537615e06b78d28010d17d5a66adf44 6632739e94c6c38b4c5a86cf5c80c48ae50ac49f 18e151bc3f8a85f2766d64262902a9fcad44d937

此外,以下分支已关闭,但他们的代码从未合并到Django,并且他们旨在实现的功能从未完成:

  • full-history

  • generic-auth

  • multiple-db-support

  • per-object-permissions

  • schema-evolution

  • schema-evolution-ng

  • search-api

  • sqlalchemy

所有上述分支现在都在 attic

最后,存储库包含 soc2009/xxxsoc2010/xxx 功能分支,用于Google夏季代码项目。

标签

每个Django版本都由 释放者 标记和签名。

标签可以在GitHub的 tags 页面上找到。