Troubleshooting — Git для Junior Data Engineer

Q: Маркеры конфликта остались в файле (<<<<<<< HEAD)

После `git merge` или `git pull` был conflict, начали править, но сохранили файл, не удалив маркеры Открыли файл в редакторе без поддержки git merge view, неправильно resolved Сделали commit с маркерами (Git это разрешает!), pushed — теперь в репо broken файл В rebase решали conflict, не до конца отредактировали Открыть файл, удалить все три типа маркеров ( >>>>>>) и оставить корректную версию кода Использовать `git mergetool` (vimdiff, meld, VS Code) для guided resolve После правки: `git add ` (помечает как resolved) и `git commit` (или `git rebase --continue`) Если уже commit/push с маркерами — pre-commit hook должен ловить это: добавить `check-merge-conflict` от pre-commit Откатить плохой commit через `git revert` и сделать заново корректно

Question 1

Detached HEAD — как попал и как выйти

Accepted Answer

Сделали `git checkout ` или `git checkout ` напрямую IDE (VSCode, JetBrains) кликом по старому коммиту переключили вас После `git submodule update` — submodule всегда в detached HEAD Скрипт CI делает checkout commit SHA вместо ветки Сделали `git switch --detach ` намеренно Если НЕ делали изменений — просто `git switch main` (или нужная ветка), detached state исчезает Если СДЕЛАЛИ commits и хотите их сохранить — создать ветку: `git switch -c rescue-branch`, затем merge в main Если случайно сделали commits и НЕ хотите сохранять — просто `git switch main`, эти commits станут unreachable и через ~30 дней удалятся git gc Найти потерянные commits через `git reflog`, если уже переключились без branch создания Намеренный detached для эксперимента — это нормально, главное помнить вернуться через switch

Question 2

Маркеры конфликта остались в файле (<<<<<<< HEAD)

Accepted Answer

После `git merge` или `git pull` был conflict, начали править, но сохранили файл, не удалив маркеры Открыли файл в редакторе без поддержки git merge view, неправильно resolved Сделали commit с маркерами (Git это разрешает!), pushed — теперь в репо broken файл В rebase решали conflict, не до конца отредактировали Открыть файл, удалить все три типа маркеров (<<<<<<<, =======, >>>>>>>) и оставить корректную версию кода Использовать `git mergetool` (vimdiff, meld, VS Code) для guided resolve После правки: `git add ` (помечает как resolved) и `git commit` (или `git rebase --continue`) Если уже commit/push с маркерами — pre-commit hook должен ловить это: добавить `check-merge-conflict` от pre-commit Откатить плохой commit через `git revert` и сделать заново корректно

Question 3

git push rejected — non-fast-forward

Accepted Answer

Кто-то другой запушил commits в эту ветку после вашего последнего fetch Вы сделали `git reset --hard HEAD~3` локально и теперь local ветка короче remote Вы сделали rebase или amend на commit, который уже был push (история переписана) Сменили upstream branch и теперь push идёт не туда, куда вы думаете Если на remote есть НУЖНЫЕ commits — `git pull --rebase` (или `git fetch && git rebase origin/main`), резолвить конфликты, потом push Если делали rebase / amend намеренно и хотите перезаписать remote — `git push --force-with-lease` (БЕЗОПАСНЕЕ чем --force) Если ветка shared с командой — ОБЯЗАТЕЛЬНО предупредить перед force push В main / protected branch force push обычно запрещён branch protection — нужно делать через revert commit Никогда `git push --force` в main / develop без согласования

Question 4

git pull пишет 'divergent branches'

Accepted Answer

У вас локальные коммиты в ветке, на remote тоже появились новые коммиты — ветки разошлись Git 2.27+ перестал использовать merge как default — требует явный выбор Не сделали `git config pull.rebase` / `pull.ff` после установки Git Установить глобальный default (recommended): `git config --global pull.rebase true` для линейной истории Или: `git config --global pull.ff only` — pull только когда fast-forward возможен, иначе manual Разовый pull с merge: `git pull --no-rebase` Разовый pull с rebase: `git pull --rebase` В большинстве DE-команд — pull.rebase = true (или вообще запрещают pull, требуют fetch + rebase explicitly)

Question 5

Случайно сделал commit в main

Accepted Answer

