Безопасность кода
Код живёт в файлах на диске, в IDE и в удалённом репозитории. Потеря прогресса обычно случается не из‑за "сложной математики", а из‑за обычных сбоев — закрыли вкладку без сохранения, перезагрузили ноутбук, удалили папку или перезаписали файл старой копией. Ниже — типовые риски и слои защиты — автосохранение, локальная история IDE, Git и бэкапы (Методы защиты пользовательских и корпоративных данных).
Базовые команды Git — в 4.13 / workflow.
Архитектура репозитория — Архитектура системы контроля версий Git, внутренности .git — Внутреннее устройство Git, опасные команды — Опасные скрипты.
Защита от подмены и копирования бинарников — Защита кода от изменений.
Непредвиденные ситуации
Когда пишется код, он должен сохраняться в локальном файле в хранилище. Однако никто не застрахован от ситуаций, когда последняя рабочая версия исчезает или подменяется:
- Несохранённые изменения — работа без автосохранения, случайное закрытие IDE или сбой редактора;
- Сбой системы — отключение питания, BSOD, зависание ОС;
- Проблема с инфраструктурой — падение сервера, отказ диска, повреждение ФС;
- Перезапись файлов — в буфер попала старая копия и нажали "Сохранить";
- Удаление без корзины —
rm, очистка диска, скрипт "почистить проект" (Опасные скрипты); - Ошибочная замена — скопировали не тот артефакт сборки поверх исходников;
- Конфликт при совместной работе — два человека правят один файл без VCS: побеждает последний
save.
Часть потерь — одна "удобная" команда — rm -rf, git reset --hard, скрипт из чата.
Стоп-лист — Опасные скрипты.
Несохранённые изменения
Несохранённые изменения представляют собой потерянный прогресс работы в коде. Такая ситуация возникает при отсутствии регулярного сохранения файлов или при аварийном завершении работы интегрированной среды разработки. Каждая внесённая правка, которая не была записана на диск, становится недоступной после закрытия программы.
Автосохранение автоматически фиксирует изменения через определённые промежутки времени. Локальная история сохраняет временные копии файлов с отметками времени. Системы контроля версий создают резервные копии при каждом коммите.
Пример. В VS Code/Cursor включите files.autoSave (например, afterDelay или onFocusChange). После падения IDE откройте Local History / Timeline для файла — часто там остаётся версия за минуты до сбоя. Это не заменяет git commit, но спасает черновик до первого коммита.
| Слой | Что спасает | Ограничение |
|---|---|---|
Ручное Ctrl+S | Текущий файл на диске | Не помогает при сбое до сохранения |
| Автосохранение IDE | Периодические записи | Только локально, без истории проекта |
| Локальная история IDE | Несколько снимков файла | Не синхронизируется с командой |
| Git commit | Снимок проекта с сообщением | Нужна дисциплина add + commit |
Сбой системы
Сбой системы приводит к неожиданному прекращению работы операционной системы. Отключение электричества мгновенно лишает компьютер питания. Синий экран смерти указывает на критическую ошибку ядра операционной системы. Зависание операционной системы делает интерфейс полностью неотзывчивым.
Восстановление после системного сбоя требует перезагрузки компьютера. При этом все несохранённые данные в оперативной памяти теряются безвозвратно. Жёсткий диск сохраняет информацию, записанную до момента сбоя.
Регулярное резервное копирование становится основным средством защиты от потери данных.
Что делать сразу после сбоя
- Перезагрузить ПК и проверить, открываются ли сохранённые файлы проекта.
- В IDE — Timeline / Local History для последних правок.
- Если проект под Git —
git status; незакоммиченное может остаться только в рабочей копии или stash. - Включить ИБП или облачную синхронизацию на будущее; критичные репозитории —
git pushв remote (Архитектура системы контроля версий Git).
| Симптом | Вероятная причина | Первый шаг |
|---|---|---|
| Файл пустой или старый | Не успели сохранить / перезапись | Local History, reflog только для Git |
| Весь проект пропал | Удаление, сбой диска | Корзина, бэкап ОС, clone с remote |
| IDE не открывается | Повреждение профиля | Другая IDE + папка проекта на диске |
Проблема с инфраструктурой
Проблема с инфраструктурой затрагивает аппаратное обеспечение и сетевые компоненты. Сбой сервера нарушает доступ к удалённым ресурсам и сервисам. Проблема с диском может проявляться в виде повреждённых секторов или полного отказа накопителя. Повреждение файловой системы делает данные недоступными для операционной системы.
Аппаратные сбои требуют физического вмешательства или замены компонентов. Резервирование дисков с помощью RAID-массивов повышает отказоустойчивость. Облачные сервисы предоставляют распределённое хранение с автоматическим восстановлением. Регулярная проверка состояния оборудования помогает выявить потенциальные проблемы до их критического проявления.
Что делать при деградации диска или сервера
- Снять полный бэкап или
git push --all+git push --tags, пока носитель ещё читается (Методы защиты пользовательских и корпоративных данных). - Не запускать "ремонтные" скрипты с
fsck/chkdskна единственной копии данных без снимка. - Для CI/CD — проверить, что артефакты сборки и образы лежат не только на упавшем runner (DevOps).
- На ноутбуке — SMART-диагностика, замена диска, восстановление из Time Machine / File History / облака.
См. также железо и хранение и системное администрирование (2.06).
Перезапись файлов
Перезапись файлов происходит при сохранении новой информации поверх существующего содержимого. Случайное копирование некорректного текста и последующее сохранение файла приводит к потере оригинальных данных. Открытие старой версии файла и её сохранение поверх актуальной версии уничтожает последние изменения.
Системы контроля версий сохраняют полную историю изменений каждого файла. Локальная история хранит временные копии с различными временными метками. Резервное копирование создаёт независимые версии файлов в отдельных местах хранения. Версионирование файлов позволяет откатиться к предыдущему состоянию без потери данных.
Восстановление после перезаписи
git log --oneline -- path/to/file.py
git show abc1234:path/to/file.py > path/to/file.py # версия из коммита
# или
git restore --source=abc1234 -- path/to/file.py
Без Git — только Local History IDE или бэкап файловой системы. Профилактика: коммитить перед экспериментом, не править production-конфиг "вручную в блокноте" без VCS.
Удаление папок или файлов без возможности восстановления
Удаление папок или файлов без возможности восстановления представляет собой окончательную потерю данных. Очистка корзины операционной системы удаляет ссылки на файлы. Форматирование диска стирает файловую систему и делает данные недоступными. Физическое повреждение носителя информации уничтожает данные на аппаратном уровне.
Регулярное резервное копирование создаёт независимые копии данных в безопасных местах. Облачное хранение обеспечивает доступ к файлам из любого места. Внешние накопители предоставляют физическое разделение данных от основной системы. Автоматизация процесса резервного копирования гарантирует своевременное создание копий.
Если файл уже удалён
| Среда | Куда смотреть |
|---|---|
| Windows | Корзина, File History, Previous Versions, OneDrive/Google Drive versions |
| macOS | Trash, Time Machine |
| Linux | extundelete / testdisk только если сразу; иначе бэкап |
| Git tracked | git checkout HEAD -- path или history commit |
| Git untracked | не в Git — только IDE Local History или бэкап |
Команды rm -rf и очистка без бэкапа — Опасные скрипты.
Ошибочная замена файлов
Ошибочная замена файлов возникает при некорректном копировании или перемещении данных. Перезапись файла более старой версией приводит к потере актуальных изменений. Замена файла с похожим именем, но различным содержимым нарушает целостность проекта. Автоматические скрипты могут случайно перезаписать важные файлы без предупреждения.
Системы контроля версий отслеживают каждое изменение файла и позволяют восстановить любую предыдущую версию. Хеширование файлов помогает выявить несанкционированные изменения. Автоматические тесты проверяют целостность файлов после операций копирования. Журналирование операций предоставляет информацию о всех изменениях файловой системы.
Конфликт изменений из-за одновременной работы с файлом
Конфликт изменений возникает при одновременной работе нескольких разработчиков с одним файлом. Разработчик номер один вносит изменения и сохраняет файл. Разработчик номер два работает с предыдущей версией файла и перезаписывает изменения первого разработчика. Итоговый файл содержит только изменения последнего сохранения, игнорируя работу первого участника.
Системы контроля версий разрешают конфликты через механизм слияния изменений. Блокировка файлов предотвращает одновременное редактирование. Оперативное уведомление о текущих изменениях помогает координировать работу команды. Атомарные операции гарантируют целостность данных при одновременных изменениях.
Как избежать "последний save победил"
- Все правки — через ветку и PR/MR (4.13 / 113).
- Мелкие коммиты и частый
pull --rebaseилиmerge mainуменьшают расхождение. - Для бинарников (PSD, Excel) — договориться о lock в SVN-стиле или хранить источник в Git LFS с явным владельцем файла.
- Конфликт merge — правка маркеров
<<<</====/>>>>, затемgit addи commit; не удалять чужие блоки "на глаз" без согласования.
Средства защиты от непредвиденных ситуаций
Play ITЗагрузка интерактивного демо…
Защита строится слоями: чем раньше снимок, тем меньше потерь. Автосохранение и локальная история IDE закрывают минуты работы; Git — логические версии для команды; бэкап диска и облако — когда погибает весь ноутбук или .git (Методы защиты пользовательских и корпоративных данных).
Для защиты кода используется автосохранение (в первую очередь), снимки состояний, локальные истории и конечно же самое важное – VCS (version control System), система контроля версий.
Автосохранение
Автосохранение представляет собой автоматический процесс записи изменений в файл через заданные промежутки времени. Интегрированная среда разработки периодически сохраняет текущее состояние документа без участия пользователя. Интервал автосохранения настраивается в зависимости от предпочтений разработчика и важности проекта.
Автосохранение создаёт временную копию файла с текущими изменениями. При аварийном завершении работы среды разработки последняя сохранённая версия остаётся доступной. Автосохранение работает в фоновом режиме и не требует дополнительных действий от пользователя. Некоторые системы автосохранения создают отдельные временные файлы для предотвращения повреждения оригинального документа.
Снимок состояния
Снимок состояния фиксирует текущее содержимое файла или проекта в определённый момент времени. Создание снимка сохраняет полную копию всех данных с точными временными метками. Снимки состояния позволяют вернуться к любому предыдущему состоянию проекта без потери информации.
Системы контроля версий создают снимки состояния при каждом коммите. Локальная история генерирует снимки через регулярные интервалы времени. Облачные сервисы автоматически создают снимки состояния при синхронизации данных. Снимки состояния хранятся в отдельном месте и не влияют на текущую работу с проектом.
Локальная история
Локальная история представляет собой механизм автоматического сохранения временных копий файлов на локальном компьютере. Интегрированная среда разработки периодически создаёт резервные копии открытых файлов с отметками времени. Локальная история хранит несколько версий каждого файла для возможности восстановления.
Локальная история работает независимо от систем контроля версий и не требует подключения к удалённым репозиториям. Временные копии хранятся в специальной директории на локальном диске. Интерфейс локальной истории позволяет просматривать все сохранённые версии файла и восстанавливать любую из них. Локальная история особенно полезна при работе с небольшими проектами или при отсутствии системы контроля версий.
Локальная история автоматически удаляет старые версии файлов для экономии дискового пространства. Настройки локальной истории позволяют определить количество сохраняемых версий и интервал создания копий. Восстановление из локальной истории происходит мгновенно без необходимости загрузки данных из внешних источников.
Контроль версий
Контроль версий — процесс учёта изменений с возможностью отката к предыдущему состоянию и сравнения версий.
Системы контроля версий (VCS) — программы, которые хранят историю проекта: кто, когда и что изменил. Каждый коммит — именованный снимок дерева файлов; ветки и теги указывают на нужные коммиты. Для команд это ещё и способ согласовать правки через merge/rebase и code review (ветвление в 4.13).
Минимальная привычка на каждый логический шаг:
git status
git add -p # или git add <файлы>
git commit -m "Кратко: что сделано"
git push # когда готовы делиться
Подробный разбор зон (рабочий каталог, индекс, .git) — в Архитектура системы контроля версий Git; 12 команд — карманный набор; расширенный справочник — Команды Git для повседневной разработки.
Git
★ Самая популярная система контроля версий – Git (гит) – децентрализованная система контроля версий с распределенной архитектурой, позволяющая каждому разработчику обладать своей локальной копией всей истории разработки.
Git использует хеши SHA-1 (алгоритм криптографического шифрования), а с 2020 года перешел на SHA-256, хеш вычисляется от содержимого файла и от метаданных (размера, типа объекта). Технологии шифрования, которые используются для идентификации подлинности объектов, позволяют эффективно сравнивать хеш-таблицы файлов и обеспечивать контроль изменений.
Git используется через инструменты (Git-системы). Их делят на платформы (хостинг + CI + задачи) и клиенты (как вы вызываете git локально).
Платформы хостинга
★ GitLab — хостинг Git с CI/CD, Issue Tracker, Wiki, Container Registry; можно развернуть on-premise:
- self-hosted на своём сервере;
- встроенные пайплайны CI/CD;
- трекер задач;
- реестр Docker-образов.
★ GitHub — крупнейший публичный хостинг (Microsoft):
- GitHub Actions (CI/CD);
- Pull Request для code review;
- GitHub Pages для статики;
- социальный слой для open source.
★ Bitbucket (Atlassian):
- бесплатный tier с лимитом пользователей;
- интеграция с Jira, Confluence, Trello;
- Bitbucket Pipelines;
- раньше поддерживал Mercurial (сейчас упор на Git).
★ Отечественные хостинги — GitVerse, SourceCraft; настройка нескольких remotes — Множественные сервисы Git на одном компьютере.
Сравнение с устаревшим SVN — Сравнение Git и Subversion (SVN). История семейств VCS:
RCS — Revision Control System хранит историю по одному файлу, использует файлы с суффиксом ",v" (например, file.txt,v).
CVCS — Centralized Version Control Systems (Централизованные) это CVS, Subversion и Perforce. Все данные хранятся на сервере. Пользователь делает checkout → изменяет → commit. Нет локальной истории: если сервер сломается — теряется всё.
DVCS — Distributed Version Control Systems (Распределённые) не только Git. Есть ещё несколько.
Perforce (CVCS) - коммерческая система, широко используется в крупных компаниях (игровые студии, банки и т.д.), поддерживает большие бинарные файлы, отлично масштабируется, имеет мощный интерфейс и интеграции. Платная и сложная.
Mercurial (DVCS) более легкий, базирован на Python, является аналогом Git, но чуть проще. Подходит для маленьких и средних проектов, имеет меньше инструментов и интеграций.
Bazaar (DVCS) разработан Canonical (Ubuntu), поддерживает как децентрализованный, так и централизованный стиль работы. Может работать поверх других систем (Git, SVN), но сейчас мало кто его использует.
Darcs (DVCS) имеет оригинальный подход к отслеживанию изменений — оперирует патчами, а не коммитами. Почти не используется в промышленной разработке, имеет мало инструментов и плохую интеграцию, однако концепция у него интересная.
BitKeeper (DVCS) была одна из первых распределённых систем, быстрая, надёжная, использовалась для разработки Linux до появления Git. Но после появления Git практически вышла из употребления.
Клиенты Git
★ Клиенты — способ вызывать Git с вашей машины:
★ Командная строка (Git Bash, PowerShell) — максимальная гибкость; все примеры в Команды Git для повседневной разработки рассчитаны на CLI.
★ TortoiseGit — интеграция в проводник Windows, наглядные статусы файлов.
★ GitKraken — визуализация веток, интеграция с GitHub/GitLab/Bitbucket.
★ SourceTree (Atlassian) — бесплатный GUI, связка с Jira/Bitbucket.
★ IDE — встроенный Git в VS Code, JetBrains, Visual Studio (Архитектура системы контроля версий Git).
Работа с Git
Play ITЗагрузка интерактивного демо…
Авторизация в Git
Авторизация в Git проходит весьма интересным образом.
PAT (Personal Access Token) представляет собой альтернативу паролю при работе с GitHub, GitLab и т.д., может иметь ограниченные права и срок действия, используется вместо пароля при HTTPS-подключении.
git clone https://github.com/username/repo.git
Username: ваш-логин
Password: ваш-PAT
Получить можно на GitHub: Settings → Developer settings → Personal access tokens
SSH-ключи — другой способ: пара ключей (публичный + приватный), используемая при работе через SSH-протокол. Несколько хостингов на одной машине — Множественные сервисы Git на одном компьютере.
Создаются ключи, публичный ключ привязывается к аккаунту на GitHub/GitLab, и репозиторий клонируется через SSH:
git clone git@github.com:username/repo.git
Git Credential Manager (GCM) третий способ. Инструмент, который интегрируется в Git и сохраняет токены/PAT в Credential Manager.
Windows предоставляет систему управления учётными данными — Credential Manager (Диспетчер учетных данных).
Панель управления → Учетные записи пользователей → Диспетчер учетных данных
Там хранятся логины и пароли для веб-сайтов, сетевых ресурсов (UNC-пути), приложений, поддерживается Windows Hello, сертификаты, ключи и т.д.
Git использует именно этот механизм, когда вы включаете GCM.
Внутри Windows использует:
- LSA Secrets (Local Security Authority Secrets) - защищённая часть реестра, где хранятся локальные секреты;
- DPAPI (Data Protection API) для шифрования данных на уровне пользователя или машины, и Git использует именно это;
- CredMan (Credential Manager API) для работы с сохранёнными учетными данными - там хранятся логин и токены.
Базовый разбор HTTP и HTTPS находится в отдельной статье — HTTP как основа веб-интеграций.