The Django source code repository

    However, if you’d like to try out in-development code from an upcoming releaseor contribute to the development of Django, you’ll need to obtain a clone ofDjango’s source code repository.

    This document covers the way the code repository is laid out and how to workwith and find things in it.

    The Django source code repository uses Git to track changes to the codeover 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 ofhow Git works.

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

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

    The Git repository includes several :

    • master contains the main in-development code which will becomethe next packaged release of Django. This is where most developmentactivity 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 necessaryafter the initial release of a feature version.
    • attic/<project> branches were used to develop major or experimental newfeatures without affecting the rest of Django’s code.The Git repository also contains tags. These are the exact revisions fromwhich packaged Django releases were produced, since version 1.0.

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

    If you’d like to try out the in-development code for the next release ofDjango, or if you’d like to contribute to Django by fixing bugs or developingnew 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-leveldjango module containing Python code, you’ll also get a copy of Django’sdocumentation, test suite, packaging scripts and other miscellaneous bits.Django’s code will be present in your clone as a directory nameddjango.

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

    Django uses branches to prepare for releases of Django.

    In the past when Django was hosted on Subversion, branches were also used forfeature development. Now Django is hosted on Git and feature development isdone on contributor’s forks, but the Subversion feature branches remain in Gitfor historical reference.

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

    For example, immediately after Django 1.5 alpha 1 was tagged, the branchstable/1.5.x was created and all further work on preparing the code for thefinal 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.xreceives only fixes for security and critical stability bugs, which areeventually released as Django 1.5.1 and so on, stable/1.4.x receives onlysecurity and data loss fixes, and no longer receives anyupdates.

    Historical information

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

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

    For example, shortly after the release of Django 1.3 the branchstable/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, andinterested community members have occasionally used them to provideunofficial support for old Django releases.

    Feature-development branches

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

    The following section is mostly useful if you’re exploring the repository’shistory, for example if you’re trying to understand how some features weredesigned.

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

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

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

    • boulder-oracle-sprint: Added support for Oracle databases toDjango’s object-relational mapper. This has been part of Djangosince the 1.0 release.
    • gis: Added support for geographic/spatial queries to Django’sobject-relational mapper. This has been part of Django since the 1.0release, as the bundled application django.contrib.gis.
    • i18n: Added toDjango. This has been part of Django since the 0.90 release.
    • magic-removal: A major refactoring of both the internals andpublic APIs of Django’s object-relational mapper. This has been partof Django since the 0.95 release.
    • multi-auth: A refactoring of Django’s bundledauthentication framework which added support for. This hasbeen part of Django since the 0.95 release.
    • new-admin: A refactoring of Django’s bundledadministrative application. This became part ofDjango as of the 0.91 release, but was superseded by anotherrefactoring (see next listing) prior to the Django 1.0 release.
    • newforms-admin: The second refactoring of Django’s bundledadministrative application. This became part of Django as of the 1.0release, and is the basis of the current incarnation ofdjango.contrib.admin.
    • unicode: A refactoring of Django’s internals to consistently useUnicode-based strings in most places within Django and Djangoapplications. This became part of Django as of the 1.0 release.When Django moved from Subversion to Git, the information about branch mergeswasn’t preserved in the source code repository. This means that the masterbranch of Django doesn’t contain merge commits for the above branches.

    However, this information is . You can restore itby putting the following lines in .git/info/grafts in your local clone:

    Additionally, the following branches are closed, but their code wasnever merged into Django and the features they aimed to implementwere never finished:

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

    Finally, the repository contains and soc2010/xxx featurebranches, used for the 2009 and 2010 Google Summer of Code projects.

    Each Django release is tagged and signed by the releaser.

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