Забыли `git switch -c feature/x` перед началом работы Открыли IDE, она автоматически переключила на main после прошлой сессии Скопировали репо или git pull привёл на main без вашего ведома Случай 1 (НЕ pushed): создать ветку с этими commits, потом откатить main
  git switch -c feature/actual-place
  git switch main
  git reset --hard origin/main Случай 2 (уже pushed в main, main protected): сделать revert commit:
  git revert <bad-commit-sha>
  git push
  потом перенести изменения в feature branch через cherry-pick Случай 3 (pushed, main НЕ protected, никто не pulled): force push (договорившись с командой):
  git reset --hard origin/main~1
  git push --force-with-lease
  потом cherry-pick в feature ВКЛЮЧИТЬ branch protection на main НЕМЕДЛЕННО — это первое, что делает любая адекватная DE-команда

Question 6

Запушил .env с секретами — playbook

Accepted Answer

Забыли добавить `.env` в `.gitignore` ПЕРЕД первым `git add .env` Скопировали `.env.example` в `.env`, заполнили секретами, сделали `git add .` — захватило новый файл Hardcoded secret в коде (config.py), а не в env-файле Нет pre-commit hook (gitleaks, detect-secrets) который ловит это ШАГ 1 (немедленно): ROTATE все скомпрометированные secrets — изменить пароли, regenerate API keys, revoke tokens. Это самое важное — file нельзя 'отозвать' из internet ШАГ 2: добавить `.env` в `.gitignore`, удалить из tracking: `git rm --cached .env && git commit -m 'chore: remove .env from tracking'` ШАГ 3 (очистка истории): `git filter-repo --invert-paths --path .env` (или BFG). Это переписывает ВСЮ историю. Если pushed — force push: `git push origin --force --all && git push origin --force --tags` ШАГ 4: уведомить команду — все должны заново clone репо (старые clones содержат secrets) ШАГ 5: настроить prevention — pre-commit gitleaks/detect-secrets, GitHub Secret Scanning, ревью .gitignore до первого commit

Question 7

fatal: not a git repository

Accepted Answer

Вы в каталоге, в котором нет `.git/` (и его нет ни в одном parent каталоге) Сделали `cd` в неправильную папку Случайно удалили `.git/` (например `rm -rf .git/`) Распаковали zip с кодом — там нет `.git/`, нужно clone или init Поломанный submodule — `.git` это файл, а не каталог, и ссылается на несуществующий путь Перейти в правильный каталог: `cd path/to/repo` Если нет `.git/` — это не git repo. Либо clone заново: `git clone <url>`, либо init если новый проект: `git init` Если .git был удалён случайно — восстановить из backup или clone заново с remote Для submodule — проверить `.git` файл, который содержит `gitdir: ../../.git/modules/...` Если работаете внутри docker-volume mount — проверьте, что .git тоже примонтирован

Question 8

fatal: refusing to merge unrelated histories

Accepted Answer

Сделали `git init` локально, потом добавили remote с уже существующим репо — две независимых истории Merged два независимых репозитория (например, перенос проекта) Случайно clone не тот репо, добавили remote с правильным — истории разошлись от Big Bang Один из репо был `filter-repo` или `filter-branch`-ed — все SHA новые, общего предка с оригиналом нет Если намеренно объединяете два репо — использовать флаг: `git pull origin main --allow-unrelated-histories` или `git merge --allow-unrelated-histories` Если это ошибка (вы clone не тот репо или сделали init вместо clone) — удалите local, clone правильный заново При переносе содержимого нового проекта в существующее репо — используйте git subtree или просто скопируйте файлы вручную Если был filter-repo на одной стороне — придётся принять unrelated histories или восстанавливать оригинал

Question 9

Закоммитил большой файл (.csv 500MB)

Accepted Answer

Случайно `git add .` захватил большой dataset Тестировали ETL на маленьких файлах, не настроили `.gitignore` для `data/` Думали добавить через LFS, забыли `git lfs track` перед `git add` Закоммитили build artifact (model.pkl, embeddings.npy) Случай 1 (НЕ pushed): просто удалить и amend: `git rm --cached data.csv && echo data.csv >> .gitignore && git commit --amend --no-edit` Случай 2 (pushed, есть в истории): удалить из всей истории через git-filter-repo: `git filter-repo --invert-paths --path data.csv`, затем `git push --force-with-lease --all` ИЛИ через BFG: `bfg --strip-blobs-bigger-than 50M`, потом `git reflog expire --expire=now --all && git gc --prune=now --aggressive` Для будущего: настроить LFS — `git lfs install && git lfs track '*.csv' && git add .gitattributes`, или DVC для ML datasets Добавить `data/`, `*.csv`, `*.parquet`, `*.pkl` в `.gitignore` и закоммитить Команды должны re-clone после filter-repo — old clones содержат большой файл

