Cuando despliegues una aplicación de Django en un entorno de producción real, casi siempre querrás utilizar una versión paquetizada oficial de Django.
Sin embargo, si deseas probar el código en desarrollo de una próxima versión o contribuir al desarrollo de Django, necesitarás obtener una copia del repositorio del código fuente de Django.
Este documento cubre la forma en que está organizado el repositorio del código y cómo trabajar con él y encontrar cosas en él.
El repositorio del código fuente de Django utiliza Git para rastrear los cambios en el código con el tiempo, por lo que necesitarás una copia del cliente Git (un programa llamado git) en tu computadora y familiarizarte con los fundamentos de cómo funciona Git.
El sitio web de Git ofrece descargas para varios sistemas operativos. El sitio también contiene vastas cantidades de documentación.
El repositorio Git de Django se encuentra en línea en github.com/django/django. Contiene el código fuente completo para todas las versiones de Django, que puedes explorar en línea.
El repositorio Git incluye varias ramas:
main contiene el código principal en desarrollo que se convertirá en la próxima versión empaquetada de Django. Este es donde se centra la mayor parte de la actividad de desarrollo.
stable/A.B.x son las ramas donde ocurre el trabajo de preparación de versiones. También se utilizan para correcciones de errores y lanzamientos de seguridad que ocurren según sea necesario después del lanzamiento inicial de una versión de características.
El repositorio Git también contiene etiquetas. Estos son las revisiones exactas desde las cuales se produjeron las versiones empaquetadas de Django, a partir de la versión 1.0.
Un número de etiquetas también existen bajo el prefijo archive/ para trabajo archivado.
El código fuente del sitio web Djangoproject.com se puede encontrar en github.com/django/djangoproject.com.
Si deseas probar el código en desarrollo para la próxima versión de Django, o si deseas contribuir a Django mediante la corrección de errores o el desarrollo de nuevas características, necesitarás obtener el código desde la rama principal.
Nota
Hasta marzo de 2021, la rama principal se llamaba master.
Note que esto obtendrá todo de Django: además del módulo principal django que contiene código Python, también obtendrás una copia de la documentación de Django, el conjunto de pruebas, los scripts de empaquetado y otros bits misceláneos. El código de Django estará presente en tu clon como un directorio llamado django.
Para probar el código en desarrollo con tus propias aplicaciones, coloca el directorio que contiene tu clon en la ruta de importación de Python. Luego, las declaraciones de importación que buscan Django encontrarán el módulo django dentro de tu clon.
Si vas a trabajar en el código de Django (por ejemplo, para corregir un bug o desarrollar una nueva característica), probablemente puedas detenerte aquí y pasar a la documentación sobre contribución a Django, que cubre cosas como el estilo de codificación preferido y cómo generar y enviar un parche.
Django utiliza ramas para prepararse para las versiones de Django. Cada serie de lanzamientos mayor tiene su propia rama estable.
Estas ramas se pueden encontrar en el repositorio como stable/A.B.x y se crearán justo después de que se etiquete la primera alpha.
Por ejemplo, inmediatamente después de que se etiquetó Django 1.5 alpha 1, se creó la rama stable/1.5.x y todo el trabajo posterior para preparar el código para el lanzamiento final de Django 1.5 se hizo allí.
Estas ramas también proporcionan soporte a bugfix y seguridad según lo descrito en Versiones soportadas.
Por ejemplo, después del lanzamiento de Django 1.5, la rama stable/1.5.x recibe solo fijaciones para seguridad y bugs críticos de estabilidad, que eventualmente se liberan como Django 1.5.1 y así sucesivamente, stable/1.4.x recibe solo fijaciones de seguridad y pérdida de datos, y stable/1.3.x ya no recibe actualizaciones.
Información histórica
Esta política para manejar las ramas stable/A.B.x fue adoptada a partir del ciclo de lanzamiento de Django 1.5.
Anteriormente, estas ramas no se creaban hasta justo después de los lanzamientos y el trabajo de estabilización ocurría en la rama principal del repositorio. Por lo tanto, no podían realizarse nuevos trabajos de desarrollo de características para la próxima versión de Django hasta que sucediera el lanzamiento final.
Por ejemplo, poco después del lanzamiento de Django 1.3 se creó la rama stable/1.3.x. El soporte oficial para esa versión ha expirado y ya no recibe mantenimiento directo desde el proyecto Django. Sin embargo, aquella y todas las demás ramas con nombres similares continúan existiendo, y los miembros de la comunidad interesados han utilizado ocasionalmente esas ramas para proporcionar un soporte oficial para versiones antiguas de Django.
Cada lanzamiento de Django está etiquetado y firmado por el responsable del lanzamiento.
Las etiquetas se pueden encontrar en la página tags de GitHub.
Información histórica
Dado que Django pasó a utilizar Git en 2012, cualquier persona puede clonar el repositorio y crear sus propias ramas, lo que alivia la necesidad de ramas oficiales en el repositorio del código fuente.
La siguiente sección es principalmente útil si estás explorando la historia del repositorio, por ejemplo, si intentas entender cómo se diseñaron algunas características.
Las ramas de desarrollo de características tienden a ser temporales por naturaleza. Algunas producen características exitosas que se fusionan nuevamente en la rama principal de Django para convertirse en parte de un lanzamiento oficial, pero otras no lo hacen; en cualquier caso, llega un momento en el que la rama ya no está siendo trabajada activamente por ningún desarrollador. En ese punto, la rama se considera cerrada.
Django se mantenía con el sistema de control de versiones Subversion, que no tiene una forma estándar de indicarlo. Como solución provisional, las ramas de Django que estaban cerradas y ya no se mantenían se movieron a attic.
Existen un número de etiquetas bajo la prefijo archive/ para mantener una referencia a esto y otros trabajos de interés histórico.
Las siguientes etiquetas bajo el prefijo archive/attic/ hacen referencia al extremo de ramas cuyo código eventualmente se convirtió en parte de Django mismo:
boulder-oracle-sprint: Se agregó soporte para bases de datos Oracle a la mapeadora objeto-relacional de Django. Esto ha sido parte de Django desde la versión 1.0.
gis: Se agregó soporte para consultas geográficas/espaciales a la mapeadora objeto-relacional de Django. Esto ha sido parte de Django desde la versión 1.0, como la aplicación embutida django.contrib.gis.
i18n: Se agregó el soporte para internacionalización a Django. Esto ha sido parte de Django desde la versión 0.90.
magic-removal: Una importante refactorización tanto de las internas como de las APIs públicas de la mapeadora objeto-relacional de Django. Esto ha sido parte de Django desde la versión 0.95.
multi-auth: Una refactorización del marco de autenticación embutido de Django que agregó soporte para autenticadores. Esto ha sido parte de Django desde la versión 0.95.
new-admin: Una refactorización del aplicación administrativa embutida de Django. Esta se convirtió en parte de Django a partir de la versión 0.91, pero fue superada por otra refactorización (ver siguiente lista) antes de la versión 1.0 de Django.
newforms-admin: La segunda refactorización de la aplicación administrativa embutida de Django. Esta se convirtió en parte de Django a partir de la versión 1.0, y es la base de la actual encarnación de django.contrib.admin.
queryset-refactor: Una refactorización de la parte interna del mapeador objeto-relacional de Django. Esto se convirtió en parte de Django a partir de la versión 1.0.
unicode: Una refactorización de los internos de Django para utilizar consistentemente cadenas basadas en Unicode en la mayoría de los lugares dentro de Django y las aplicaciones de Django. Esto se convirtió en parte de Django a partir de la versión 1.0.
Además, los siguientes etiquetas con el prefijo archive/attic/ hacen referencia a las cabeceras de ramas que fueron cerradas, pero cuyo código nunca fue integrado en Django, y las características que pretendían implementar nunca estuvieron completas:
full-history
generic-auth
multiple-db-support
per-object-permissions
schema-evolution
schema-evolution-ng
search-api
sqlalchemy
Finalmente, bajo la prefija archive/, el repositorio contiene etiquetas soc20XX/<project> que hacen referencia a la punta de ramas utilizadas por estudiantes que trabajaron en Django durante los programas de verano de código Google de 2009 y 2010.
may 31, 2026