---
title: "Le dépôt de code source de Django"
version: 3.0
locale: fr
source: https://docs.djangoproject.com/fr/3.0/internals/git/
canonical: https://djangodocs.dev/fr/3.0/internals/git/
---
# Le dépôt de code source de Django

Lors du déploiement d’une application Django dans un environnement de production réel, il est pratiquement toujours indiqué d’utiliser une [version officiellement empaquetée de Django](https://www.djangoproject.com/download/).

Cependant, si vous souhaitez essayer du code en cours de développement d’une version à venir ou contribuer au développement de Django, vous aurez besoin d’accéder au dépôt du code source de Django.

Ce document présente la façon dont le dépôt de code est organisé et comment vous pouvez travailler avec lui et y faire des recherches.

## Aperçu général

Le dépôt du code source de Django utilise [Git](https://git-scm.com/) pour suivre l’évolution du code à travers le temps, il est donc nécessaire de disposer d’une copie du client Git (programme nommé `git`) sur votre ordinateur, et il est conseillé de vous familiariser quelque peu avec les bases du fonctionnement de Git.

Le site Web de Git offre des téléchargements pour différents systèmes d’exploitation. Le site contient aussi une grande quantité de [documentation](https://git-scm.com/documentation).

Le dépôt Git de Django est accessible en ligne sur [github.com/django/django](https://github.com/django/django). Il contient le code source complet de toutes les versions de Django que vous pouvez parcourir en ligne.

Le dépôt Git comprend plusieurs [branches](https://github.com/django/django/branches):

- `master` contient le code en développement principal qui est appelé à devenir la prochaine version publiée de Django. C’est là que la plupart des activités de développement ont lieu.
- `stable/A.B.x` sont les branches dans lesquelles se préparent les prochaines publications. Elles sont également utilisées pour les publications correctives et de sécurité qui sont produites en fonction des besoins à la suite de la publication initiale d’une version majeure.

Le dépôt Git contient aussi des étiquettes ([tags](https://github.com/django/django/tags)). Il s’agit de versions figées à partir desquelles des versions de Django ont été produites depuis la version 1.0.

Un certain nombre de « tags » existent aussi sous le préfixe `archive/` pour des [travaux archivés](#archived-feature-development-work).

Le code source du site Web [Djangoproject.com](https://www.djangoproject.com/) se trouve à l’adresse [github.com/django/djangoproject.com](https://github.com/django/djangoproject.com).

## La branche principale `master`

Si vous souhaitez tester le code en cours de développement de la prochaine version de Django ou si vous aimeriez contribuer à Django en corrigeant des anomalies ou en développant de nouvelles fonctionnalités, vous aurez besoin d’obtenir le code de la branche `master`.

Notez que vous obtiendrez *la totalité* de Django : en plus du module \` django\` au premier niveau contenant le code Python, vous obtiendrez aussi une copie de la documentation de Django, la suite de tests, les scripts d’empaquetage et d’autres éléments divers. Le code de Django sera présent dans votre clone sous forme d’un répertoire nommé `django`.

Pour tester le code en cours de développement avec vos propres applications, placez le répertoire contenant votre clone dans le chemin d’importation Python. De ce fait, les instructions `import` recherchant Django vont trouver le module `django` de votre clone du code.

Si vous avez l’intention de travailler sur le code de Django (correction d’anomalie ou développement de fonctionnalités), vous pouvez probablement arrêter de lire cette page et passer à la [documentation de contribution à Django](/fr/3.0/internals/contributing/), qui couvre des sujets comme le style de codage préféré ou sur la façon de produire et soumettre un correctif.

## Les branches stables

Django utilise des branches pour préparer les nouvelles publications de Django. Chaque publication majeure possède sa propre branche stable.

Ces branches se trouvent dans le dépôt sous la forme de branches `stable/A.B.x` et sont créées à partir du moment où la première version alpha d’une nouvelle série est étiquetée.

Par exemple, immédiatement après que *Django 1.5 alpha 1* a été produite, la branche `stable/1.5.x` a été créée et toute la suite de travail de préparation de code pour la version 1.5 finale a eu lieu dans celle-ci.

Ces branches sont aussi la source des versions correctives et de sécurité telles que décrites dans [Versions prises en charge](/fr/3.0/internals/release-process/#supported-versions-policy).

Par exemple, après la publication de Django 1.5, la branche `stable/1.5.x` ne reçoit plus que des corrections de sécurité ou d’anomalies jugées critiques pour sa stabilité, qui sont alors publiées comme Django 1.5.1 et ainsi de suite. La branche `stable/1.4.x` ne reçoit plus que des corrections de sécurité ou d’anomalies générant des pertes de données, alors que `stable/1.3.x` ne reçoit plus aucune mise à jour.

> **Information historique**
>
> Cette politique de gestion des branches `stable/A.B.x` a été adoptée à partir du cycle de publication de Django 1.5.
>
> Précédemment, ces branches n’étaient créées que juste après les publications et le travail de stabilisation se faisait dans la branche principale du dépôt. De ce fait, aucun développement de nouvelle fonctionnalité pour la prochaine publication de Django ne pouvait être commité avant la publication finale en cours.
>
> 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.

## Étiquettes (`tags`)

Chaque version de Django est étiquetée et signée par la personne qui a produit la version.

Les étiquettes sont accessibles sur la page [tags](https://github.com/django/django/tags) de GitHub.

### Développements de fonctionnalités archivés

> **Information historique**
>
> Depuis que Django a passé à Git en 2012, tout le monde peut clôner le dépôt et créer ses propres branches, ce qui rend caduque la nécessité de créer des branches officielles dans le dépôt du code source.
>
> La section suivante est surtout utile si vous explorez l’historique du dépôt, par exemple si vous essayez de comprendre comment certaines fonctionnalités ont été développées.

Feature-development branches tend by their nature to be temporary. Some
produce successful features which are merged back into Django’s master 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`: Added support for Oracle databases to
  Django’s object-relational mapper. This has been part of Django
  since the 1.0 release.
- `gis`: Added support for geographic/spatial queries to Django’s
  object-relational mapper. This has been part of Django since the 1.0
  release, as the bundled application `django.contrib.gis`.
- `i18n`: Added [internationalization support](/fr/3.0/topics/i18n/) to
  Django. This has been part of Django since the 0.90 release.
- `magic-removal`: A major refactoring of both the internals and
  public APIs of Django’s object-relational mapper. This has been part
  of Django since the 0.95 release.
- `multi-auth`: A refactoring of [Django’s bundled
  authentication framework](/fr/3.0/topics/auth/) which added support for
  [authentication backends](/fr/3.0/topics/auth/customizing/#authentication-backends). This has
  been part of Django since the 0.95 release.
- `new-admin`: A refactoring of [Django’s bundled
  administrative application](/fr/3.0/ref/contrib/admin/). This became part of
  Django as of the 0.91 release, but was superseded by another
  refactoring (see next listing) prior to the Django 1.0 release.
- `newforms-admin`: The second refactoring of Django’s bundled
  administrative application. This became part of Django as of the 1.0
  release, and is the basis of the current incarnation of
  `django.contrib.admin`.
- `queryset-refactor`: A refactoring of the internals of Django’s
  object-relational mapper. This became part of Django as of the 1.0
  release.
- `unicode`: A refactoring of Django’s internals to consistently use
  Unicode-based strings in most places within Django and Django
  applications. This became part of Django as of the 1.0 release.

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.