Question 10

Упустил коммит после git reset --hard (reflog rescue)

Accepted Answer

git reset --hard перемещает branch указатель назад, оставляя 'покинутые' commits unreachable Похожее происходит при rebase --abort после многих rebase steps После `git checkout -B` (форсированно создать ветку поверх существующей) После `git push --force` без --force-with-lease — но это не помогает локально, только если был backup remote Восстановить через reflog: `git reset --hard HEAD@{1}` (или конкретный SHA из reflog) Если работали в branch и сделали reset — можно `git branch rescue HEAD@{1}` создать ветку прямо там Если reset был очень давно и `git gc` уже прошёл — restore может быть невозможен. Reflog default expire 90 дней (refs/heads), 30 дней (unreachable) Поискать через `git fsck --unreachable --no-reflogs` — list of dangling commits ПРАВИЛО: ВСЕГДА перед `git reset --hard` сделать backup ветку: `git branch backup-$(date +%s)`

Question 11

Забыл git pull перед работой — теперь конфликт

Accepted Answer

Не выработана привычка: первое действие в начале дня — `git fetch && git status` IDE не показывает behind-status автоматически Работали в long-lived feature branch — не делали regular rebase на main У команды нет conventions о синхронизации (например, daily rebase на main) Делать `git pull --rebase` или `git fetch && git rebase origin/main` — резолвить конфликты Перед rebase — закоммитить или stash свою работу В IDE (VS Code, JetBrains) — включить auto-fetch каждые N минут чтобы видеть behind-status Привычка: первое утром — `git pull --rebase` в main, потом в feature `git rebase main` Для long-lived feature branches — делать regular rebase минимум раз в день Договориться с командой о small / quickly-merged PRs — long-lived branches накапливают конфликты

Question 12

Your branch is ahead of 'origin/main' by N commits

Accepted Answer

Сделали локальные коммиты, ещё не запушили — нормальная ситуация для feature branch Если на main — закоммитили прямо в main (это другая проблема, см. accidental-commit-to-main) После rebase локальная история переписана, ahead показывает новые SHA, behind — старые Кто-то force-pushed на remote и теперь у вас «ahead» из-за расхождения SHA Если это feature branch и всё ок — просто `git push` (с -u при первом push) Если на main и не должны быть commits — см. troubleshooting 'accidental-commit-to-main' Если показывает 'ahead by 3 and behind by 5' — расхождение, нужен rebase: `git pull --rebase` Если после rebase 'ahead by N' где N = количество rebased commits — нормально, нужен `git push --force-with-lease`

Question 13

Permission denied (publickey) — SSH

Accepted Answer

SSH-ключ не сгенерирован Public key не добавлен в GitHub/GitLab account Используется wrong SSH-ключ (несколько identities) ssh-agent не запущен или ключ не добавлен Permissions на `~/.ssh/` или `id_ed25519` слишком открытые URL HTTPS вместо SSH — публичный ключ для HTTPS не работает Заблокирован порт 22 на корпоративной сети Если нет ключа — сгенерировать: `ssh-keygen -t ed25519 -C 'you@email.com'` Добавить public key в GitHub: Settings -> SSH and GPG keys -> New SSH key, вставить `cat ~/.ssh/id_ed25519.pub` Запустить ssh-agent и добавить: `eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_ed25519` Fix permissions: `chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_ed25519 && chmod 644 ~/.ssh/id_ed25519.pub` Если URL HTTPS — переключить на SSH: `git remote set-url origin git@github.com:user/repo.git` Если порт 22 заблокирован — использовать SSH over HTTPS port 443: см. https://docs.github.com/en/authentication/troubleshooting-ssh/using-ssh-over-the-https-port Несколько ключей? Настроить `~/.ssh/config` с Host-specific IdentityFile

Question 14

.git/index.lock exists

Accepted Answer

Параллельно запущена другая git команда (IDE auto-fetch + manual command) Предыдущая git команда crashed (Ctrl+C посередине, killed process) Антивирус / Spotlight indexing открыли .git/index в момент write VSCode/JetBrains git integration делает свою операцию На сетевом drive (NFS) — lock не освободился Убедиться, что нет активных git процессов: `ps aux | grep git` Закрыть IDE на минуту, проверить Если lock висит давно (минут 5+) и нет процессов — удалить вручную: `rm .git/index.lock` Также проверить другие locks: `rm -f .git/{HEAD.lock,refs/heads/main.lock,packed-refs.lock}` Никогда не использовать `kill -9` для git процесса — оставляет locks. Use `kill` (SIGTERM) Не хранить git репо на сетевом drive (NFS, SMB) — кучи проблем с lock

