Защита данных
Пять слоёв защиты от потери работы, плюс preflight-проверки и обработка ошибок
Ключевой принцип GitBor — никогда не терять вашу работу, даже если приложение упадёт посреди операции. Защита построена из пяти независимых слоёв — если не сработал один, сработает следующий.
1. Reflog: история перемещений HEAD
Встроенный механизм Git: каждое перемещение HEAD (commit, checkout, reset, rebase, merge) логируется и хранится около 90 дней. GitBor опирается на него при восстановлении. Просмотр и восстановление — через Repository → More → Reflog…, полный интерфейс описан на странице Reflog.
2. Авто-стэш перед опасными операциями
Перед каждым pull, merge, rebase и переключающим ветку checkout GitBor:
- Проверяет наличие незакоммиченных изменений.
- Если есть — авто-стэшит их с маркерным именем.
- Запускает основную операцию.
- При успехе — возвращает stash; ваши изменения снова в рабочей копии.
- При сбое — оставляет stash в списке, чтобы вы применили его вручную (Pop в тулбаре или Apply stash из диалога ошибки).
Так что даже если вы забыли закоммитить и нажали Pull, правки не потеряются.
3. Точка сохранения перед rebase и reset
Перед rebase или reset GitBor запоминает текущий HEAD. Если результат не понравился, в reflog есть заведомо хорошая точка, к которой можно вернуться в один клик.
4. Журнал операций
Каждая опасная операция пишется в журнал репозитория в три этапа:
| Запись | Когда |
|---|---|
| Start | Перед началом операции. |
| Success | После завершения. |
| Failure | При ошибке, с деталями. |
Если GitBor жёстко убьют между «start» и «success» (отключение питания, kill -9, BSOD), журнал останется незавершённым — и GitBor поднимет это при следующем запуске.
5. Восстановление при старте
При открытии репозитория GitBor проверяет:
- Устаревший
index.lock— оставшийся.git/index.lockпосле падения. GitBor помечает его устаревшим и игнорирует, но не удаляет автоматически (вдруг работает другой git-процесс). Удалите вручную, если он реально мешает. - Незавершённые операции из журнала — диалог: продолжить, отменить или забыть.
- Незавершённый rebase — восстанавливает баннер прогресса с Continue / Abort.
- Незавершённый merge — открывает редактор для конфликтных файлов.
Обработка ошибок и preflight-проверки
Перед опасными операциями GitBor выполняет preflight-проверки и, когда что-то не так, показывает сфокусированный диалог с причиной и правильным следующим шагом вместо сырой ошибки Git. Частые случаи:
| Ситуация | Что предлагает GitBor |
|---|---|
Другой git-процесс держит index.lock | Подождать, Kill git process или Remove index.lock — со списком запущенных git-процессов. |
| Рабочее дерево было бы перезаписано | Сперва stash, commit или discard. |
| Merge / rebase / cherry-pick / revert уже идёт | Завершить или отменить перед запуском другого. |
| Неразрешённые конфликты в индексе | Разрешить их или сперва отменить. |
| Remote отклонил push (non-fast-forward) | Сделать pull или rebase перед push. |
| Сбой сети / аутентификации | Повторить или починить соединение / креды / SSH-ключ. |
| Untracked-файлы были бы перезаписаны | Сперва переместить или удалить их. |
Когда при неудачной операции был создан авто-стэш, диалог сообщит его хэш и предложит Apply stash для восстановления.
Безопасность ввода и настроек
Помимо данных репозитория, GitBor защищается от плохого ввода:
- Пути из Open / Clone валидируются — попытки выйти за выбранную папку (
../../etc/passwd) отклоняются. - Рискованные корни (домашняя папка, корень диска,
Program Files,node_modules) открываются без слежения за файлами, чтобы не нагружать ОС. - Имена SSH-ключей и хуков проверяются на спецсимволы.
- Секреты в логе (флаги паролей и т.п.) маскируются перед записью.
- Настройки и кэши пишутся атомарно — временный файл, затем переименование — так что обрыв питания в момент записи не оставит битый конфиг.
- AI-ключи шифруются через системное хранилище ключей.
Если что-то всё же сломается — reflog и журнал на месте. Потерять уже закоммиченное в Git очень трудно; GitBor добавляет защиту и для незакоммиченной части.