Django源代码库

当将Django应用程序部署到真实的生产环境中时，你几乎总是想使用“Django的正式打包发行版”。

不过，如果你想尝试即将发布的开发版本中的代码，或者想参与Django的开发，就需要克隆一个Django源代码库。

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

高级概述

The Django source code repository uses Git to track changes to the code over time, so you’ll need a copy of the Git client (a program called git) on your computer, and you’ll want to familiarize yourself with the basics of how Git works.

Git’s website offers downloads for various operating systems. The site also contains vast amounts of documentation.

The Django Git repository is located online at github.com/django/django. It contains the full source code for all Django releases, which you can browse online.

Git仓库包含了几个`分支`:

  • main contains the main in-development code which will become the next packaged release of Django. This is where most development activity is focused.
  • stable/A.B.x are the branches where release preparation work happens. They are also used for bugfix and security releases which occur as necessary after the initial release of a feature version.

Git仓库也包含`tags`。这些是Django从1.0版本开始打包发行的确切版本。

A number of tags also exist under the archive/ prefix for archived work.

The source code for the Djangoproject.com website can be found at github.com/django/djangoproject.com.

The main branch

If you’d like to try out the in-development code for the next release of Django, or if you’d like to contribute to Django by fixing bugs or developing new features, you’ll want to get the code from the main branch.

备注

Prior to March 2021, the main branch was called master.

请注意，这将获取Django的* 全部 *信息:除了包含Python代码的顶级模块` ‘ Django’ ，你还将获得Django文档、测试套件、打包脚本和其他杂项内容的副本。Django的代码将以目录 ‘ Django’ `的形式出现在你的克隆文件中。

To try out the in-development code with your own applications, place the directory containing your clone on your Python import path. Then import statements which look for Django will find the django module within your clone.

If you’re going to be working on Django’s code (say, to fix a bug or develop a new feature), you can probably stop reading here and move over to the documentation for contributing to Django, which covers things like the preferred coding style and how to generate and submit a patch.

Stable branches

Django uses branches to prepare for releases of Django. Each major release series has its own stable branch.

These branches can be found in the repository as stable/A.B.x branches and will be created right after the first alpha is tagged.

For example, immediately after Django 1.5 alpha 1 was tagged, the branch stable/1.5.x was created and all further work on preparing the code for the final 1.5 release was done there.

These branches also provide bugfix and security support as described in 支持的版本.

For example, after the release of Django 1.5, the branch stable/1.5.x receives only fixes for security and critical stability bugs, which are eventually released as Django 1.5.1 and so on, stable/1.4.x receives only security and data loss fixes, and stable/1.3.x no longer receives any updates.

Historical information

This policy for handling stable/A.B.x branches was adopted starting with the Django 1.5 release cycle.

Previously, these branches weren’t created until right after the releases and the stabilization work occurred on the main repository branch. Thus, no new feature development work for the next release of Django could be committed until the final release happened.

For example, shortly after the release of Django 1.3 the branch stable/1.3.x was created. Official support for that release has expired, and so it no longer receives direct maintenance from the Django project. However, that and all other similarly named branches continue to exist, and interested community members have occasionally used them to provide unofficial support for old Django releases.

标签(Tags)

Each Django release is tagged and signed by the releaser.

The tags can be found on GitHub’s tags page.

Archived feature-development work

Historical information

Since Django moved to Git in 2012, anyone can clone the repository and create their own branches, alleviating the need for official branches in the source code repository.

如果您正在探索存储库的历史，例如，如果您试图了解一些功能是如何设计的，则下面的部分非常有用。

Feature-development branches tend by their nature to be temporary. Some produce successful features which are merged back into Django’s main branch to become part of an official release, but others do not; in either case, there comes a time when the branch is no longer being actively worked on by any developer. At this point the branch is considered closed.

Django used to be maintained with the Subversion revision control system, that has no standard way of indicating this. As a workaround, branches of Django which are closed and no longer maintained were moved into attic.

A number of tags exist under the archive/ prefix to maintain a reference to this and other work of historical interest.

The following tags under the archive/attic/ prefix reference the tip of branches whose code eventually became part of Django itself:

  • boulder-oracle-sprint: Added support for Oracle databases to Django’s object-relational mapper. This has been part of Django since the 1.0 release.
  • gis: Added support for geographic/spatial queries to Django’s object-relational mapper. This has been part of Django since the 1.0 release, as the bundled application django.contrib.gis.
  • i18n: Added internationalization support to Django. This has been part of Django since the 0.90 release.
  • magic-removal:对Django的对象关系映射器的内部和公共api进行了重大重构。从0.95版本开始，Django就加入了这个功能。
  • multi-auth: A refactoring of Django’s bundled authentication framework which added support for authentication backends. This has been part of Django since the 0.95 release.
  • new-admin: A refactoring of Django’s bundled administrative application. This became part of Django as of the 0.91 release, but was superseded by another refactoring (see next listing) prior to the Django 1.0 release.
  • newforms-admin: The second refactoring of Django’s bundled administrative application. This became part of Django as of the 1.0 release, and is the basis of the current incarnation of django.contrib.admin.
  • queryset-refactor: A refactoring of the internals of Django’s object-relational mapper. This became part of Django as of the 1.0 release.
  • unicode: A refactoring of Django’s internals to consistently use Unicode-based strings in most places within Django and Django applications. This became part of Django as of the 1.0 release.

Additionally, the following tags under the archive/attic/ prefix reference the tips of branches that were closed, but whose code was never merged into Django, and the features they aimed to implement were never finished:

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

Finally, under the archive/ prefix, the repository contains soc20XX/<project> tags referencing the tip of branches that were used by students who worked on Django during the 2009 and 2010 Google Summer of Code programs.