When deploying a Django application into a real production environment, you\nwill almost always want to use an official packaged release of Django.
\nHowever, if you’d like to try out in-development code from an upcoming release\nor contribute to the development of Django, you’ll need to obtain a clone of\nDjango’s source code repository.
\nThis document covers the way the code repository is laid out and how to work\nwith and find things in it.
\nThe Django source code repository uses Git to track changes to the code\nover time, so you’ll need a copy of the Git client (a program called git)\non your computer, and you’ll want to familiarize yourself with the basics of\nhow Git works.
Git’s website offers downloads for various operating systems. The site also\ncontains vast amounts of documentation.
\nThe Django Git repository is located online at github.com/django/django. It contains the full source code for all\nDjango releases, which you can browse online.
\nThe Git repository includes several branches:
\nmain contains the main in-development code which will become\nthe next packaged release of Django. This is where most development\nactivity is focused.
stable/A.B.x are the branches where release preparation work happens.\nThey are also used for bugfix and security releases which occur as necessary\nafter the initial release of a feature version.
The Git repository also contains tags. These are the exact revisions from\nwhich packaged Django releases were produced, since version 1.0.
\nA number of tags also exist under the archive/ prefix for archived\nwork.
The source code for the Djangoproject.com\nwebsite can be found at github.com/django/djangoproject.com.
\nIf you’d like to try out the in-development code for the next release of\nDjango, or if you’d like to contribute to Django by fixing bugs or developing\nnew features, you’ll want to get the code from the main branch.
\n\nNote that this will get all of Django: in addition to the top-level\ndjango module containing Python code, you’ll also get a copy of Django’s\ndocumentation, test suite, packaging scripts and other miscellaneous bits.\nDjango’s code will be present in your clone as a directory named\ndjango.
To try out the in-development code with your own applications, place the\ndirectory containing your clone on your Python import path. Then import\nstatements which look for Django will find the django module within your\nclone.
If you’re going to be working on Django’s code (say, to fix a bug or\ndevelop a new feature), you can probably stop reading here and move\nover to the documentation for contributing to Django, which covers things like the preferred\ncoding style and how to generate and submit a patch.
\nDjango uses branches to prepare for releases of Django. Each major release\nseries has its own stable branch.
\nThese branches can be found in the repository as stable/A.B.x\nbranches and will be created right after the first alpha is tagged.
For example, immediately after Django 1.5 alpha 1 was tagged, the branch\nstable/1.5.x was created and all further work on preparing the code for the\nfinal 1.5 release was done there.
These branches also provide bugfix and security support as described in\nSupported versions.
\nFor example, after the release of Django 1.5, the branch stable/1.5.x\nreceives only fixes for security and critical stability bugs, which are\neventually released as Django 1.5.1 and so on, stable/1.4.x receives only\nsecurity and data loss fixes, and stable/1.3.x no longer receives any\nupdates.
Each Django release is tagged and signed by the releaser.
\nThe tags can be found on GitHub’s tags page.
\nFeature-development branches tend by their nature to be temporary. Some\nproduce successful features which are merged back into Django’s main branch to\nbecome part of an official release, but others do not; in either case, there\ncomes a time when the branch is no longer being actively worked on by any\ndeveloper. At this point the branch is considered closed.
\nDjango used to be maintained with the Subversion revision control system, that\nhas no standard way of indicating this. As a workaround, branches of Django\nwhich are closed and no longer maintained were moved into attic.
A number of tags exist under the archive/ prefix to maintain a reference to\nthis and other work of historical interest.
The following tags under the archive/attic/ prefix reference the tip of\nbranches whose code eventually became part of Django itself:
boulder-oracle-sprint: Added support for Oracle databases to\nDjango’s object-relational mapper. This has been part of Django\nsince the 1.0 release.
gis: Added support for geographic/spatial queries to Django’s\nobject-relational mapper. This has been part of Django since the 1.0\nrelease, as the bundled application django.contrib.gis.
i18n: Added internationalization support to\nDjango. This has been part of Django since the 0.90 release.
magic-removal: A major refactoring of both the internals and\npublic APIs of Django’s object-relational mapper. This has been part\nof Django since the 0.95 release.
multi-auth: A refactoring of Django’s bundled\nauthentication framework which added support for\nauthentication backends. This has\nbeen part of Django since the 0.95 release.
new-admin: A refactoring of Django’s bundled\nadministrative application. This became part of\nDjango as of the 0.91 release, but was superseded by another\nrefactoring (see next listing) prior to the Django 1.0 release.
newforms-admin: The second refactoring of Django’s bundled\nadministrative application. This became part of Django as of the 1.0\nrelease, and is the basis of the current incarnation of\ndjango.contrib.admin.
queryset-refactor: A refactoring of the internals of Django’s\nobject-relational mapper. This became part of Django as of the 1.0\nrelease.
unicode: A refactoring of Django’s internals to consistently use\nUnicode-based strings in most places within Django and Django\napplications. This became part of Django as of the 1.0 release.
Additionally, the following tags under the archive/attic/ prefix reference\nthe tips of branches that were closed, but whose code was never merged into\nDjango, 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\nsoc20XX/<project> tags referencing the tip of branches that were used by\nstudents who worked on Django during the 2009 and 2010 Google Summer of Code\nprograms.