Перейти к основному содержанию
Общий набор советов по форкингу и agreed upon best practices от разработчиков форков. Если вы разработчик форка и хотите добавить что-то сюда, пожалуйста, откройте PR. Настоятельно рекомендуется иметь некоторый опыт работы с SS14 и RT перед созданием собственного форка. Этот документ описывает только технические аспекты форкинга. Имейте в виду, что любой хороший форк потребует команду администраторов и политики.

​
Создание репозитория

Вам не следует создавать репозиторий вашего проекта с помощью кнопки fork на GitHub. Это потому, что GitHub разрешает только один форк репозитория на аккаунт, и форки вашего репозитория будут считаться так же, как форки вашего upstream. Кроме того, когда у вас есть репозиторий, форкнутый через кнопку fork, очень легко случайно отправить изменения в ваш upstream. Вместо этого сделайте следующее:
  • Создайте пустой репозиторий, либо в организации, либо в вашем аккаунте. Не инициализируйте репозиторий начальным коммитом; оставьте его пустым.
  • git clone репозиторий upstream, от которого вы хотите форкнуться (если у вас уже есть локальная копия, можете использовать её)
  • git remote add YourFork github.com/YourOrg/YourRepo чтобы добавить ваш пустой репозиторий как remote
  • git checkout желаемую удалённую ветку. Если вы базируетесь на Wizard’s Den, настоятельно рекомендуется базировать форк на stable.
    • git fetch upstream stable (предполагая, что remote, указывающий на репозиторий, от которого вы хотите форкнуться, называется upstream)
    • git checkout upstream/stable
  • git push YourFork master чтобы отправить это в ваш форк как ветку master.
Поздравляю, вы успешно создали форк! Чтобы обновлять форк в будущем, делайте следующее:
  • Создайте новую ветку на основе последнего коммита вашего форка
  • git fetch вашей желаемой upstream ветки, как указано выше
  • Затем git pull.
Продолжая пример с mainline stable, команды для вышеуказанного будут:
  • git fetch upstream stable
  • git pull upstream stable
  • Исправьте конфликты слияния, если необходимо, и создайте PR с вашей свежей веткой слияния upstream
  • Если вы не хотите какую-то функцию из upstream, сейчас самое время откатить изменение с помощью git revert
Обратите внимание, что любые контрибьюторы вашего форка должны будут нажать кнопку fork на GitHub на вашем репозитории, а не на upstream.

​
Лицензирование вашего форка

Информация, написанная в этом документе, не должна рассматриваться как юридическая консультация и не должна использоваться как таковая.УБЕДИТЕСЬ, ЧТО ВЫ ПРОЧИТАЛИ И ПОНЯЛИ ЛИЦЕНЗИЮ ВСЕХ ФАЙЛОВ В ВАШЕМ ФОРКЕ.
Если вы не сильны в лицензиях на открытое ПО, мы рекомендуем лицензировать ваш форк под той же лицензией, что и ваш upstream. Это вызовет у вас наименьшее количество юридических проблем (или, скорее, общих споров). Wizard’s Den использует лицензию «MIT License» (иногда называемую лицензией Expat). Копия этой лицензии уже включена в репозиторий и не требует от вас никаких действий для её использования. Лицензия MIT даёт вам право делать почти всё что угодно с кодом (включая сублицензирование), если сохранена копия уведомления об авторских правах. Большинство художественных ресурсов лицензированы исключительно под CC BY-SA 3.0 или CC BY-NC-SA 3.0. Для последней NC означает «non-commercial»: следовательно, любые ресурсы, лицензированные под ней, не могут использоваться в коммерческих проектах; вам придётся либо удалить эти ресурсы, либо получить их перелицензирование владельцем для разрешения коммерческого использования. Имейте в виду, что при портировании контента из других форков у них могут быть более строгие лицензии, такие как GNU Affero General Public License (AGPL) или Mozilla Public License (MPL). Будьте осторожны и соблюдайте ограничения, налагаемые этими лицензиями. Лицензии AGPL и MPL являются «copyleft» лицензиями, что означает, что они требуют, чтобы любые модификации вашего кода были выпущены под той же лицензией. AGPL требует, чтобы результирующий бинарный файл вашего проекта был лицензирован под AGPL, что означает, что каждый пользователь имеет право на копию всего исходного дерева. Это мешает вам иметь скрытый контент. AGPL-код может быть лицензирован двумя способами: AGPL-3.0-only или AGPL-3.0-or-later. Разница в том, что AGPL-3.0-or-later код будет лицензирован под любой будущей версией AGPL, опубликованной Free Software Foundation. У MPL нет опции «v2 only»; ваша лицензия всегда будет последней версией, опубликованной Mozilla. MPL требует только, чтобы файлы под лицензией MPL были доступны пользователям, что делает её подходящей для проектов, включающих скрытый контент. Обратите внимание, что у MPL есть опциональное условие под названием «Exhibit B». Код, лицензированный под MPL с условием Exhibit B, не может быть объединён с кодом, лицензированным под AGPL. Помните, что этот документ предоставляет очень краткий обзор обсуждаемых лицензий. Вы должны прочитать лицензию любых файлов/кода, которые намереваетесь включить, полностью и проконсультироваться с юристом, если у вас есть вопросы.

​
Организация

​
Размещайте свой код в специальных серверных папках.

