Git 미드레벨 기술면접

Git의 index는 .git/index 파일에 바이너리 형태로 저장되며, 각 파일의 경로, 모드, SHA-1, 타임스탬프 정보를 포함합니다. 부분적 커밋 시 index에 추가된 파일만 커밋 객체에 포함되어 작업 디렉토리와 다른 스냅샷을 만들 수 있습니다. 충돌 발생 시 stage 0은 정상 파일, stage 1은 공통 조상(base), stage 2는 현재 브랜치(ours), stage 3은 병합 대상(theirs)을 저장하여 3-way merge를 지원합니다. git ls-files -s 명령으로 각 단계의 파일을 확인할 수 있으며, 충돌 해결 후 git add로 stage 0으로 통합됩니다.

Delta compression은 git gc 실행 시 유사한 객체들을 찾아 차이(delta)만 저장하는 방식으로, packfile 크기를 크게 줄입니다. Base 객체와 delta chain을 구성하며, 너무 긴 chain은 압축 해제 성능을 저하시킵니다. Bitmap index는 각 커밋에서 도달 가능한 모든 객체를 비트맵으로 미리 계산하여 저장하므로, clone이나 fetch 시 전송할 객체를 빠르게 계산할 수 있습니다. pack.writeBitmaps 옵션으로 활성화되며, 특히 대규모 저장소에서 객체 그래프 탐색 시간을 수십 배 단축시킵니다. 하지만 bitmap 생성 자체에 시간이 걸리고 추가 디스크 공간을 사용하는 트레이드오프가 있습니다.

Trunk-based Development 방식으로 모든 개발자가 main 브랜치에 직접 또는 1-2일 내 병합되는 짧은 feature 브랜치로 작업합니다. 미완성 기능은 Feature Flag로 감싸서 프로덕션에서 비활성화하고, 테스트 환경에서만 활성화하여 검증합니다. CI/CD 파이프라인은 main 브랜치 커밋마다 자동 배포하되, Feature Flag 설정은 별도 관리 시스템에서 런타임에 제어합니다. 이를 통해 긴 수명의 feature 브랜치로 인한 통합 지옥을 방지하고, 작은 단위의 잦은 통합으로 충돌을 최소화하며, 배포와 기능 출시를 분리할 수 있습니다. 브랜치 보호 규칙과 자동화된 테스트로 main 브랜치 품질을 보장합니다.

먼저 각 팀원은 현재 작업을 git stash 또는 임시 브랜치로 백업합니다. git fetch origin으로 원격의 rebase된 히스토리를 가져온 후, git rebase --onto origin/branch old-branch-tip current-branch 명령으로 자신의 커밋들을 새로운 base 위로 재배치합니다. 또는 git reset --hard origin/branch 후 백업한 변경사항을 git cherry-pick이나 수동 적용합니다. 예방책으로는 공유 브랜치에서는 rebase 금지 규칙을 설정하고, force push는 --force-with-lease 옵션으로 제한하며, rebase가 필요한 경우 팀 공지 후 모든 작업 중단을 확인합니다. 또한 protected branch 설정으로 force push를 원천 차단하거나, PR 기반 워크플로우로 개인 브랜치에서만 rebase를 허용합니다.

기존 커밋 수정 방식은 git commit --amend나 git rebase -i로 리뷰 피드백을 원래 커밋에 통합하여 깔끔한 히스토리를 유지하지만, force push가 필요하고 리뷰 변경 이력 추적이 어렵습니다. 새 커밋 추가 방식은 'Address review comments' 같은 커밋으로 피드백을 반영하여 리뷰 과정을 투명하게 기록하고 force push가 불필요하지만, 히스토리가 지저분해집니다. 일반적으로 리뷰 중에는 새 커밋으로 피드백을 반영하여 변경사항 추적을 쉽게 하고, 최종 머지 전에 squash merge나 rebase로 정리하는 하이브리드 방식을 권장합니다. GitHub의 'Squash and merge' 기능이나 GitLab의 'Squash commits' 옵션을 활용하면 자동화할 수 있습니다.