Репозиторий исходного кода Django ¶
При развертывании приложения Django в реальной производственной среде почти всегда рекомендуется использовать официально упакованную версию Django .
Однако, если вы хотите опробовать разрабатываемый код для предстоящего выпуска или внести свой вклад в разработку Django, вам потребуется доступ к репозиторию исходного кода Django.
В этом документе показано, как организовано хранилище кода, и как с ним можно работать и исследовать.
Обзор ¶
Репозиторий исходного кода Django использует Git для отслеживания эволюции кода с течением времени, поэтому необходимо иметь копию клиента Git (названную программу git ) на вашем компьютере, и вам рекомендуется с чем-то ознакомиться. немного с основами работы Git.
Веб-сайт Git предлагает загрузки для различных операционных систем. На сайте также есть большой объем документации .
Репозиторий Git Django можно получить в Интернете по адресу github.com/django/django . Он содержит полный исходный код для всех версий Django, которые вы можете просматривать в Интернете.
Репозиторий Git имеет несколько веток :
masterсодержит основной код разработки, который должен стать следующей выпущенной версией Django. Здесь происходит большая часть разработок.stable/A.B.x- это отрасли, в которых готовятся следующие публикации. Они также используются для исправлений и выпусков безопасности, которые создаются по мере необходимости после первоначального выпуска основного выпуска.
Репозиторий Git также содержит теги . Это замороженные версии, из которых были созданы версии Django, начиная с версии 1.0.
Ряд «тегов» также существует под префиксом archive/ для заархивированных заданий .
Исходный код веб- сайта Djangoproject.com можно найти на github.com/django/djangoproject.com .
Основная ветка master ¶
Если вы хотите протестировать разрабатываемый код для следующей версии Django, или если вы хотите внести свой вклад в Django, исправляя ошибки или разрабатывая новые функции, вам необходимо получить код из ветки master .
Обратите внимание, что вы получите Django целиком : в дополнение к модулю `django` первого уровня, содержащему код Python, вы также получите копию документации Django, тестового набора, сценариев упаковки и прочего. различный. Код Django будет представлен в вашем клоне как именованный каталог django .
Чтобы протестировать разрабатываемый код с вашими собственными приложениями, поместите каталог, содержащий ваш клон, в путь импорта Python. Следовательно, инструкции import по поиску Django найдут модуль django для вашего клонированного кода.
Если вы планируете работать над кодом Django (исправление ошибок или разработка функций), вы, вероятно, можете перестать читать эту страницу и перейти к документации Django , которая охватывает такие темы, как стили. предпочтительное кодирование или о том, как произвести и отправить исправление.
Стабильные ветви ¶
Django использует ветки для подготовки новых выпусков Django. У каждого крупного издания есть своя стабильная ветка.
Эти ветки находятся в репозитории как ветки stable/A.B.x и создаются с момента пометки первой альфа-версии новой серии.
Например, сразу после создания Django 1.5 alpha 1 ветка stable/1.5.x была создана, и в ней проходила вся остальная работа по подготовке кода для финальной версии 1.5.
Эти ветки также являются источником исправлений и выпусков безопасности, как описано в разделе Поддерживаемые версии .
Например, после выпуска Django 1.5 ветка stable/1.5.x получает только исправления безопасности или ошибок, которые считаются критическими для ее стабильности, которые затем выпускаются как Django 1.5.1 и так далее. Филиал stable/1.4.x получает только исправления безопасности или аномалии, приводящие к потере данных, но stable/1.3.x больше не получает никаких обновлений.
Историческая справка
Эта политика управления ветвями stable/A.B.x была заимствована из цикла выпуска Django 1.5.
Раньше эти ветки создавались только сразу после постов, а работа по стабилизации проводилась в ветке основного репозитория. Следовательно, разработка каких-либо новых функций для следующего выпуска Django не может быть завершена до текущего финального выпуска.
Например, вскоре после выпуска Django 1.3 ветка
stable/1.3.x была создана. Официальная поддержка этого выпуска истекла, поэтому он больше не получает прямого обслуживания от проекта Django. Однако эта и все другие ветки с аналогичными названиями продолжают существовать, и заинтересованные члены сообщества иногда использовали их для обеспечения неофициальной поддержки старых выпусков Django.
Этикетки ( tags ) ¶
Каждая версия Django помечена и подписана лицом, создавшим версию.
Теги доступны на странице тегов GitHub.
Архивные разработки функций ¶
Историческая справка
С тех пор, как Django перешел на Git в 2012 году, любой может клонировать репозиторий и создавать свои собственные ветки, избавляя от необходимости создавать официальные ветки в репозитории исходного кода.
Следующий раздел особенно полезен, если вы изучаете историю репозитория, например, если вы пытаетесь понять, как были разработаны определенные функции.
Ветви разработки функций по своей природе имеют тенденцию быть временными. Некоторые создают успешные функции, которые снова объединяются в мастер Django, чтобы стать частью официального выпуска, а другие - нет; в любом случае наступает время, когда над веткой больше не ведется активная работа со стороны какого-либо разработчика. На данный момент филиал считается закрытым.
Раньше Django поддерживался системой контроля версий Subversion, в которой нет стандартного способа указать это. В качестве обходного пути ветки Django, которые закрыты и больше не обслуживаются, были перемещены в attic .
Под archive/ префиксом существует ряд тегов для поддержки ссылки на эту и другие работы, представляющие исторический интерес.
Следующие теги под archive/attic/ префиксом ссылаются на кончики веток, код которых в конечном итоге стал частью самого Django:
boulder-oracle-sprint: Добавлена поддержка баз данных Oracle в объектно-реляционный преобразователь Django. Это было частью Django с момента выпуска 1.0.gis: Добавлена поддержка географических / пространственных запросов в объектно-реляционный картограф Django. Это было частью Django с момента выпуска 1.0 в виде связанного приложенияdjango.contrib.gis.i18n: Добавлена поддержка интернационализации в Django. Это было частью Django с момента выпуска 0.90.magic-removal: Существенный рефакторинг как внутренних, так и общедоступных API объектно-реляционного картографа Django. Это было частью Django с момента выпуска 0.95.multi-auth: Рефакторинг интегрированной платформы аутентификации Django, которая добавила поддержку бэкэндов аутентификации . Это было частью Django с момента выпуска 0.95.new-admin: Рефакторинг связанного административного приложения Django . Он стал частью Django с выпуска 0.91, но был заменен другим рефакторингом (см. Следующий листинг) до выпуска Django 1.0.newforms-admin: Второй рефакторинг административного приложения Django. Он стал частью Django начиная с версии 1.0 и является основой текущего воплощенияdjango.contrib.admin.queryset-refactor: Рефакторинг внутреннего устройства объектно-реляционного картографа Django. Это стало частью Django с выпуском 1.0.unicode: Реорганизация внутреннего устройства Django для последовательного использования строк на основе Unicode в большинстве мест в приложениях Django и Django. Это стало частью Django с выпуском 1.0.
Кроме того, следующие теги под archive/attic/ префиксом ссылаются на кончики веток, которые были закрыты, но код которых никогда не был объединен с Django, а функции, которые они намеревались реализовать, так и не были завершены:
full-historygeneric-authmultiple-db-supportper-object-permissionsschema-evolutionschema-evolution-ngsearch-apisqlalchemy
Наконец, под archive/ префиксом репозиторий содержит
soc20XX/<project> теги, ссылающиеся на кончики веток, которые использовались студентами, которые работали над Django в программах Google Summer of Code 2009 и 2010 годов.