När du distribuerar en Django-applikation till en riktig produktionsmiljö vill du nästan alltid använda ”en officiell paketerad version av Django”.
\nMen om du vill prova kod under utveckling från en kommande version eller bidra till utvecklingen av Django, måste du skaffa en klon av Djangos källkodsarkiv.
\nDet här dokumentet beskriver hur kodarkivet är uppbyggt och hur man arbetar med och hittar saker i det.
\nDjangos källkodsarkiv använder Git för att spåra ändringar i koden över tid, så du behöver en kopia av Git-klienten (ett program som heter git) på din dator, och du vill bekanta dig med grunderna i hur Git fungerar.
Gits webbplats erbjuder nedladdningar för olika operativsystem. Webbplatsen innehåller också stora mängder dokumentation.
\nDjangos Git-förvar finns online på github.com/django/django. Den innehåller den fullständiga källkoden för alla Django-versioner, som du kan bläddra i online.
\nGit-förvaret innehåller flera ”grenar”:
\nmain innehåller den huvudsakliga koden under utveckling som kommer att bli nästa paketerade version av Django. Det är här den mesta utvecklingsaktiviteten är fokuserad.
stable/A.B.x är de grenar där arbetet med att förbereda releaser sker. De används också för buggfix- och säkerhetsreleaser som sker vid behov efter den första releasen av en funktionsversion.
Git-förvaret innehåller också tags. Dessa är de exakta revisionerna från vilka paketerade Django-versioner producerades, sedan version 1.0.
\nEtt antal taggar finns också under prefixet archive/ för archived work.
Källkoden för webbplatsen Djangoproject.com finns på github.com/django/djangoproject.com.
\nOm du vill prova den kod som är under utveckling för nästa version av Django, eller om du vill bidra till Django genom att åtgärda buggar eller utveckla nya funktioner, bör du hämta koden från huvudgrenen.
\n\nObservera att detta kommer att få allt av Django: förutom toppnivån django-modulen som innehåller Python-kod, får du också en kopia av Djangos dokumentation, testsvit, förpackningsskript och andra diverse bitar. Djangos kod kommer att finnas i din klon som en katalog med namnet django.
För att prova den kod som är under utveckling med dina egna applikationer, placera katalogen som innehåller din klon på din Python-importväg. Då kommer import-uttalanden som letar efter Django att hitta django-modulen i din klon.
Om du kommer att arbeta med Djangos kod (till exempel för att fixa en bugg eller utveckla en ny funktion) kan du förmodligen sluta läsa här och gå vidare till dokumentationen för att bidra till Django, som täcker saker som den föredragna kodningsstilen och hur man genererar och skickar in en patch.
\nDjango använder grenar för att förbereda sig inför releaser av Django. Varje större release-serie har sin egen stabila gren.
\nDessa grenar finns i arkivet som stable/A.B.x grenar och kommer att skapas direkt efter att den första alfan är taggad.
Till exempel, omedelbart efter att Django 1.5 alpha 1 taggades, skapades grenen stable/1.5.x och allt ytterligare arbete med att förbereda koden för den slutliga 1.5-utgåvan gjordes där.
Dessa grenar ger också stöd för buggfixar och säkerhet enligt beskrivningen i Versioner som stöds.
\nTill exempel, efter lanseringen av Django 1.5 får grenen stable/1.5.x endast korrigeringar för säkerhets- och kritiska stabilitetsbuggar, som så småningom släpps som Django 1.5.1 och så vidare, stable/1.4.x får endast säkerhets- och dataförlustkorrigeringar, och stable/1.3.x får inte längre några uppdateringar.
Varje Django-release är märkt och signerad av releasegivaren.
\nTaggarna finns på GitHubs tags-sida.
\nFunktionsutvecklingsgrenar tenderar av sin natur att vara tillfälliga. Vissa producerar framgångsrika funktioner som slås samman tillbaka till Djangos huvudgren för att bli en del av en officiell utgåva, men andra gör det inte; i båda fallen kommer det en tid då grenen inte längre aktivt arbetas med av någon utvecklare. Vid denna tidpunkt anses grenen vara stängd.
\nDjango brukade underhållas med revisionskontrollsystemet Subversion, som inte har något standardiserat sätt att ange detta. Som en lösning flyttades grenar av Django som är stängda och inte längre underhålls till attic.
Ett antal taggar finns under prefixet archive/ för att upprätthålla en referens till detta och andra verk av historiskt intresse.
Följande taggar under prefixet archive/attic/ refererar till toppen av grenar vars kod så småningom blev en del av Django själv:
boulder-oracle-sprint: Lagt till stöd för Oracle-databaser i Djangos objekt-relationella mappare. Detta har varit en del av Django sedan 1.0-utgåvan.
gis: Lagt till stöd för geografiska/spatiala frågor till Djangos objekt-relationella mappare. Detta har varit en del av Django sedan 1.0-utgåvan, som den medföljande applikationen django.contrib.gis.
i18n: Lade till internationaliseringsstöd till Django. Detta har varit en del av Django sedan 0.90-utgåvan.
magisk-removal: En större refaktorisering av både de interna och publika API:erna i Djangos objekt-relationella mappare. Detta har varit en del av Django sedan 0.95-utgåvan.
multi-auth: En omarbetning av Djangos medföljande autentiseringsramverk som lade till stöd för autentiseringsbackends. Detta har varit en del av Django sedan 0.95-utgåvan.
ny-admin: En refaktorisering av Djangos medföljande administrativa applikation. Detta blev en del av Django från och med 0.91-utgåvan, men ersattes av en annan refaktorisering (se nästa lista) före Django 1.0-utgåvan.
newforms-admin: Den andra refaktoriseringen av Djangos medföljande administrativa applikation. Detta blev en del av Django från och med 1.0-utgåvan och är grunden för den nuvarande inkarnationen av django.contrib.admin.
queryset-refactor: En refaktorisering av de interna delarna av Djangos objekt-relationella mappare. Detta blev en del av Django från och med 1.0-utgåvan.
unicode: En refaktorisering av Djangos interna funktioner för att konsekvent använda Unicode-baserade strängar på de flesta ställen inom Django och Django-applikationer. Detta blev en del av Django från och med 1.0-utgåvan.
Dessutom hänvisar följande taggar under prefixet archive/attic/ till tipsen på grenar som stängdes, men vars kod aldrig slogs samman till Django, och de funktioner som de syftade till att implementera blev aldrig färdiga:
full-historia
generisk-auth
stöd för flera databaser
per-objekt-behörigheter
schema-evolution
schema-evolution-ng
search-api
sqlalchemy
Slutligen, under prefixet archive/, innehåller arkivet soc20XX/<project> taggar som refererar till spetsen på grenar som användes av studenter som arbetade med Django under 2009 och 2010 års Google Summer of Code-program.