The Django source code repository¶
When deploying a Django application into a real production environment, you will almost always want to use an official packaged release of Django.
However, if you’d like to try out in-development code from an upcoming release or contribute to the development of Django, you’ll need to obtain a clone of Django’s source code repository.
This document covers the way the code repository is laid out and how to work with and find things in it.
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
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.
The Git repository includes several branches:
maincontains 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.xare 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.
The Git repository also contains tags. These are the exact revisions from which packaged Django releases were produced, since version 1.0.
A number of tags also exist under the
archive/ prefix for archived
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
Note that this will get all of Django: in addition to the top-level
django module containing Python code, you’ll also get a copy of Django’s
documentation, test suite, packaging scripts and other miscellaneous bits.
Django’s code will be present in your clone as a directory named
To try out the in-development code with your own applications, place the
directory containing your clone on your Python import path. Then
statements which look for Django will find the
django module within your
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.
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
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 Supported versions.
For example, after the release of Django 1.5, the branch
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
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.