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 web site 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.

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 master branch.

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
django.

To try out the in-development code with your own applications, simply 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.

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

The following section is mostly useful if you’re exploring the repository’s
history, for example if you’re trying to understand how some features were
designed.

Feature-development branches tend by their nature to be temporary. Some
produce successful features which are merged back into Django’s master 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.

Unfortunately, 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.

For reference, the following are branches whose code eventually became
part of Django itself, and so are no longer separately maintained:

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.

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.

When Django moved from SVN to Git, the information about branch merges wasn’t
preserved in the source code repository. This means that the master branch
of Django doesn’t contain merge commits for the above branches.

However, this information is available as a grafts file. You can restore it
by putting the following lines in .git/info/grafts in your local clone:

In addition to fixing bugs in current master, the Django project provides
official bugfix support for the most recent released version of Django, and
security support for the two most recently-released versions of Django.

This support is provided via branches in which the necessary bug or security
fixes are applied; the branches are then used as the basis for issuing bugfix
or security releases.

These branches can be found in the repository as stable/A.B.x
branches, and new branches will be created there after each new Django
release.

For example, shortly after the release of Django 1.0, the branch
stable/1.0.x was created to receive bug fixes, and shortly after the
release of Django 1.1 the branch stable/1.1.x was created.

Official support for the above mentioned releases has expired, and so they no
longer receive direct maintenance from the Django project. However, the
branches continue to exist and interested community members have occasionally
used them to provide unofficial support for old Django releases.