djangodocs

Django 4.1
Português (Brasil)
Documentation contents

O repositório de código-fonte do Django

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.

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

Este documento cobre a maneira como o repositório de código é estruturado e como trabalhar e encontrar coisas dentro dele.

Visão de alto nível

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

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

O repositório Git inclui várias branches:

  • main contains the main in-development code which will become the next packaged release of Django. This is where most development activity is focused.

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

A number of tags also exist under the archive/ prefix for archived work.

O código-fonte para o website Djangoproject.com pode ser encontrado em github.com/django/djangoproject.com.

The main branch

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

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

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

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.

Branches estáveis

Django uses branches to prepare for releases of Django. Each major release series has its own stable branch.

Essas 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 Versões suportadas.

For example, after the release of Django 1.5, the branch stable/1.5.x receives only fixes for security and critical stability bugs, which are eventually released as Django 1.5.1 and so on, stable/1.4.x receives only security and data loss fixes, and stable/1.3.x no longer receives any updates.

Tags

Each Django release is tagged and signed by the releaser.

As tags podem ser encontradas na página do GitHub,

Archived feature-development work

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

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.

A number of tags exist under the archive/ prefix to maintain a reference to this and other work of historical interest.

The following tags under the archive/attic/ prefix reference the tip of branches 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 the tips of branches that were closed, but whose code was never merged into Django, 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 soc20XX/<project> tags referencing the tip of branches that were used by students who worked on Django during the 2009 and 2010 Google Summer of Code programs.

This page as Markdown JSON

Edit this page on GitHub Official version