EnRuУпрощ. EnУпрощ. Ru
Черновики

Глава 8: Ветки — Управление параллельными реальностями

Новые идеи в этой главе

  • Ветки как изолированные рабочие пространства: Мы представляем ветки как параллельные, изолированные среды в одной базе данных. Они позволяют командам экспериментировать, разрабатывать и тестировать новые функции, не нарушая стабильность основной (main) версии.
  • Ссылки, учитывающие ветки: Схема URI aug: расширена для полной поддержки веток. Она позволяет как явно запрашивать Vibe из конкретной ветки, так и неявно находить его по приоритетному списку веток.
  • Иерархический поиск: Поиск Vibe — это не простое действие. Он следует настраиваемому, упорядоченному пути поиска (например, ['feature-x', 'staging', 'main']), создавая каскадную систему запасных вариантов и переопределений, что крайне важно для процессов разработки.
  • Запросы в прошлое: Поиск с учетом веток также учитывает время, позволяя системе находить зависимости в том виде, в каком они существовали в любой момент в прошлом. Это обеспечивает идеальную воспроизводимость для любого Vibe.
  • Ветки как основа для безопасного развития: Мы показываем, как ветки обеспечивают безопасную доработку (refinement) и развитие всех типов Vibe — от Records и Instructions до Processes и Budgets — контролируемым и отслеживаемым образом.

Сила параллелизма

В любой развивающейся системе управление изменениями — это ключевая задача. Как добавлять новые функции, исправлять ошибки или экспериментировать с идеями, не нарушая стабильность основной, готовой к работе версии вашей системы? Ответ — ветки.

Ветка — это полная, параллельная версия экосистемы Vibe. Она позволяет разработчикам и создателям работать в изолированной среде, внося изменения и создавая новые ревизии Vibe, которые невидимы для других веток, пока они не будут явно объединены. Это дает два основных преимущества:

  1. Изоляция: Работа над новой функцией (например, в ветке feature/new-billing) не мешает стабильной ветке main. Это предотвращает попадание незаконченного или содержащего ошибки кода в рабочие системы.
  2. Эксперименты: Ветки легко и быстро создавать. Это поощряет эксперименты. Вы можете создать ветку, чтобы протестировать новый Instruction, попробовать другую модель Budget или разработать новый Process, и просто удалить ветку, если эксперимент не удался.

На техническом уровне это обеспечивается таблицей базы данных vibes, которая содержит столбец-массив branches. Один id Vibe может иметь несколько ревизий, каждая из которых связана с одной или несколькими ветками. Это позволяет Vibe, такому как aug:ui/theme, иметь стабильную ревизию 2 в ветке main, в то время как ревизия 5 разрабатывается в ветке feature/redesign.

Ссылки и их поиск в разных ветках

Настоящая сила системы заключается в ее способности умно находить ссылки (resolve) aug: с учетом текущей ветки. Этот процесс управляется путем поиска — упорядоченным списком названий веток, который указывает системе, где и в каком порядке искать Vibe.

Путь поиска

Когда вы запрашиваете Vibe, не указывая ветку, система ищет его, используя ваш текущий путь поиска. Типичный путь поиска во время разработки может выглядеть так:

['feature/my-new-idea', 'staging', 'main']

Эта конфигурация означает:

  1. Сначала искать Vibe в ветке feature/my-new-idea.
  2. Если он там не найден, искать в ветке staging.
  3. Если он все еще не найден, использовать ветку main.

Этот каскадный поиск очень эффективен. Он позволяет разработчику, работающему в ветке feature/my-new-idea, иметь рабочее пространство, которое содержит:

  • Конкретные Vibe, которые он создал или изменил в своей ветке.
  • Все стабильные Vibe из staging и main, которые он не трогал.

Это создает полную, работающую среду без необходимости дублировать каждый Vibe.

Синтаксис ссылок aug: для веток

