Git 주니어 CS 기초 면접

Git은 파일의 내용을 기반으로 SHA-1 해시를 생성하여 Blob 객체로 저장합니다. 동일한 내용의 파일은 항상 같은 해시값을 가지므로, Git은 중복된 Blob 객체를 생성하지 않고 기존 객체를 재사용합니다. 이를 content-addressable storage라고 하며, 파일명이나 위치가 달라도 내용이 같으면 하나의 객체만 저장되어 공간 효율성이 높습니다. 또한 Git은 주기적으로 packfile을 생성하여 유사한 객체들을 델타 압축으로 더욱 효율적으로 저장합니다.

Git Flow는 main, develop, feature, release, hotfix 등 5가지 브랜치 타입을 사용하는 복잡한 전략으로, 정기적인 릴리즈 주기를 가진 전통적인 소프트웨어 개발에 적합합니다. 반면 GitHub Flow는 main 브랜치와 feature 브랜치만 사용하는 단순한 전략으로, main은 항상 배포 가능한 상태를 유지하며 feature 브랜치에서 작업 후 PR을 통해 병합합니다. GitHub Flow는 지속적 배포(Continuous Deployment)를 수행하는 웹 서비스나 SaaS 환경에 적합하며, 빠른 배포 주기와 간단한 워크플로우가 장점입니다.

Git은 모든 변경 이력을 저장하므로, 대용량 바이너리 파일을 커밋하면 저장소 크기가 급격히 증가합니다. 바이너리 파일은 델타 압축이 효과적이지 않아 수정할 때마다 거의 전체 파일 크기만큼 저장소가 커지며, clone이나 fetch 시 네트워크 전송 시간이 길어집니다. 해결 방법으로는 Git LFS(Large File Storage)를 사용하여 대용량 파일을 별도 서버에 저장하고 Git에는 포인터만 관리하거나, .gitignore에 추가하여 버전 관리 대상에서 제외하고 외부 CDN이나 스토리지를 활용할 수 있습니다.

Push가 rejected되는 이유는 로컬 브랜치가 원격 브랜치보다 뒤처져 있기 때문입니다. 다른 개발자가 먼저 push한 커밋이 원격에 존재하는데, 로컬에는 그 커밋이 없어서 fast-forward가 불가능한 상태입니다. git pull은 fetch 후 merge를 수행하여 병합 커밋을 생성하므로 히스토리가 복잡해집니다. 반면 git pull --rebase는 fetch 후 rebase를 수행하여 로컬 커밋을 원격 커밋 위에 재배치하므로 선형적인 히스토리를 유지할 수 있습니다. 팀 컨벤션에 따라 선택하되, 일반적으로 feature 브랜치에서는 rebase를 사용하여 깔끔한 히스토리를 유지하는 것이 권장됩니다.

.git 디렉토리는 Git 저장소의 모든 메타데이터와 객체 데이터베이스를 포함하는 핵심 디렉토리입니다. 여기에는 모든 커밋 히스토리, 브랜치 정보, 설정 파일, 객체(blob, tree, commit) 등이 저장되어 있습니다. 웹 서버에 .git 디렉토리를 포함하여 배포하면, 공격자가 .git 디렉토리에 접근하여 전체 소스코드, 커밋 히스토리, 삭제된 민감 정보(API 키, 비밀번호 등)를 복원할 수 있는 심각한 보안 위험이 발생합니다. 따라서 배포 시에는 빌드된 파일만 복사하거나, .git 디렉토리를 명시적으로 제외해야 합니다.