강제로 지운 git 히스토리 되돌려보기

1. Git이란 무엇인가?

• 형상 관리 시스템(VCS)의 진화: 중앙 집중형(SVN) vs 분산형(Git)
• Git이 소스코드를 스냅샷(Snapshot)으로 관리하는 방식
• 백엔드 아키텍처 관점에서 본 분산 버전 관리의 안정성과 이점

1) 형상 관리 시스템(VCS)의 진화: 중앙 집중형(SVN) vs 분산형(Git)

형상 관리 시스템은 개발 협업의 중심축 역할을 하며 중앙 집중형(CVCS)에서 분산형(DVCS)으로 진화해 왔습니다.

• 중앙 집중형 (SVN) 하나의 중앙 서버가 모든 소스코드의 역사와 버전을 독점적으로 관리하는 구조입니다. 개발자는 중앙 서버에서 최신 코드를 받아와(Checkout) 수정 후 다시 서버로 반영(Commit)합니다. 구조가 직관적이고 직무별 접근 권한 제어가 용이하다는 장점이 있지만, 중앙 서버에 장애가 발생하면 전체 개발팀의 커밋 및 이력 확인 작업이 완전히 마비되는 치명적인 단점(Single Point of Failure)이 있습니다. 히스토리 조회를 포함한 모든 작업이 네트워크 연결을 전제로 하므로 속도가 상대적으로 느립니다.
• 분산형 (Git) 중앙 서버가 존재하지만, 모든 개발자가 각자의 로컬 PC에 전체 저장소(Repository)와 히스토리의 완전한 복사본을 소유하는 구조입니다. 이로 인해 개발자는 네트워크 연결이 없는 환경에서도 로컬에서 커밋, 브랜치 생성, 이력 조회를 독립적으로 수행할 수 있습니다. 원격 서버와의 통신은 동기화(Push/Pull) 시에만 발생하므로 작업 속도가 압도적으로 빠르며, 중앙 서버가 다운되더라도 개별 로컬 저장소를 통해 시스템을 완벽하게 복구할 수 있는 고가용성을 자랑합니다.

2) Git이 소스코드를 스냅샷(Snapshot)으로 관리하는 방식

SVN과 Git을 가르는 가장 큰 기술적 차이는 데이터를 바라보는 메커니즘에 있습니다.

• SVN의 델타(Delta) 방식 소스코드의 기본 파일들을 두고, 파일의 변경된 '차이점(Delta)'만을 기록하는 정밀 파일 기반 방식입니다. 파일의 역사를 파악하려면 최초 상태부터 차이점들을 순차적으로 연산해야 하므로 성능 손실이 발생합니다.
• Git의 스냅샷(Snapshot) 방식 파일이 변경될 때마다 시스템의 현재 전체 상태를 하나의 '사진(Snapshot)'처럼 통째로 저장하는 방식입니다. 파일이 수정되면 수정된 파일의 전체 내용을 새로운 객체(Blob)로 생성하고, 수정되지 않은 파일은 새로 저장하지 않고 이전 스냅샷의 링크만 참조하여 저장 공간을 효율적으로 사용합니다.
• 체크섬(SHA-1) 기반 관리 Git은 모든 파일과 디렉토리 구조를 고유한 SHA-1 해시값(Checksum)으로 변환하여 콘텐츠의 무결성을 보장합니다. 파일 내용이 1비트라도 바뀌면 해시값이 완전히 달라지기 때문에, 과거의 특정 시점으로 안전하게 롤백(Rollback)하거나 데이터 유실 없이 브랜치를 전환하는 연산이 가볍고 신속하게 이루어집니다.

3) 백엔드 아키텍처 관점에서 본 분산 버전 관리의 안정성과 이점

백엔드 엔지니어의 시각에서 Git의 분산 구조와 스냅샷 메커니즘은 고가용성 분산 시스템 아키텍처와 매우 닮아 있으며, 개발 프로세스 전반에 강력한 안정성을 제공합니다.

• 무중단 배포 파이프라인(CI/CD)과의 호환성 서비스 다운타임을 최소화하는 MSA 환경에서 Git의 가벼운 브랜치 전략(Git Flow 등)은 필수적입니다. 스냅샷 기반의 빠른 브랜치 생성과 병합(Merge) 덕분에 기능별 배포 단위를 격리하기 쉬우며, 배포 중 장애가 발생하더라도 특정 스냅샷 해시값으로 즉각 롤백할 수 있어 인프라 운영의 안정성을 극대화합니다.
• 로컬 독립성을 통한 오프라인 내결함성 중앙 서버의 상태와 무관하게 개발자 개별 WAS나 컨테이너 환경에서 로컬 저장소를 기반으로 독립적인 빌드, 테스트, 커밋을 지속할 수 있습니다. 이는 중앙 저장소라는 단일 장애점(SPOF)을 제거하여 시스템 장애 상황에서도 조직의 전체 개발 생산성이 중단되지 않도록 방어합니다.
• 데이터 무결성과 추적성 데이터베이스의 트랜잭션 로그나 블록체인의 체인 구조처럼, Git의 커밋 히스토리는 이전 커밋의 해시를 참조하는 불변(Immutable)의 단방향 그래프 구조를 가집니다. 소스코드의 변조나 누락을 원천 차단하므로, 엔터프라이즈 환경에서 보안 규정을 준수하고 대규모 트래픽을 처리하는 소스코드의 이력을 투명하게 추적·관리할 수 있습니다.

