GitBor

Защита данных

5 уровней защиты от потери работы — reflog, auto-stash, WAL, RecoveryManager

Один из основных принципов GitBor — никогда не терять работу пользователя, даже при падении приложения посреди опасной операции. Реализовано пятью независимыми слоями. Код живёт в src/core/safety/.

1. Git reflog

Встроенный механизм git: каждое движение HEAD (commit, checkout, reset, rebase, merge) попадает в .git/logs/HEAD и хранится 90 дней. GitBor ничего дополнительного не делает — просто опирается на reflog при восстановлении.

Просмотр через Repository → Reflog...: полная история действий, копирование SHA, Restore (hard reset) до любой точки — с подтверждением.

2. Auto-stash перед деструктивными операциями

SafetyNet (в src/core/safety/SafetyNet.ts) перед каждой деструктивной операцией (pull, merge, rebase, checkout со сменой ветки):

  1. Проверяет, есть ли незакоммиченные изменения (git status).
  2. Если есть — делает git stash push -u с маркерным именем (например, gitbor-autostash-1715000000).
  3. Запускает основную операцию.
  4. При успехе — git stash pop, изменения возвращаются на место.
  5. При ошибке — оставляет stash. Пользователь увидит его в списке stash-ей и сможет применить вручную.

3. Сохранение HEAD-хеша

Перед rebase и reset GitBor запоминает текущий SHA HEAD. Если что-то пойдёт не так, есть «золотая точка», к которой можно сделать git reset --hard <saved-sha> через Reflog.

4. WAL-журнал операций

OperationJournal (src/core/safety/OperationJournal.ts) — write-ahead log в формате JSON в файле .git/GitBor-journal.json. На каждую опасную операцию пишется запись:

Тип записиКогда
beginПеред стартом операции
completeПосле успешного завершения
failПри ошибке (с диагностикой)

Если GitBor жёстко прибили между begin и complete, при следующем запуске RecoveryManager найдёт «зависшую» запись и поднимет её на разбор.

5. RecoveryManager при старте

RecoveryManager (src/core/safety/RecoveryManager.ts) запускается при открытии каждого репозитория и проверяет:

  • Lock-файлы — .git/index.lock. Если он остался от предыдущего падения git, GitBor не удаляет его автоматически на старте (это могло бы сломать параллельный git, если он действительно идёт), а помечает как stale и игнорирует при чтении состояния.
  • Незавершённые операции в WAL-журнале — show user prompt: продолжить, отменить или забыть.
  • Незавершённый rebase — наличие .git/rebase-merge/ или .git/rebase-apply/. GitBor автоматически восстановит UI прогресс-баннера.
  • Незавершённый merge — наличие .git/MERGE_HEAD. Откроет конфликтную панель.

Атомарные записи на диск

Все настройки и кэши, которые GitBor пишет на диск (.git/GitBor-journal.json, ai-config.json, кэш графа), используют AtomicWrite (src/core/safety/AtomicWrite.ts):

  1. Запись во временный файл *.tmp.
  2. fsync — гарантия попадания на диск.
  3. rename поверх итогового файла — POSIX гарантирует атомарность.
  4. Для Windows — retry через Atomics.wait (без busy-spin), потому что rename там может конфликтовать с антивирусом и индексаторами.

Защита ввода

Помимо защиты данных репозитория, GitBor защищает себя от подсунутых снаружи путей:

  • safePath() — все IPC-пути проходят через realpathSync.native (резолвит симлинки, case-insensitive на Windows). Запросы вида ../../../etc/passwd не пройдут.
  • isDangerousRepoRoot() — открыть репозиторий в опасном корне ($HOME, корень диска, Program Files, node_modules) можно, но file watcher (chokidar) не подключается, чтобы избежать каскада EPERM-ошибок.
  • isSafeFilename() — имена SSH-ключей и git-хуков проверяются на спецсимволы.
  • AppError — все ошибки имеют структурированный code + data. Renderer показывает локализованный текст из locale.repoErrors[code], а не сырой stderr.
  • Маскирование секретов в логе — sanitizeArgs редактирует commit-сообщения и парольные флаги (-m, -C, -N, --message) перед записью в Git Activity Log.
  • Защита от shell injection — openInTerminal использует execFile/spawn, не exec.
  • Electron sandbox — contextIsolation: true, sandbox: true, nodeIntegration: false.