Question 15

modified content, untracked content в submodule

Accepted Answer

Внутри submodule есть изменения файлов (modified content) Внутри submodule есть новые untracked файлы Submodule на каком-то commit, который отличается от того, что записан в parent repo Кто-то изменил submodule contents без commit/push в самом submodule После `git submodule update --remote` submodule moved forward Если submodule намеренно обновлён — commit это в main repo: `git add path/to/submodule && git commit -m 'chore: bump submodule'` Если submodule содержит unwanted changes — сбросить: `cd submodule && git reset --hard && git clean -fd` Чтобы синхронизировать с записанным в main repo: `git submodule update --init --recursive` Чтобы обновить до latest на remote: `git submodule update --remote --merge` В .gitmodules можно указать branch вместо фиксированного commit для auto-tracking Если submodule всё ещё путает — рассмотреть git subtree или git worktree как альтернативу

Question 16

Неправильный author в коммите — нужно переписать

Accepted Answer

Не настроили `user.email` / `user.name` после установки Git Глобальный config с одним email, но для work репо нужен другой (или наоборот) В config один email, а в системе $GIT_AUTHOR_EMAIL — другой Скопировали репо с другой машины с прошлым config Установить правильный для текущего репо: `git config user.email work@company.com` Для всех будущих репо: `git config --global user.email correct@email` Per-folder config (Git 2.13+) — `~/.gitconfig` с `[includeIf "gitdir:~/work/"] path = ~/.gitconfig-work` Переписать последний commit: `git commit --amend --author='Lev ' --no-edit` Переписать несколько последних: `git rebase -i HEAD~3 --exec 'git commit --amend --author="Lev " --no-edit'` ПЕРЕписать ВСЮ историю (опасно для shared repo): `git filter-repo --mailmap mailmap.txt` Pre-commit hook, валидирующий author email по regex — для прода-репо

Question 17

Git LFS не работает / large file warning

Accepted Answer

Не установлен git lfs: `git lfs install` не выполнен `.gitattributes` не настроен (или настроен, но забыт после клонирования) Сначала добавили файл, потом настроили LFS — файл уже в обычном объекте После clone не сделали `git lfs pull` — есть только pointers На server (self-hosted GitLab) LFS не включён Quota на LFS storage исчерпана (GitHub limits) Установить и инициализировать: `git lfs install` (one-time per user) После clone подтянуть актуальные файлы: `git lfs pull` Track patterns в .gitattributes ДО добавления файла: `git lfs track '*.parquet' && git add .gitattributes` Если файл уже как обычный blob — migrate в LFS: `git lfs migrate import --include='*.parquet'` (переписывает историю!) После migrate force push: `git push --force-with-lease --all` Проверить LFS quota на GitHub Settings -> Billing -> Git LFS Для DE often лучше DVC чем LFS — особенно для часто меняющихся datasets

Question 18

pre-commit hook падает и блокирует commit

Accepted Answer

Реальная проблема в коде (linter нашёл issue) — pre-commit делает что должно Auto-fixer (ruff-format, black) исправил файл, но не закоммитил — нужен повторный add Версия hook в конфиге устарела, что-то изменилось Hook требует tool (например ruff) — не установлен в venv False positive — secret-detector нашёл что-то, что не secret .pre-commit-config.yaml broken — невалидный YAML Прочитать output и исправить реальные проблемы в коде После auto-fix — `git add <fixed-files> && git commit` снова Если hook упал на legitimate code — добавить exclusion: `exclude: ^(tests|legacy)/` в config Update hooks: `pre-commit autoupdate` Скипнуть конкретный hook одноразово: `SKIP=ruff git commit -m 'msg'` Скипнуть все hooks (плохая практика, не делать regularly): `git commit --no-verify` Для detect-secrets baseline: `detect-secrets scan --baseline .secrets.baseline` Установить инструменты в venv: `pip install ruff black isort` и `pre-commit install --install-hooks`

Question 19

Кириллица в именах файлов сломалась

Accepted Answer

