---
title: "O repositório de código-fonte do Django"
version: 5.2
locale: pt-br
source: https://docs.djangoproject.com/pt-br/5.2/internals/git/
canonical: https://djangodocs.dev/pt-br/5.2/internals/git/
---
# 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](https://www.djangoproject.com/download/).

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](https://git-scm.com/) 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](https://git-scm.com/doc).

O repositório do Django no GIt é localizado online em [github.com/django/django](https://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](https://github.com/django/django/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](https://github.com/django/django/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](#archived-feature-development-work).

O código-fonte para o website [Djangoproject.com](https://www.djangoproject.com/) pode ser encontrado em [github.com/django/djangoproject.com](https://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**
>
> Prior to March 2021, the main branch was called `master`.

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](/pt-br/5.2/internals/contributing/), 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](/pt-br/5.2/internals/release-process/#supported-versions-policy).

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.

> **Informação Histórica**
>
> Esta política para manipular branches `stable/A.B.x` foi adotada começando com o ciclo de release da versão Django 1.5.
>
> Previously, these branches weren’t created until right after the releases
> and the stabilization work occurred on the main repository branch. Thus,
> no new feature development work for the next release of Django could be
> committed until the final release happened.
>
> For example, shortly after the release of Django 1.3 the branch
> `stable/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, and
> interested community members have occasionally used them to provide
> unofficial support for old Django releases.

## Tags

Each Django release is tagged and signed by the releaser.

As [tags](https://github.com/django/django/tags) podem ser encontradas na página do GitHub,

### Archived feature-development work

> **Informação Histórica**
>
> Desde que o Django mudou para o Git em 2012, todos podem clocar o repositório e criar suas próprias branches. aliviando a necessidade de branches oficiais no repositório de código-fonte.
>
> A seção seguinte é mais útil se você estiver explorando o histórico do repositório, por exemplo se você está tentando entender como alguma funcionalidade foi desenvolvida.

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](/pt-br/5.2/topics/i18n/) 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](/pt-br/5.2/topics/auth/) que adicionou suporte para [backends de autenticação](/pt-br/5.2/topics/auth/customizing/#authentication-backends). Ela tem sido parte do Django desde a release 0.95.
- `new-admin`: Uma refatoração da [aplicação administrativa embutida no Django](/pt-br/5.2/ref/contrib/admin/). 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.