Ви підключаєте репозиторій, робите пуш з IDE — і отримуєте конфлікти злиття. Втрачені правки. Тихі відкати. Це фундаментальний дефект проектування.

Три способи, якими git sync виходить з ладу

1. Одностороннє дзеркало. Більшість платформ ставляться до git як до резервної копії. Пуші з IDE спричиняють конфлікти. GitBook — найбільш показовий приклад.

2. База даних на першому місці, git — на другому. Wiki.js: база даних є канонічним джерелом. Git — лише однобічний експорт для читання. Неможливо зробити git clone, push і побачити зміни в інтерфейсі.

3. Деструктивне вирішення конфліктів. Платформи мовчки перезаписують, створюють дублікати або позначають синхронізацію як «невдалу».

Чому це складно

Вебінтерфейси очікують негайних атомарних записів. Git працює зі знімками стану. Розрив у часі між ними призводить до розбіжностей.

Патерн Content Ledger

Valoryx: журнал подій з додаванням записів лише в кінець, з повним упорядкуванням.

  • Кожна мутація є подією — не прямим записом у git або базу даних
  • Події застосовуються до обох цілей — вебінтерфейс і git-репозиторій сходяться
  • Пуші в git стають записами журналу через webhook — вебінтерфейс оновлюється за секунди
  • Конфлікти неможливі за задумом — всі мутації серіалізовані

На практиці

  • Редагування в браузері → git log показує коміт за секунди
  • Пуш з VS Code → вебінтерфейс оновлюється без ручної синхронізації
  • CI змінює документи → результати відображаються у вебредакторі
  • git revert → вебінтерфейс негайно відображає зміни

Немає статусу синхронізації. Немає інтерфейсу конфліктів. Немає розбіжностей.