core.quotePath = true (default) — Git escape non-ASCII в выводе Разные кодировки имён файлов на разных OS (macOS NFD vs Linux NFC vs Windows) Терминал не настроен на UTF-8 (особенно cmd.exe на Windows) Локаль системы не UTF-8 (LANG=C вместо LANG=en_US.UTF-8) Файл создан на Windows с CP1251 в имени Отключить escape в Git: `git config --global core.quotePath false` Установить UTF-8 локаль (Linux): `export LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8` На macOS — Terminal preferences -> Profiles -> Advanced -> Text encoding: Unicode (UTF-8) На Windows — Git Bash работает лучше, чем cmd.exe; для PowerShell: `[Console]::OutputEncoding = [System.Text.Encoding]::UTF8` Избегать кириллицы в именах файлов в production проектах (de-facto convention) Если уже есть кириллица — `git mv old.csv new.csv` чтобы переименовать в ASCII (или транслит) core.precomposeUnicode = true для macOS чтобы избежать NFD/NFC проблем

Question 20

Line endings: CRLF vs LF

Accepted Answer

На Windows default line ending — CRLF (
), на Linux/macOS — LF (
) core.autocrlf настроен по-разному на машинах команды Нет `.gitattributes` — Git гадает, как обработать shell-скрипт (.sh) с CRLF не работает на Linux: `bash: ./script.sh: /bin/bash^M: bad interpreter` Файл создан в Notepad (CRLF) и закоммичен — теперь в репо смесь Настроить `.gitattributes` (recommended, per-project): `* text=auto eol=lf` и `*.sh text eol=lf` для shell scripts Глобально на dev машине Linux/macOS: `git config --global core.autocrlf input` На Windows: `git config --global core.autocrlf true` (CRLF в working tree, LF в repo) Исправить уже закоммиченные файлы: `git add --renormalize .` после установки .gitattributes Конвертировать существующий файл: `dos2unix script.sh` или `tr -d '' < in > out` В IDE (VS Code) настроить default eol = LF На pre-commit добавить hook `mixed-line-ending --fix=lf`

Question 21

Rebase сломал ветку — как восстановить

Accepted Answer

Conflict resolved неправильно — сделали `git add` и `--continue` с broken merge Пропустили часть кода при resolving — он потерялся В interactive rebase случайно отметили коммит как `drop` или `squash` (вместо pick) `--abort` после серии resolved conflicts — все resolutions потеряны Rebase на wrong base — например на origin/feature вместо main Спасение через reflog: найти SHA до rebase (обычно `HEAD@{N}` перед 'rebase (start)') и `git reset --hard HEAD@{N}` Если rebase ещё в процессе — `git rebase --abort` возвращает к начальному состоянию Создать ветку перед rebase КАЖДЫЙ раз — backup: `git branch backup-before-rebase`. Тогда если что — `git reset --hard backup-before-rebase` Если потеряли изменения в файле — `git fsck --lost-found` может найти orphaned blobs Не делать rebase шибко больших ranges (>20 commits) — разбейте на несколько мелких Для shared branches НЕ делать rebase вообще — только merge

Question 22

fatal: ambiguous argument

Accepted Answer

Указан не существующий branch / commit / tag Опечатка в имени ref (`mian` вместо `main`) Branch local — но указан как remote (нужно origin/main вместо main) Default branch переименован (master -> main), скрипт ссылается на старое имя Файл с тем же именем что и ветка — Git не знает, что вы имели в виду После filter-repo / fresh clone — local refs из старой истории отсутствуют Проверить правильное имя ветки/тега — `git branch -a` показывает все Если ветка remote — добавить `origin/`: `git diff origin/main feature` Если master -> main rename: `git branch -m master main && git fetch && git branch -u origin/main main` Если конфликт с файлом — использовать `--`: `git log -- main` (главой считать main как файл) или `git log main --` (как ref) После clone с пустыми branches — `git fetch --all` подтянет remote refs При работе со скриптами всегда use full refs: `refs/heads/main`, `refs/remotes/origin/main`, `refs/tags/v1.0`

Question 23

Случайный commit бинарника — репо весит 2GB

Accepted Answer