2. 협업을 위한 대형 지도: Git Flow 브랜치 전략

• Git Flow의 핵심 브랜치 구조와 생명주기

• 항상 유지되는 메인 축: main(master)**, develop

• 살고 없어지는 보조 브랜치: feature**, release**, hotfix

• 대규모 엔터프라이즈 환경 및 팀 협업에서 Git Flow가 가져다주는 안정성

• 프로젝트 규모에 따른 Git Flow와 GitHub Flow의 트레이드오프

{ image }이미지 불러오는 중

3. CLI 환경에서 hard reset이나 force pull로 코드가 날아갔을 때 대응 프로토콜

협업 과정에서 배포 프로세스나 브랜치 전략(Git Flow)을 철저히 준수하더라도, 동료와 커밋 히스토리가 꼬이는 예기치 못한 상황은 언제든 발생할 수 있습니다. 수많은 조율 끝에 결국 git reset --hard나 force push/pull 같은 극단적인 명령어를 실행하는 순간, 로컬에 남아있던 수일간의 작업물이 한순간에 증발해 버리는 아찔한 경험을 마주하곤 합니다. 하지만 백엔드 엔지니어로서 이 위기를 단순히 좌절로 끝내지 않고, Git의 로우 레벨 저장 매커니즘을 짚어보며 유실된 코드를 추적하고 복구하는 아키텍처적 돌파구를 학습했습니다.

Git은 소스코드를 변경된 차이(Delta)가 아니라 상태 자체를 보존하는 스냅샷(Snapshot) 구조로 관리하며, 모든 객체는 고유한 SHA-1 해시 키를 기반으로 불변(Immutable) 상태로 저장됩니다. 분산 버전 관리 시스템의 특성상 로컬 저장소 역시 독립적인 히스토리 로그를 온전히 소유하고 있습니다. 비록 reset --hard로 인해 브랜치 포인터(HEAD)가 과거로 돌아가면서 최신 커밋들이 화면상에서 사라졌을지라도, 물리적인 스냅샷 데이터(Dangling Commit)는 저장소 내부에 여전히 살아 숨 쉬고 있습니다. 가시적인 브랜치 링크만 끊어졌을 뿐, 실제 데이터는 지워지지 않았다는 점에 착안하여 다음과 같은 단계별 복구 프로세스를 정리해 봤습니다.

• STEP 1. [가장 먼저] 현 상태 백업 브랜치 생성 (골든타임 확보)

• 더 이상의 상태 오염을 막기 위해 현재의 워킹 디렉터리와 인덱스 상태를 무조건 임시 브랜치로 격리하는 이유

• STEP 2. git clean 전 상태라면? Git History와 Log 추적

• 아직 추적되지 않은 파일(Untracked files)의 생존 여부 확인

• 일반 *git log*에 남지 않는 파괴적 명령의 흔적을 찾는 무기: git reflog git log는 현재 브랜치의 활성화된 커밋 트리만 보여주지만, git reflog는 로컬 저장소에서 HEAD 포인터가 이동한 모든 발자취(브랜치 전환, 리셋, 커밋, 머지 등)를 가감 없이 기록합니다. 명령어를 실행하여 코드 유실 직전, 즉 하드 리셋을 감행하기 바로 전 시점의 해시 값(HEAD@{index})을 찾아냅니다.

• STEP 3. 고립된 스냅샷(Dangling Commit) 확인 및 검증 찾아낸 해시 키의 내용을 검증하기 위해 git show <commit_hash> 명령어를 활용합니다. 이를 통해 해당 스냅샷 시점의 소스코드와 파일 상태를 직접 확인하여, 내가 복구하고자 하는 타겟 데이터가 맞는지 정밀하게 대조합니다.

• STEP 4. commit hash(해시 값)를 활용한 역순 복구 프로세스

• 삭제되거나 덮어씌워진 커밋의 고유 SHA-1 해시 값 찾아내기

• git reset --hard [hash] 또는 *git cherry-pick*을 활용해 타임머신처럼 원하는 시점으로 되돌리는 실전 CLI 명령어 원하는 시점의 커밋 해시를 확보했다면, git checkout -b <new_branch_name> <commit_hash>를 실행하여 해당 스냅샷을 기반으로 하는 새로운 독립 브랜치를 생성합니다. 이 과정을 통해 미궁에 빠졌던 소스코드가 완벽히 부활하며, 기존 작업 트리와 안전하게 재병합할 수 있는 상태가 됩니다.

건널 수 없는 강 **git clean**의 위험성

다만, 이 복구 메커니즘에도 명확한 기술적 한계가 존재합니다. 아직 커밋되지 않은 추적되지 않는 파일(Untracked files) 상태에서 git clean -fd같은 명령어를 수행해 버리면, Git의 스냅샷 객체(Blob)로 조차 등록되지 않은 완전한 날것의 파일들이 디스크 레벨에서 영구 삭제됩니다. 로컬의 reflog자체를 파괴하거나 인덱싱되지 않은 자원을 날려버리는 행위는 그야말로 복구가 불가능한 '건널 수 없는 강'을 건너는 것과 같으므로, 저와 같이 git flow가 꼬였을 때는 작업한 임시 branch를 우선 생성하고, 역순으로 하나씩 찾아가는 습관이 중요한 것같습니다.