Quando estiver fazendo deploy de uma aplicação Django em um ambiente de produção real, você quase sempre vai querer usar uma release do Django oficial.
\nEntretanto, se você quiser tentar o código em desenvolvimento de uma próxima release ou contribuir para o desenvolvimento do Django, você terá que obter um clone do repositório de código-fonte do Django.
\nEste documento cobre a maneira como o repositório de código é estruturado e como trabalhar e encontrar coisas dentro dele.
\nO repositório de código-fonte do Django usa Git para rastrear mudanças no código durante o tempo, então você vai precisar de uma cópia do client do Git (um programa chamado git) no seu computador, e você quer familiarizar-se com o básico de como o Git trabalha.
O website do Git oferece download para vários sistemas operacionais. O site ainda contém vastas quantias de documentation.
\nO repositório do Django no GIt é localizado online em github.com/django/django. Ele contém todo o código-fonte para todas as releases do Django, que você pode navegar online.
\nO repositório Git inclui várias branches:
\nmaster contém o principal código em desenvolvimento e que se tornará a próxima versão de release do Django. Esse é o lugar onde a maior parte do atividade de desenvolvimento é realizada.
stable/A.B.x são branches onde o trabalho de preparação de release acontece. Elas também são usadas para correção de bugs e releases de segurança que ocorrem a depender da necessidade depois que a versão final.
O repositório Git que contém as tags. Essas são as revisões exatas das quais as releases do Django foram produzidas, desde a versão 1.0.
\nA number of tags also exist under the archive/ prefix for archived\nwork.
O código-fonte para o website Djangoproject.com pode ser encontrado em github.com/django/djangoproject.com.
\nSe você gostaria de testar o código em desenvolvimento da próxima versão do Django, ou se você gostaria de contribuir para o Django corrigindo bugs ou desenvolvendo novas funcionalidades, você vai querer pegar o código da master branch.
\nNote que isso irá pegar tudo do Django: além do módulo django contendo código Python, você irá também pegar uma cópia da documentação do Django, suíte de testes, scripts e outras coisas gerais. O código Django irá ser apresentado em seu clone como um diretório chamado django.
Para testar o código de desenvolvimento com suas próprias aplicações, simplesmente coloque o diretório contendo o seu clone no seu Python import path. Então os comandos import que procuram pelo Django irão encontrar o módulo django dentro do seu clone.
Se você estará trabalhando no código do Django (por exemplo, para corrigir bugs ou desenvolver uma nova funcionalidade), você pode provavelmente para de ler aqui e ir para a documentação para contribuições no Django, que cobre coisas como o estilo preferido de código e como gerar e submeter um patch.
\nDjango uses branches to prepare for releases of Django. Each major release\nseries has its own stable branch.
\nEssas branches podem ser encontradas dentro das branches stable/A.B.x e serão criadas após realização de tag da primeira versão alpha.
Por exemplo, imediatamente após o tag da versão Django 1.5 alpha 1, a branch stable/1.5.x foi criada e todo o trabalho seguinte na preparação do código para a release final 1.5 foi feita nela.
These branches also provide bugfix and security support as described in\nVersões suportadas.
\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.
\nAs tags podem ser encontradas na página do GitHub,
\nFeature-development branches tend by their nature to be temporary. Some\nproduce successful features which are merged back into Django’s master 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: Adicionou suporte para os bancos de dados Oracle no ORM do Django. Ela tem sido parte do Django desde a release 1.0.
gis: Adiciona suporte para consultas geográficas/espaciais no ORM do Django. Ela tem sido parte do Django desde a release 1.0, foi embutida na aplicação django.contrib.gis.
i18n: Adiciona suporte a internacionalização ao Django. Ela tem sido parte do Django desde a relase 0.90.
magic-removal: Uma refatoração massiva tanto da API privada quanto da API pública do ORM do Django. Ela tem sido parte do Django desde a release 0.95.
multi-auth: Uma refatoração do framework de autenticação embutido no Django que adicionou suporte para backends de autenticação. Ela tem sido parte do Django desde a release 0.95.
new-admin: Uma refatoração da aplicação administrativa embutida no Django. Ela tem sido parte do Django desde a release 0.91, mas substituída foi por outra refatoração (veja a próxima listagem) antes da release do Django 1.0.
newforms-admin: A segunda refatoração da aplicação administrativa embutida no Django. Ela se tornou parte do Django na release 1.0, e é a base da encarnação atual do django.contrib.admin.
queryset-refactor: Uma refatoração das entranhas do ORM do Django. Ela se tornou parte do Django na release 1.0.
unicode: Uma refatoração das entranhas do Django para uso consistente de strings baseadas em Unicode e mais locais dentro do Django e de aplicações Django. Ela se tornou parte do Django na release 1.0.
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.