Git에서 파일을 잃어버렸나요? 삭제된 파일 및 커밋되지 않은 파일 복구하기
A branch switch leaves your source folder looking empty. A hard reset removes this morning’s edits. Or a cleanup command deletes a script you never committed. These git lost files situations look similar, but the right recovery method depends on whether Git ever stored the missing content.
Missing from your working folder does not necessarily mean gone from the repository. A commit, the staging area, another branch, or a stash may still contain a usable copy. Start with those locations before you scan a disk.
This guide follows that order. If Git has no copy and the actual file has disappeared from storage, the 삭제된 파일 복구 가이드 covers the next branch. For that specific Windows scenario, Magic Data Recovery offers a storage-level recovery option; it does not reconstruct Git history.
목차
Git Lost Files: Choose the Right Recovery Method
The quickest answer: restore a tracked file from the index or a known commit. Check reflog for lost commits and local history for edits Git never saved. Use disk recovery only when no usable copy remains.
무슨 일이 있었나요? | Where a copy may exist | Start here |
You deleted a tracked file without staging the deletion | Git’s index | Restore the individual path |
You staged the deletion or used | The last commit | Restore that path from |
You committed the deletion | An earlier commit | Find a revision that contains the file |
A reset, rebase, or amend hid a commit | Local reflog | Create a recovery branch at the old commit |
You staged content but never committed it | Index or surviving blob objects | Check the index, then inspect objects |
You never added, committed, or stashed the content | Editor history, backups, original disk | Check copies before disk recovery |
Files vanished after switching branches | Another branch or checkout configuration | Confirm location and branch first |
This distinction matters for Git recover uncommitted files searches: “uncommitted” includes both staged content and changes Git has never stored. Those two cases have different recovery limits.
Protect the Repository Before Trying Commands
Pause builds, dependency installs, and automated cleanup. If the drive works normally, copy the repository to another physical drive, including hidden Git metadata. A normal clone does not preserve all local recovery clues, such as your index, reflog, and unreachable objects.
For linked worktrees or submodules, .git may be a pointer file rather than a directory. Preserve the Git directory it references too. If you suspect physical drive failure, stop ordinary copying and scanning and seek professional recovery help.
Avoid these commands during recovery:
git reset --hard, which discards tracked working changes and can remove obstructing untracked paths.git clean -fd또는git clean -fdx, which removes untracked content;-xalso includes ignored files.git gc --prune=now그리고git prune, which can remove objects you still need.
Git’s reset documentation 그리고 clean documentation explain these effects. A whole-repository rollback is usually unnecessary when you only need one missing file.
Use the examples below from the repository root. Replace sample filenames and hashes with your own. The restore commands require Git 2.23 or later and work in Git Bash on Windows, as well as macOS and Linux terminals.
Check Whether the File Is Missing or Simply Elsewhere
시도하기 전에 Git file recovery, confirm which repository and branch you opened:
- git rev-parse –show-toplevel
git status --shortgit branch --show-currentgit branch --all
Next, search Explorer or Finder using the exact filename, extension, and approximate modification time. Check another checkout, a renamed project folder, external storage, and your editor’s excluded folders.
Three Git concepts explain most git lost files cases:
- Working tree: the files you currently edit.
- Index: the content you selected with
git addfor the next commit. - Commit: a saved project snapshot in Git history.
Git does not automatically save every edit. Staging captures the content at that moment, so later edits may exist only in your working tree. See Git’s guide to recording changes.
Recover Deleted Files in Git Before Committing
최적 대상: a tracked file that you deleted locally while the repository still contains its content.
First, inspect the path:
git status --short -- src/app.jsgit diff -- src/app.jsgit diff --cached -- src/app.js
In short status, the first column describes index changes; the second describes working-tree changes. D means an unstaged deletion. D means a staged deletion.
Restore an Unstaged Deletion from the Index
To recover deleted files in Git when the index still contains the file:
git restore -- src/app.js
This restores the staged version, which may differ from the last commit. For example, if you staged an updated function before deleting the file, Git can bring back that staged content. It cannot also recover later unstaged edits through this command.
Restore a Staged Deletion from HEAD
If you staged the deletion, the index no longer holds the file at that path. After preserving any useful copy, restore its last committed version:
git restore --source=HEAD --staged --worktree -- src/app.js
This changes both the index and the working file for that path. It does not bring back a newer, uncommitted version. Git’s restore documentation explains the source and destination options.
For a newly added file in a repository with no commits, HEAD does not yet exist. If the index still contains the file, use the index-based method instead.
Restore a File from an Earlier Commit or Another Branch
최적 대상: a committed deletion, an older file version, or a file missing only from your current branch.
Start with its history:
git log --all --oneline -- src/app.js
If you cannot remember its old path, list deletion records:
git log --all --diff-filter=D --summary
Inspect a candidate commit before restoring anything:
- git show abc1234:src/app.js
교체 abc1234 with a commit that actually contains the file. Then restore only that path:
git restore --source=abc1234 -- src/app.js
만약 abc1234 is the deletion commit, inspect its parent with git show abc1234^:src/app.js. For a simple deletion, the parent may hold the desired version. Merge commits have multiple parents, so verify the content instead of assuming the first parent is correct.
For Git missing files after switching branches, inspect the branch that contains the file:
- git show feature/login:src/app.js
git restore --source=feature/login -- src/app.js
These examples preserve your current branch and other files. Check the Git log documentation for history searches and the Git show documentation for inspecting stored content. History searches may need the old filename if someone renamed the file.
Use Reflog for Git Lost Changes After a Reset
최적 대상: committed work that disappeared from visible history after a reset, rebase, amend, or branch movement.
For git reset hard recovery, inspect your local reference history:
- git reflog –date=local
Look for the commit before the unwanted operation. Confirm its content, then preserve it under a new branch name:
- git show –stat abc1234
git branch recovery-lost-work abc1234
Creating the branch does not switch your working tree. You can inspect or restore individual files from it afterward.
Reflog does not record every file edit. It records reference movements. If the missing content never entered a commit, reflog alone cannot recover it. Entries and objects also have limited retention. Git explains the mechanism in its reflog documentation.
For git lost files after deleting a branch, the official Git data recovery guide describes rescuing surviving commits. Preserve a useful commit promptly once you identify it.
Check Stashes and Staged but Uncommitted Content
Recover Files from a Stash
가정하기 전에 Git lost changes permanently, check whether you put them aside:
- git stash list
- git stash show –include-untracked –name-only ‘stash@{0}’
- git stash show -p –include-untracked ‘stash@{0}’
Choose the stash by its contents, not just its date. In a protected copy with a clean working tree, apply the correct entry:
- git stash apply ‘stash@{0}’
와 달리 pop, apply keeps the entry in the stash list. It can produce conflicts, so review the result before continuing.
A default stash does not include untracked files. Those require -u when creating the stash; ignored files require -a. Consult the Git stash documentation.
Recover Staged Content from Surviving Objects
For Git recover uncommitted files cases where you previously ran git add, check whether the index still holds the content:
- git ls-files –stage — src/app.js
- git show :src/app.js
The second command displays the indexed version. The Git ls-files documentation describes how to inspect index entries.
If a reset replaced the index, a blob containing the staged content may still survive. Work on your preserved repository copy:
- git fsck –full –no-reflogs –unreachable
For an unreachable blob candidate, inspect its content:
- git cat-file -p BLOB_HASH
교체 BLOB_HASH with an actual object ID. Look for a distinctive function, comment, or configuration value. Blobs contain content, not the original filename, so identification can take time.
For dangling objects, git fsck --lost-found writes recovery material under .git/lost-found/. It does not promise to export every unreachable object or recreate a complete directory tree. See Git fsck 그리고 Git cat-file.
Export a confirmed blob to a new file on another drive using Git Bash output redirection or a byte-preserving export method. Avoid copying binary content from terminal output. This route helps with Git staged files recovery, but only while the relevant objects remain intact.
Recover Untracked Files Through Editor History and Backups
최적 대상: deleted files or newer edits that Git never added, committed, or stashed.
To recover untracked files, check your editor before scanning storage. In VS Code, open the Command Palette and run:
- 지역사: 복원할 항목 찾기
Select the missing file, inspect available entries, and compare their content. For an existing file, the Timeline view can also show local history. Availability depends on saved entries, settings, and retention; it is not a guaranteed record of unsaved typing. Microsoft documents this in the VS Code user interface guide.
Next, inspect the Recycle Bin or Trash, cloud deleted items, cloud version history, and system backups. Terminal deletion commands may bypass the Recycle Bin. Check your original storage path rather than assuming every file in the project lived inside the repository.
A remote repository can restore pushed commits, but it does not automatically contain local untracked files, unsaved edits, or private stashes. Ask teammates about separate copies if the missing work was shared elsewhere.
For git clean recovery, these external copies are especially important: Git cannot recover content it never stored merely because the deletion happened inside a repository.
When Git Lost Files Require Disk Recovery
Move to storage recovery only after answering these questions:
- Does the correct branch, index, commit, stash, or surviving object contain the needed version?
- Can your editor, cloud history, or backup supply it?
- Is the actual file missing from its original storage location?
- Does the device remain stable and detectable?
If no usable copy exists and the file has truly disappeared, git lost files becomes a disk-level problem. Examples include an untracked script removed by cleanup, a deleted project directory, or a formatted drive containing local work.
Recover Deleted Project Files with Magic Data Recovery
Magic Data Recovery supports Windows recovery scenarios involving deletion, formatting, and file-system errors. Its scanning and filtering workflow offers a practical way to inspect recoverable project files when Git has no stored copy.
Windows 7/8/10/11 및 Windows Server 지원
The relevant advantage is scope: Git searches its own records, while this tool scans the original storage. For a deleted local script or project archive, that makes it a more appropriate next step than repeatedly running Git commands. The visual scan-and-review workflow also lets you check candidates before returning them to the project.
Follow four steps:
- Set up safely. Install and run the tool from another drive or computer where practical. Minimize writes to the affected device.
- Scan the original volume. Select the drive that held the missing files, even if your current checkout sits elsewhere.
- Review candidates. Use available filename, path, and type filters. Preview supported formats; validate source files in an editor after export.
- 다른 곳에서 회복하세요. Save selected files to a different physical drive and keep the original repository untouched until verification.
Recovery may return older versions, incomplete files, or changed names. The tool cannot invent unsaved code, rebuild missing commit relationships, or restore dependencies automatically. Its suitability here comes from addressing actual storage loss after native recovery options fail.
Validate Recovered Files Before Rejoining the Project
For Git lost files recovery, success means usable content, not just a filename in a scan result.
Open recovered source files in a separate folder. Check important functions, encoding, line endings, and whether the latest changes actually exist. File size and timestamps offer clues, but they do not prove you found the correct version.
Compare the candidate with the current project. Copy only verified files into a protected working checkout, review git diff, and run the relevant build or tests. Confirm configuration files and external assets separately.
Finally, commit the restored changes on a recovery branch. Avoid replacing an entire .git directory with partially recovered metadata; recover source content separately if repository integrity remains uncertain.
If Recovery Fails, Check the Limitation
A deeper scan cannot recreate overwritten content. SSD TRIM and subsequent device cleanup can also make deleted data unavailable. Microsoft’s Windows File Recovery guidance recommends reducing drive use and saving recovered data to a separate drive.
If the device disconnects repeatedly, makes unusual noises, or produces read errors, stop repeated scans. For a stable device, recheck the original volume and any external backups before trying further software.
일부 Git missing files need a different explanation. Sparse checkout intentionally leaves some tracked paths out of the working tree, while submodules maintain separate repository content. Inspect those configurations before treating an empty folder as deletion. Git documents sparse checkout 그리고 submodule initialization.
Prevent Git Lost Files in Future Work
Commit useful milestones and push important branches to a remote. Before cleaning a workspace, preview the affected paths with git clean -nd; if you intend to include ignored files, inspect git clean -ndx too.
Keep editor local history enabled and back up the full project folder. Include untracked resources and external assets that a Git remote cannot replace. Review .gitignore deliberately: ignoring a valuable file does not create a backup of it.
Before a reset or rebase, preserve ongoing work and check what your backup or stash actually includes. A short verification now can save hours of reconstruction later.
Conclusion: Match Git Lost Files to the Copy That Still Exists
최고 git lost files solution depends on where the missing version survives. Use the index or a commit for tracked files, reflog for lost commits, and editor history or backups for content Git never stored.
If those checks confirm actual storage loss, Magic Data Recovery is a reasonable Windows option because it addresses deletion, formatting, and file-system errors beyond Git’s records. Follow the 삭제된 파일 복구 가이드, save candidates elsewhere, and verify the code before returning it to your project.
Windows 7/8/10/11 및 Windows Server 지원
자주 묻는 질문
1. Git은 커밋된 적이 없는 파일을 복구할 수 있나요?
git add 또는 임시 저장소에 저장되어 있을 수도 있습니다. Git에 누락된 버전이 저장된 적이 없다면, 편집기의 로컬 기록, 백업 파일, 클라우드 사본을 확인해 보세요. 실제로 삭제된 후에는 디스크 복구가 도움이 될 수 있지만, 메모리에만 존재했던 코드는 복원할 수 없습니다.2. 모든 설정을 초기화하지 않고 삭제된 파일을 복구하려면 어떻게 해야 하나요?
git restore -- 파일 경로. 삭제를 단계적으로 진행했다면, 다음 경로에서 경로를 복원하십시오. HEAD 와 함께 --staged --worktree. 파일을 완전히 삭제하려면, 해당 파일이 포함된 이전 리비전을 찾아 그 경로만 복원하십시오. 어떤 내용도 덮어쓰기 전에 최신 내용은 반드시 보존하십시오.3. git reflog는 커밋되지 않은 변경 사항을 복원할 수 있나요?
4. git clean -fd 명령어를 실행한 후에도 파일을 복구할 수 있나요?
5. 파일이 누락되었는데도 git pull 명령어가 ‘최신 상태’라고 표시되는 이유는 무엇인가요?
git status 그리고 해당 소스에서 추적된 삭제 항목을 복원하십시오. 또한 현재 브랜치와 스파스 체크아웃 설정을 확인하고, 누락된 폴더가 서브모듈에 속하는지 여부도 확인하십시오.6. Git은 분실 및 발견된 파일을 어디에 저장하나요?
git fsck --lost-found 다음 위치에 매달린 복구 객체를 기록합니다. .git/lost-found/commit/ 또는 .git/lost-found/other/. 블롭 항목에는 파일 내용이 포함되어 있지만, 대개 원래 파일 이름이 없습니다. 연결된 워크트리에서는 이러한 폴더를 찾기 전에 실제 Git 메타데이터 디렉터리를 찾아야 합니다.7. Magic Data Recovery로 전체 Git 저장소를 복원할 수 있나요?
8. 이전 버전의 Git으로 복원하면 최근에 수정한 내용이 복구되나요?