Настоятельно рекомендуется помещать код вашего сервера (вместе с опциональным, но рекомендуемым файлом LICENSE, содержащим лицензию вашего кода) в собственную папку верхнего уровня в основных разделах кодовой базы. Например, во всех папках Content.* будет папка _ServerNameHere, в которой будет размещаться весь специфичный для вашего сервера код. Избегайте смешивания вашего кода с кодом upstream в этом отношении, чтобы избежать потенциальных конфликтов слияния в будущем.

​
Используйте namespace для ваших компонентов (и любых других сериализуемых типов)

Все сериализуемые типы находятся в одном глобальном namespace. Чтобы предотвратить конфликты, вы должны добавлять к ним префикс с коротким идентификатором вашего форка. Например, если ваш сервер называется «Foo Bar», вы можете добавить префикс «FB» ко всем компонентам. Держите его коротким, потому что вы будете много его печатать.

​
Используйте namespace для ваших prototypes

Аналогично именованию сериализуемых типов, prototypes также имеют единый глобальный namespace. Настоятельно рекомендуется давать всем именам prototypes префикс для избежания конфликтов. Например, можно дать сущности ID FooMyEntity вместо MyEntity, если сокращение вашего сервера — «foo».

​
Конфликты слияния не так страшны.

Короче говоря, при модификации существующего кода методы предотвращения конфликтов обычно являются плохой практикой, так как они часто позволяют вашему коду продолжать компилироваться ценой того, что он на самом деле больше не работает корректно. В целом, если у вас возник конфликт слияния, он вряд ли возник без причины, и вы должны просмотреть его вручную, вместо того чтобы пытаться использовать методы предотвращения.
Хотя это в основном правда, избегание конфликтов в, скажем, списках элементов, обычно является хорошей идеей (так как они будут конфликтовать без необходимости чаще, чем нет). Обычно это так же просто, как поместить ваши записи в начало списка или в отдельную часть списка, разделённую пробелами.
При модификации кода upstream рекомендуется оставлять краткий комментарий, объясняющий почему было сделано изменение, чтобы облегчить слияние с upstream. Пример: // FOOFORK: Changed Bar to 2 instead of 1 because everything breaks if it is 1.

​
Избегание проблем в shared enums.

Хороший пример — enum AdminLog, содержащий все виды логов администратора. Выберите узнаваемый десятичный (или шестнадцатеричный) префикс, положительный или отрицательный, для ваших значений и придерживайтесь его. В идеале выберите случайный, чтобы у вас не было проблем при слиянии изменений других форков, если вы захотите взять их изменения.

​
CVars

​
Используйте namespace для ваших CVars!

CVars могут быть любой глубины вложенности таблиц, например foo.respawn.time — это допустимый ключ CVar, который будет соответствовать следующему: 
[foo.respawn]
time = 360
Это помогает устранить неоднозначность происхождения CVar. Кроме того, рассмотрите возможность переноса любых CVar, в которые вы вносите значительные изменения в поведение (например, добавление новых макетов UI или изменение ключей enum), в ваш префикс.

​
Используйте собственные CVarDefs вместо CCVars

Главный класс CCVars — это некий антипаттерн даже в upstream. Вы можете объявлять новые классы CVarDef в любом месте и размещать ваши CVars там вместо CCVars. Например: 
[CVarDefs]
public static class MySubsystemCVars
{
    /// <summary>
    ///     This is my CVar!
    /// </summary>
    public readonly static CVarDef<bool> MyCVar = CVarDef.Create("foofork.subtable.mycvar", false);
}
Возможно, целесообразно иметь CVarDefs на каждую крупную подсистему; например, вы поместите CVar генерации мира в ту же папку, что и код worldgen. Имя статического класса не имеет значения. Вы можете поместить класс CVarDefs только в клиент или только в сервер, но имейте в виду, что это приведёт к записи CVar как отсутствующего, если он окажется в конфигурационном файле, загружаемом обеими сторонами.

​
НУЖНО редактировать значения по умолчанию в коде!

Может возникнуть соблазн изменить или ввести пресет конфигурации для изменения значений CCVars по умолчанию без редактирования самого класса. Это отчасти подпадает под пункт Конфликты слияния не так страшны; делая так, вы рискуете тем, что upstream изменит значение по умолчанию значимым образом (например, изменит, что представляет собой число, например минуты на секунды или наоборот), и вы получите баг на production, если это останется незамеченным. Конфликты пытаются вам что-то сказать, если они происходят.

​
Но не делайте значения по умолчанию специфичными для сервера.

CCVars — это не конфигурационный файл вашего сервера. Настройте ваш сервер в server_config.toml, а не в кодовой базе. Изменяйте значения по умолчанию, если значение по умолчанию ломает игру, отключает механику, которую вы хотите отключить, или нарушает ваш дизайн, а не для установки вашей ссылки на Discord.

​
Структура базы данных

EFCore на самом деле не предназначен для использования так, как вы будете его использовать как разработчик форка. Если вы можете избежать изменений БД, вам следует это сделать. Чтобы избежать ряда багов (в первую очередь этого), настоятельно рекомендуется не изменять таблицы вашего upstream. Вместо этого сделайте соответствующую таблицу для данных вашего форка, которая находится в отношении один к одному с оригинальной таблицей. Любые миграции, которые вы добавляете, должны быть именованы так же, как prototypes и компоненты. Хотя вероятность коллизии миграций практически нулевая, это проясняет, какие миграции были добавлены вашим форком. Наконец, убедитесь, что вы тестируете свои изменения и миграции как на postgres, так и на sqlite, чтобы избежать потери данных. Не забывайте регулярно делать резервные копии вашей базы данных.
Последнее изменение 21 июня 2026 г.