Git 미드레벨 기술면접
새 면접Q. git worktree는 어떤 문제를 해결하기 위해 만들어졌으며, 내부적으로 어떻게 동작하나요? 여러 브랜치를 동시에 작업해야 하는 상황에서 worktree를 활용하는 것이 여러 개의 clone을 사용하는 것과 비교해 어떤 장점이 있는지 설명해주세요.
git worktree는 하나의 저장소에서 여러 브랜치를 동시에 체크아웃하여 작업할 수 있게 해주는 기능입니다. 내부적으로 .git/worktrees 디렉토리에 각 worktree의 메타데이터를 저장하고, 실제 객체 데이터베이스는 원본 저장소와 공유합니다. 여러 clone을 사용하는 것과 달리 디스크 공간을 절약하고, 모든 worktree가 동일한 객체 저장소를 참조하므로 fetch/pull을 한 번만 수행하면 모든 작업 공간에 반영됩니다. 또한 브랜치 간 전환이 필요 없어 긴급 hotfix 작업이나 코드 리뷰 중 다른 브랜치 확인이 필요할 때 유용합니다.
- • 하나의 저장소에서 여러 브랜치를 동시에 체크아웃 가능
- • 객체 데이터베이스를 공유하여 디스크 공간 절약
- • .git/worktrees에 메타데이터 저장
- • fetch/pull이 모든 worktree에 자동 반영
- • 브랜치 전환 없이 동시 작업 가능
worktree를 삭제하지 않고 방치했을 때 발생할 수 있는 문제와 git worktree prune의 역할은 무엇인가요?
Q. .gitattributes 파일의 역할과 활용 사례를 설명해주세요. 특히 merge 드라이버, diff 드라이버, 그리고 filter를 정의하여 특정 파일 타입에 대한 Git의 동작을 커스터마이징하는 방법과 실무에서의 활용 예시를 제시해주세요.
.gitattributes는 파일 경로 패턴별로 Git의 동작을 제어하는 설정 파일입니다. merge 드라이버를 통해 특정 파일(예: package-lock.json)의 충돌 해결 전략을 커스터마이징할 수 있고, diff 드라이버로 바이너리 파일이나 특수 포맷(예: PDF, Excel)의 차이를 텍스트로 변환하여 비교할 수 있습니다. filter를 사용하면 체크아웃/커밋 시 파일 내용을 자동 변환할 수 있어, 개발 환경별 설정값 치환이나 민감 정보 자동 제거 등에 활용됩니다. 실무에서는 CRLF 줄바꿈 통일, 바이너리 파일 식별, 언어별 diff hunk 헤더 커스터마이징 등에 사용됩니다.
- • 파일 경로 패턴별로 Git 동작 제어
- • merge 드라이버로 충돌 해결 전략 커스터마이징
- • diff 드라이버로 특수 파일 형식의 비교 가능
- • filter로 체크아웃/커밋 시 자동 변환
- • 줄바꿈 통일, 바이너리 처리 등 실무 활용
Git LFS(Large File Storage)는 내부적으로 .gitattributes의 어떤 기능을 활용하여 구현되었나요?
Q. git bisect를 사용한 자동화된 버그 추적 시스템을 구축하려고 합니다. 수천 개의 커밋 중에서 버그가 발생한 정확한 커밋을 찾아야 할 때, git bisect run을 활용한 자동화 전략과 테스트 스크립트 작성 시 고려사항을 설명해주세요. 특히 빌드 실패, 간헐적 버그, 테스트 환경 설정 등의 예외 상황을 어떻게 처리하시겠습니까?
git bisect run은 이진 탐색으로 버그 발생 커밋을 자동으로 찾아주는 명령입니다. 테스트 스크립트는 성공 시 0, 실패 시 1-127(125 제외), 스킵 시 125를 반환해야 합니다. 빌드 실패나 테스트 환경 문제가 있는 커밋은 125를 반환하여 스킵하고, 간헐적 버그는 여러 번 실행하여 재현율을 높이는 로직을 추가합니다. 각 커밋마다 의존성 설치나 데이터베이스 마이그레이션이 필요한 경우 스크립트에 포함시키고, 타임아웃을 설정하여 무한 대기를 방지합니다. 또한 bisect 시작 전 git bisect log로 진행 상황을 저장하여 중단 시 재개할 수 있도록 합니다.
- • 이진 탐색으로 O(log n) 시간에 버그 커밋 발견
- • 반환 코드로 good(0), bad(1-127), skip(125) 구분
- • 빌드 실패나 환경 문제는 125로 스킹
- • 간헐적 버그는 재시도 로직으로 재현율 향상
- • 의존성 설치, 마이그레이션, 타임아웃 처리 필요
git bisect 과정에서 merge 커밋이 포함되어 있을 때 발생할 수 있는 문제와, --first-parent 옵션의 활용 방법을 설명해주세요.
Q. 네트워크가 차단된 환경(air-gapped environment)에서 Git 저장소를 전송해야 합니다. git bundle의 동작 원리를 설명하고, 증분 번들(incremental bundle)을 생성하여 효율적으로 업데이트를 전달하는 방법, 그리고 번들의 무결성을 검증하는 프로세스를 제시해주세요.
git bundle은 Git 저장소의 일부 또는 전체를 하나의 파일로 패키징하는 기능으로, 네트워크 없이 저장소를 전송할 수 있습니다. 내부적으로 packfile 형식과 유사하며, git bundle create로 특정 브랜치나 커밋 범위를 지정하여 생성합니다. 증분 번들은 이전 번들의 마지막 커밋을 시작점으로 지정하여(예: git bundle create new.bundle old-commit..HEAD) 변경사항만 포함시킵니다. git bundle verify 명령으로 번들 파일의 무결성과 필요한 선행 커밋 존재 여부를 확인하고, git bundle list-heads로 포함된 참조를 확인할 수 있습니다. 수신 측에서는 git clone이나 git fetch로 번들을 일반 저장소처럼 사용할 수 있습니다.
- • 저장소를 단일 파일로 패키징하여 오프라인 전송
- • packfile 형식 기반으로 효율적인 저장
- • 커밋 범위 지정으로 증분 번들 생성 가능
- • git bundle verify로 무결성 검증
- • clone/fetch로 번들을 일반 저장소처럼 사용
git bundle을 사용하여 특정 서브디렉토리만 포함하는 부분 저장소를 만들 수 있나요? 그렇지 않다면 어떤 대안이 있을까요?
Q. git replace 명령의 동작 원리와 활용 사례를 설명해주세요. 특히 저장소 히스토리를 실제로 변경하지 않으면서 특정 커밋을 다른 커밋으로 대체하는 메커니즘과, 레거시 저장소를 분리하거나 히스토리를 정리할 때 어떻게 활용할 수 있는지 설명해주세요.
git replace는 특정 Git 객체를 다른 객체로 대체하는 참조를 생성하여, 실제 히스토리를 변경하지 않고도 Git이 읽을 때는 대체된 객체로 보이게 합니다. .git/refs/replace/ 디렉토리에 매핑 정보를 저장하며, 로컬에서만 적용되고 기본적으로 push되지 않습니다. 레거시 히스토리를 별도 저장소로 분리하고 현재 저장소는 최근 히스토리만 유지하면서, replace로 연결하면 로컬에서는 전체 히스토리를 볼 수 있습니다. 또한 잘못된 커밋 메시지나 작성자 정보를 수정한 새 커밋으로 대체하여, filter-branch 없이도 히스토리를 정리할 수 있습니다. git push --force 없이도 안전하게 히스토리 개선이 가능합니다.
- • 실제 객체 변경 없이 대체 참조만 생성
- • .git/refs/replace/에 매핑 정보 저장
- • 로컬에만 적용되며 기본적으로 push 안 됨
- • 레거시 히스토리 분리 후 논리적 연결에 활용
- • filter-branch 없이 안전한 히스토리 정리 가능
git replace --graft 옵션은 어떤 용도로 사용되며, 일반적인 replace와 어떻게 다른가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!