Забота о коде и данных — итоги
Кратко — что стоит унести из раздела "Забота о коде и данных". Если пункт кажется туманным — откройте указанную главу или оглавление.
FAQ — Часто задаваемые вопросы
Типичные сбои и ситуации, с которыми сталкиваются новички после раздела. Здесь — что делать и где копать в главах; определения для зачёта — в чек-листе.
Вопрос. IDE упала — полдня работы "пропало".
Ответ. Сначала Local History / Timeline в редакторе, затем последний git stash или commit. Автосохранение спасает файл, но не историю проекта — коммитьте чаще. Подробнее здесь — глава 1.
Вопрос. Сделал git reset --hard — можно вернуть?
Ответ. Иногда через git reflog, если коммиты ещё не собраны garbage collection. Не экспериментируйте на prod-репозитории; опасные команды — в стоп-листе. Подробнее здесь — Опасные скрипты, Настройка и параметры Git.
Вопрос. Закоммитил пароль от БД — удалил в следующем коммите. Всё чисто?
Ответ. Нет: секрет остаётся в истории Git. Ротируйте пароль, используйте git filter-repo или BFG, считайте ключ скомпрометированным. Подробнее здесь — Методы защиты пользовательских и корпоративных данных.
Вопрос. .env в .gitignore, но файл всё равно попал в PR.
Ответ. Файл мог быть добавлен до ignore или force-add. Удалите из индекса (git rm --cached), проверьте pre-commit hook, ротируйте секреты. Подробнее здесь — Методы защиты пользовательских и корпоративных данных, Архитектура системы контроля версий Git.
Вопрос. Два человека правили один файл без Git — победила чужая версия.
Ответ. Без VCS побеждает последний save. Нужны ветки, pull перед работой, PR и code review. Подробнее здесь — глава 1, 4.13 / ветки.
Вопрос. Merge conflict — паника, что нажать "Accept All"?
Ответ. Разберите маркеры <<<< / ==== / >>>> вручную или с напарником; слепой Accept All часто смешивает две логики. После — тесты и commit. Подробнее здесь — 4.13, Типовые ситуации с Git.
Вопрос. Скопировал из чата "удобный" скрипт очистки — удалил полпроекта.
Ответ. Читайте команды перед Enter; rm -rf, git clean -fdx — из стоп-листа. Восстановление — reflog, бэкап, clone заново. Подробнее здесь — Опасные скрипты.
Вопрос. git push rejected — "non-fast-forward".
Ответ. На remote уже есть коммиты: сделайте git pull --rebase (или merge), разрешите конфликты, push снова. Force push в общую ветку без согласования — табу. Подробнее здесь — Настройка и параметры Git, 4.13.
Вопрос. Репозиторий только на GitHub — ноутбук украли. Код спасён?
Ответ. Код на remote, если всё push'или; но локальные незакоммиченные изменения и секреты на диске — риск. Шифруйте диск, MFA на GitHub, не храните prod-ключи локально. Подробнее здесь — глава 1, Методы защиты пользовательских и корпоративных данных.
Вопрос. Бэкап БД раз в год "на всякий случай" — достаточно?
Ответ. Нет: нужны регулярность, проверка restore и правило 3-2-1. Бэкап без теста восстановления — надежда, не стратегия. Подробнее здесь — Методы защиты пользовательских и корпоративных данных.
Вопрос. Пароли пользователей хранят в БД "как есть" для простоты входа.
Ответ. Храните хеш + salt (bcrypt, Argon2), никогда plaintext. Утечка дампа тогда не даёт мгновенный вход всем аккаунтам. Подробнее здесь — Методы защиты пользовательских и корпоративных данных, 8.07.
Вопрос. Логи приложения пишут номера карт и JWT — это нормально для отладки?
Ответ. Нет: логи часто утекают в SIEM, support, stdout в облаке. Маскируйте PII и секреты, используйте уровни log. Подробнее здесь — Методы защиты пользовательских и корпоративных данных.
Вопрос. Вставил API-ключ ChatGPT прямо в код для "быстрого теста".
Ответ. Типичный путь утечки через vibe-coding: ключ в промпт, скрин, репозиторий. Вынесите в env, ротируйте, если уже светился. Подробнее здесь — Методы защиты пользовательских и корпоративных данных, 6.07.
Вопрос. git add . перед коммитом — случайно добавил гигабайтный дамп.
Ответ. Используйте .gitignore, git status до add, pre-commit на большие файлы. Удаление из истории тяжелее, чем не закоммитить. Подробнее здесь — Архитектура системы контроля версий Git, Внутреннее устройство Git.
Вопрос. Submodule или LFS — коллега clone'ит, бинарники пустые.
Ответ. Нужны git submodule update --init или LFS pull; без этого репозиторий неполный. Документируйте в README. Подробнее здесь — Модель ветвления GitFlow, Защита кода от изменений.
Вопрос. Signed commit — "лишняя бюрократия"?
Ответ. Подпись снижает риск подмены автора и supply-chain в open source и банках. Для pet-проекта опционально; для prod — часто требование. Подробнее здесь — Защита кода от изменений, Особенности работы с репозиториями в Git.
Вопрос. Транзакция БД "наполовину" записала заказ — деньги списали, строки нет.
Ответ. Нужны ACID-транзакции, правильный уровень изоляции, идемпотентность API. Без этого распределённая система ломается при сбое посередине. Подробнее здесь — Методы защиты пользовательских и корпоративных данных, SQL.
Вопрос. HTTPS на сайте есть, но API внутри кластера ходит по HTTP.
Ответ. Внутренняя сеть не "доверенная по умолчанию" при компрометации pod. TLS/mTLS между сервисами — для чувствительных данных. Подробнее здесь — Методы защиты пользовательских и корпоративных данных, 8.07.
Вопрос. Скачал библиотеку с лицензией GPL — можно закрыть коммерческий продукт?
Ответ. GPL тянет copyleft — проверьте compliance до релиза. MIT/Apache мягче; юрист или таблица лицензий в CI. Подробнее здесь — Сравнение Git и Subversion (SVN), Команды Git для повседневной разработки.
Вопрос. git stash — "куда делся код"?
Ответ. Изменения во временном stash, не в ветке. git stash list, git stash pop — вернуть. Забытый stash месяцами — типичная потеря контекста. Подробнее здесь — 4.13 / типовые ситуации.
Вопрос. Диск ноутбука умер — Git на remote есть, локальные ветки нет.
Ответ. Clone заново; не запушенные ветки и stash потеряны. Дисциплина push и облачный remote — минимальная страховка кода. Подробнее здесь — глава 1.
Вопрос. CI упал на секретах — "variable not found".
Ответ. Секреты задают в settings CI / vault, не в yaml в репозитории. Разные env для dev и prod. Подробнее здесь — Методы защиты пользовательских и корпоративных данных, 8.04 / CI.
Вопрос. Обфускация .exe — "никто не украдёт алгоритм"?
Ответ. Обфускация замедляет, не останавливает reverse engineering. Секреты в бинарнике всё равно извлекают; защита — на сервере и ключах. Подробнее здесь — Защита кода от изменений.
Вопрос. Публичный репозиторий — в issues случайно вставили токен.
Ответ. GitHub сканирует, но ротация немедленно; issues не удаляют историю из уведомлений. Secret scanning + branch protection. Подробнее здесь — Методы защиты пользовательских и корпоративных данных.
Вопрос. chmod 777 на папку проекта — "чтобы всё работало".
Ответ. Открытые права — любой процесс может менять файлы. Минимальные права для пользователя сервиса; 777 — временный костыль, не решение. Подробнее здесь — Настройка и параметры Git, 2.06.
Вопрос. Как не потерять код, если только учусь и Git "страшный"?
Ответ. Минимум: aut save, ежедневный commit + push, один remote. Дальше — ветки и PR по 4.13. Подробнее здесь — глава 1, intro раздела.
Вопрос. Git для начинающих — с чего начать?
Ответ. git init, add, commit, push на GitHub — минимальный цикл; дальше ветки и PR. Подробнее здесь — 4.13 / 12 команд, глава 1.
Вопрос. Что такое git commit и зачем писать сообщение?
Ответ. Commit — снимок изменений в истории; сообщение объясняет "зачем", не "что нажал". Нужен для отката и code review. Подробнее здесь — 4.13 / workflow.
Вопрос. Git reset --hard — как отменить и вернуть код?
Ответ. Смотрите git reflog и checkout/cherry-pick на старый hash; работает, пока GC не собрал объекты. Подробнее здесь — Опасные скрипты, Настройка и параметры Git.
Вопрос. Как удалить пароль из истории Git на GitHub?
Ответ. Ротация секрета + git filter-repo / BFG; force push с согласованием команды. Удаление файла одним commit не чистит историю. Подробнее здесь — Методы защиты пользовательских и корпоративных данных.
Вопрос. Git merge conflict — что делать пошагово?
Ответ. Откройте файлы с маркерами, согласуйте обе версии, git add, завершите merge. Тесты после. Подробнее здесь — 4.13 / ветки, Типовые ситуации с Git.
Вопрос. Git stash — что это и как вернуть изменения?
Ответ. Временный стек правок без commit: stash list, stash pop. Не замена push на remote. Подробнее здесь — 4.13 / типовые ситуации.
Вопрос. Git rebase vs merge — в чём разница?
Ответ. Merge сохраняет ветвление; rebase переписывает историю поверх main — чище log, опаснее для shared branch. Подробнее здесь — 4.13, Настройка и параметры Git.
Вопрос. Pull Request (Merge Request) — что это?
Ответ. Запрос влить ветку после review и CI; точка контроля качества, не формальность. Подробнее здесь — 4.13 / PR.
Вопрос. Git Flow — что за схема веток?
Ответ. main, develop, feature/release/hotfix — модель для релизов; для маленьких команд часто хватает trunk-based. Подробнее здесь — Настройка и параметры Git, 4.13.
Вопрос. Как хранить пароли пользователей в базе правильно?
Ответ. Только хеш с salt (bcrypt, Argon2), never plaintext; pepper опционально. Подробнее здесь — Методы защиты пользовательских и корпоративных данных, 8.07.
Вопрос. Файл .env — что это и можно ли коммитить в Git?
Ответ. Локальные переменные окружения; в Git только .env.example без секретов. Подробнее здесь — Методы защиты пользовательских и корпоративных данных.
Вопрос. Утечка API ключа на GitHub — что делать?
Ответ. Revoke ключ немедленно, новый ключ, очистка history, secret scanning. Подробнее здесь — Методы защиты пользовательских и корпоративных данных.
Вопрос. Правило бэкапа 3-2-1 — что значит?
Ответ. Три копии данных, на двух типах носителей, одна копия offsite. Подробнее здесь — Методы защиты пользовательских и корпоративных данных.
Вопрос. Как сделать backup PostgreSQL / MySQL?
Ответ. pg_dump, snapshot, реплика + периодический restore-test; не только dump на том же диске. Подробнее здесь — Методы защиты пользовательских и корпоративных данных, SQL.
Вопрос. Симметричное и асимметричное шифрование — простыми словами?
Ответ. Симметричное — один ключ (AES для данных); асимметричное — пара public/private (TLS, подписи). Подробнее здесь — Методы защиты пользовательских и корпоративных данных, 8.07.
Вопрос. VCS — что такое система контроля версий?
Ответ. Хранит историю изменений файлов и совместную работу; Git — де-факто стандарт. Подробнее здесь — глава 1, 4.13.
Вопрос. Git clone — что делает команда?
Ответ. Копирует репозиторий с remote на машину со всей историей (не только последний файл). Подробнее здесь — 4.13 / 12 команд.
Вопрос. Как восстановить удалённый файл из Git?
Ответ. git log -- path, затем git checkout commit -- file или revert commit. Подробнее здесь — 4.13 / 1141.
Вопрос. Pre-commit hook для секретов — зачем?
Ответ. Блокирует commit с паттернами ключей до push; дополнение к .gitignore, не замена ротации секрета. Подробнее здесь — Методы защиты пользовательских и корпоративных данных, Архитектура системы контроля версий Git.
Вопрос. Безопасность исходного кода — основные угрозы?
Ответ. Потеря несохранённого, утечка репо, подмена бинарников, секреты в логах. Слои защиты — в разделе 8.03. Подробнее здесь — глава 1, Защита кода от изменений.
Вопрос. Staging area (git add) — что это?
Ответ. Индекс между рабочей папкой и commit — что войдёт в следующий снимок. git status показывает три зоны. Подробнее здесь — Архитектура системы контроля версий Git, 4.13.
Вопрос. Публичный и приватный репозиторий GitHub — разница?
Ответ. Public виден всем (и ботам сканерам); private — по ACL. Секреты не кладут даже в private без rotation. Подробнее здесь — Методы защиты пользовательских и корпоративных данных.
Вопрос. Как не потерять код при сгорании ноутбука?
Ответ. Частые push на remote, второй clone, бэкап диска; незакоммиченная работа всё равно под риском. Подробнее здесь — глава 1.
Что запомнить
Главная идея
Код и данные живут в файлах, Git, БД и облаке. Гигиена — слои защиты от потери и утечки — autosave, VCS, секреты вне репозитория, бэкапы с проверкой restore.
Слои сохранности кода
| Слой | Спасает от |
|---|---|
| Autosave / Local History | Сбой IDE до первого commit |
| Git commit + remote | Потеря машины, совместная работа |
| Бэкап БД и артефактов | Сбой диска, ошибка миграции |
Подробнее — глава 1, Методы защиты пользовательских и корпоративных данных.
Секреты и данные
- Пароли и ключи — в env, vault, CI secrets; не в Git и не в логах.
- Пароли пользователей — хеш, не plaintext.
- Опасные команды терминала и Git — стоп-лист 101.
Три правила на каждый день
- Commit и push чаще, чем кажется нужным.
- Секрет утёк — ротация, не "удалил строку".
- Бэкап без теста restore не считается бэкапом.
Куда идти дальше
| Тема | Раздел |
|---|---|
| "Тестирование информационной безопасности" | "Тестирование информационной безопасности" |
| "Контейнеризация и оркестрация — о разделе" | "Контейнеризация и оркестрация — о разделе" |
| "Основы интеграционного взаимодействия — о разделе" | "Основы интеграционного взаимодействия — о разделе" |
| "Информационная безопасность — о разделе" | "Информационная безопасность — о разделе" |
Проверьте себя: Чек-лист самопроверки.