Схема URI aug: имеет специальный синтаксис для работы с ветками:

  • Неявный запрос: aug:schemas/UserProfile

    • Запрашивает последнюю ревизию схемы UserProfile, используя текущий путь поиска.

  • Явный запрос: aug:~main/schemas/UserProfile

    • Префикс ~ указывает на явный запрос ветки. Этот запрос ищет последнюю ревизию схемы UserProfile именно из ветки main, игнорируя остальной путь поиска для этого Vibe.

  • Разрешенная (найденная) ссылка: aug:~:staging/schemas/UserProfile?:2

    • Это формат ссылки после ее успешного поиска. Он предоставляет постоянную, однозначную запись о результате:
      • ~: означает, что исходный запрос был неявным (без префикса ~).
      • staging — это ветка, в которой был найден Vibe.
      • schemas/UserProfile — это путь.
      • ?:2 означает, что была запрошена последняя версия (?) и найдена ревизия 2 (:2).

Тестовый набор SQL (03_test_find_vibes_for_resolution.sql) предоставляет множество конкретных примеров этих правил поиска в действии, от простых проверок приоритета до сложных запасных вариантов с требованиями минимальной версии.

Поиск в ветках управляется упорядоченным путем поиска (например, `['feature', 'main']`). Неявная ссылка (`aug:my-vibe`) разрешается путем проверки каждой ветки по порядку. Явная ссылка (`aug:~main/my-vibe`) указывает на конкретную ветку, переопределяя путь поиска. Разрешенные ссылки фиксируют результат, создавая постоянную, отслеживаемую связь (например, `aug:~:main/my-vibe?:5`).

Алиса: «Так, если мой путь поиска — ['my-feature', 'main'], и я запрашиваю aug:common/button, система сначала будет искать версию common/button в моей ветке. Если я ее не меняла, она найдет стандартную в main?» Боб: «Именно так. Ты получаешь свои локальные изменения плюс стабильную основу из main, и все это работает без проблем. Но если тебе нужно протестировать что-то именно со стандартной версией кнопки из main, ты можешь запросить aug:~main/common/button, чтобы обойти свою локальную версию.»

Как путь поиска влияет на нахождение (resolution) Vibe?
* [x] Он определяет упорядоченный список веток для поиска по приоритету.
* [x] Он позволяет разработчикам переопределять стабильные Vibe своими версиями.
* [x] Он обеспечивает каскадный механизм поиска: от веток с новыми функциями к основной.
* [ ] Он требует, чтобы все Vibe существовали во всех ветках.
* [ ] Порядок веток в пути поиска не имеет значения.

Типичный процесс разработки

Давайте посмотрим, как ветки обеспечивают безопасный и эффективный процесс разработки при создании нового Process.

  1. Создание ветки: Разработчик начинает с создания новой ветки, feature/user-onboarding-v2. Его путь поиска устанавливается на ['feature/user-onboarding-v2', 'main'].

  2. Разработка процесса: Разработчик создает новый Vibe типа Process, aug:processes/onboarding. Поскольку он находится в ветке feature/user-onboarding-v2, этот новый Vibe и все его ревизии связываются с этой веткой. Он может свободно дорабатывать (refine) и тестировать процесс, создавая необходимые Vibe типа Instruction и схемы Record. Все эти новые Vibe существуют в его ветке.

  3. Использование существующих компонентов: Новому процессу onboarding нужен стандартный Instruction «Отправить письмо». Разработчик ссылается на него как aug:activities/send-email. Система поиска сначала проверяет ветку feature/user-onboarding-v2. Так как Vibe там нет, она обращается к main и находит стабильную версию.

  4. Переопределение компонента: Разработчик понимает, что ему нужен свой собственный шаблон «Приветственного письма». Он создает новую ревизию aug:records/email-templates/welcome и сохраняет ее. Эта новая ревизия сохраняется в ветку feature/user-onboarding-v2. Теперь, когда его процесс ссылается на этот Vibe, система поиска в первую очередь находит его новую версию, оставляя оригинал в ветке main нетронутым.

  5. Тестирование: Весь Process можно тестировать изолированно в этой ветке. Он использует комбинацию новых компонентов из ветки разработки и стабильных компонентов из main.

  6. Слияние: После завершения разработки и тестирования изменения из feature/user-onboarding-v2 могут быть объединены (merged) с веткой main. Обычно это контролируемый процесс, в ходе которого новые ревизии Vibe, созданные в ветке, связываются также и с веткой main, делая их новым «рабочим» стандартом.

Этот рабочий процесс, основанный на системе веток и поиска, позволяет вести параллельную разработку безопасно и эффективно. Это основной механизм, который позволяет экосистеме Vibe развиваться контролируемым, предсказуемым и масштабируемым образом.