Git 미드레벨 기술면접

blob 객체는 파일의 내용을 저장하고, tree 객체는 디렉토리 구조와 파일명을 저장하며 blob이나 다른 tree를 가리킵니다. commit 객체는 특정 시점의 tree를 가리키며 메타데이터(작성자, 날짜, 메시지, 부모 커밋)를 포함합니다. 'git add'는 작업 디렉토리의 파일을 blob 객체로 변환하여 .git/objects에 저장하고 인덱스에 등록하며, 'git commit'은 인덱스의 상태를 기반으로 tree 객체를 생성한 후 이를 가리키는 commit 객체를 생성합니다. 모든 객체는 SHA-1 해시로 식별되며 .git/objects 디렉토리에 불변(immutable) 방식으로 저장됩니다.

먼저 git filter-branch나 BFG Repo-Cleaner를 사용하여 전체 히스토리에서 민감한 파일을 제거합니다. filter-branch의 경우 '--tree-filter' 또는 '--index-filter' 옵션으로 모든 커밋에서 해당 파일을 삭제하고, 작업 후 'git push --force'로 원격 저장소를 덮어씁니다. 모든 팀원에게 즉시 공지하여 로컬 작업을 백업하고, 'git fetch origin', 'git reset --hard origin/main'으로 강제 동기화하도록 안내합니다. 이미 노출된 패스워드는 즉시 변경해야 하며, 향후 재발 방지를 위해 pre-commit hook에 git-secrets나 truffleHog 같은 도구를 설정하고 .gitignore를 업데이트합니다.

shallow clone(--depth)은 최근 N개의 커밋만 가져와 히스토리를 제한하며 CI/CD에서 빌드만 필요한 경우 유용합니다. partial clone(--filter)은 Git 2.19+에서 지원하며 blob이나 tree 객체를 필요할 때만 다운로드하여 초기 클론 속도를 높이고, 전체 히스토리는 유지하면서 용량을 줄입니다. sparse checkout은 작업 디렉토리에 특정 경로의 파일만 체크아웃하여 모노레포에서 특정 서비스만 작업할 때 효과적입니다. shallow clone은 히스토리 접근이 제한되고, partial clone은 서버 지원이 필요하며, sparse checkout은 전체 객체는 다운로드하므로 각 상황에 맞게 선택해야 합니다.

git merge는 두 브랜치의 변경사항을 통합하는 새로운 merge commit을 생성하여 히스토리를 보존하며, 브랜치 간 관계를 명확히 보여줍니다. git rebase는 커밋들을 다른 베이스 위로 재배치하여 선형 히스토리를 만들고 깔끔한 로그를 유지하지만 커밋 해시가 변경됩니다. feature 브랜치에서는 로컬 작업 정리를 위해 rebase를 사용하고, main 브랜치로 통합 시에는 merge를 사용하는 것이 안전합니다. 이미 push된 공유 브랜치에서는 절대 rebase를 사용하지 않아야 하며, 필요시 팀 전체 합의 하에 force push를 진행해야 합니다.

main 브랜치는 항상 프로덕션 배포 가능 상태를 유지하고, develop 브랜치에서 차기 릴리스를 개발합니다. hotfix 발생 시 main에서 직접 'hotfix/issue-name' 브랜치를 생성하여 수정하고, 테스트 후 main으로 머지하며 즉시 버전 태그(v1.2.3)를 생성합니다. hotfix는 반드시 develop 브랜치에도 머지하여 차기 릴리스에 포함되도록 하며, cherry-pick으로 다른 지원 버전에 백포트합니다. release 브랜치는 QA를 위해 develop에서 분기하며, 이 시점 이후 새 기능은 다음 릴리스로 연기됩니다. 자동화된 CI/CD 파이프라인에서 태그 기반 배포를 트리거하고, 각 환경별 배포 상태를 추적합니다.