Когда-то закоммитили большой бинарник (model.pkl, dataset.parquet, video.mp4) Даже если удалили в новом commit — он в истории навсегда Случайно `git add .` забрал build directory, dist/, node_modules/ Закоммитили IDE индексы (.idea/, .vscode/cache/) В CI artifact пушится в репо вместо artifact storage Поколение docker images или ML models versioned в git Удалить большие файлы из истории через `git filter-repo --strip-blobs-bigger-than 10M` Или конкретный путь: `git filter-repo --invert-paths --path data/large.parquet --path models/` Альтернатива BFG: `bfg --strip-blobs-bigger-than 50M repo.git` После filter-repo: `git reflog expire --expire=now --all && git gc --prune=now --aggressive` Force push: `git push --force --all && git push --force --tags` (TEAM должна re-clone!) Для будущего — настроить LFS для бинарников ИЛИ DVC для datasets/models Pre-commit hook check-added-large-files (от pre-commit framework) — блокирует commits с файлами > N MB

Question 24

fatal: bad object

Accepted Answer

Физическое повреждение диска (bad sectors, недоописанные блоки) Принудительное выключение / kill процесса git во время write Антивирус scan и quarantine .git/ файлов Manual edit (или удаление) файлов в .git/objects/ Файловая система проблемы (NFS / SMB hung writes) Сбой при `git gc` или packfile corruption Если есть remote — clone заново в другой каталог и работать оттуда (самое простое решение) Если local важен — попытаться восстановить отсутствующий объект из remote: `git fetch origin --depth 1` и потом полный fetch Удалить broken object и пересохранить: `rm .git/objects/3a/8c2f1...; git fetch --all` Восстановить из reflog: `git fsck --lost-found && git reflog` Если pack повреждён — `git unpack-objects < broken.pack` экстрагирует целые objects Профилактика: backups, не kill -9 git процессов, регулярный `git fsck`

Question 25

Merge закоммитил, но потом понял что не надо

Accepted Answer

Merged в неправильную ветку (feature -> develop, а нужно было feature -> main) Merged не готовую ветку (без CI green, без code review) Случайно скриптом сделали merge вместо namespace-level rebase Auto-merged через `gh pr merge` в спешке Если НЕ pushed — `git reset --hard HEAD~1` отменяет merge commit полностью Если pushed и safe — `git reset --hard HEAD~1 && git push --force-with-lease` (опасно для team) Если pushed и main protected (правильный setup) — нельзя reset. Используйте `git revert -m 1 <merge-sha>` чтобы создать revert commit Revert merge через `-m 1` указывает 'parent 1' (то есть main branch line) как сторону, которую сохранить ВАЖНО: после revert merge, повторный merge той же feature ветки НЕ применит изменения снова. Чтобы 'разморозить' — нужен revert revert или новая feature ветка В будущем — настроить branch protection требующее approve + CI status check

Question 26

Could not resolve host: github.com

Accepted Answer

Нет интернета / DNS проблемы Корпоративный proxy без правильного config VPN режет/блокирует github.com ISP блокирует git domains (в РФ периодически случается) `/etc/hosts` имеет неправильную запись github.com DNS server даёт outdated / cached IP Проверить интернет / VPN — открыть https://github.com в браузере Настроить Git proxy: `git config --global http.proxy http://proxy:8080` Если SSH блокирован — попробовать HTTPS вариант (можно изменить remote URL): `git remote set-url origin https://github.com/user/repo.git` Если HTTPS блокирован — SSH over port 443: добавить в `~/.ssh/config`: `Host github.com
    Hostname ssh.github.com
    Port 443
    User git` Использовать VPN, если есть geo-blocking Если внутри docker container — проверить network config контейнера (host networking может помочь)

Question 27

Переключился на другую ветку и потерял незакоммиченные изменения

Accepted Answer

git switch переносит uncommitted changes между ветками, если они не конфликтуют — это feature, не bug Изменения, не закоммиченные и не stashed, существуют только в working tree Если потом пришли изменения с pull/rebase/checkout — working tree перезаписался Файл был untracked, не staged — Git его не отслеживает вообще Если файлы были untracked и просто переключение НЕ удалило их — должны быть на месте, проверить `git status` Если staged — `git fsck --lost-found` ищет blobs, не attached к коммитам. Найденные blob можно открыть: `git cat-file -p ` Если был auto-stash при switch (Git 2.27+ feature на некоторых config) — `git stash list` Если файлы перезаписались — recovery ОЧЕНЬ ограниченно. IDE local history (VS Code, JetBrains) — последняя надежда ПРАВИЛО: ВСЕГДА `git stash` или `git commit` перед switch, если есть незакоммиченные изменения Современный workflow: `git switch -m ` (merge mode) ИЛИ enable `--autostash` для switch

Категория

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы

Причина

Решение

Симптомы