Git 주니어 CS 기초 면접
새 면접Q. Git이 커밋을 식별하는 데 사용하는 SHA-1 해시의 특징과 충돌 가능성에 대해 설명하고, 짧은 해시(short hash)를 사용할 수 있는 이유를 말씀해주세요.
Git은 각 커밋을 40자리 SHA-1 해시로 식별하며, 이는 커밋의 내용, 메타데이터, 부모 커밋 정보를 기반으로 생성됩니다. 이론적으로 충돌 가능성이 존재하지만 실제로는 거의 발생하지 않으며, 저장소 내에서 유일성이 보장됩니다. Git은 앞 7자리만으로도 저장소 내에서 커밋을 고유하게 식별할 수 있다면 짧은 해시 사용을 허용하며, 필요시 자동으로 더 긴 해시를 사용합니다. 이를 통해 사용자는 git log --oneline이나 git show 명령어에서 간편하게 커밋을 참조할 수 있습니다.
- • SHA-1 해시는 40자리 16진수로 커밋을 고유하게 식별
- • 충돌 가능성은 이론적으로 존재하나 실무에서는 거의 발생하지 않음
- • 저장소 내에서 고유하다면 앞 7자리 이상의 짧은 해시로 참조 가능
- • Git이 자동으로 충분한 길이의 해시를 선택하여 모호성 방지
Git이 SHA-256으로 전환을 고려하는 이유와 이로 인한 영향에 대해 설명해주세요.
Q. git merge 시 사용할 수 있는 Fast-forward 병합과 3-way 병합의 차이점을 설명하고, --no-ff 옵션을 사용하는 이유를 말씀해주세요.
Fast-forward 병합은 브랜치가 분기된 후 base 브랜치에 새 커밋이 없을 때, 단순히 포인터만 이동시켜 병합하는 방식으로 병합 커밋이 생성되지 않습니다. 3-way 병합은 두 브랜치와 공통 조상을 비교하여 새로운 병합 커밋을 생성하며, 양쪽 브랜치에 모두 변경사항이 있을 때 사용됩니다. --no-ff 옵션은 Fast-forward가 가능한 상황에서도 강제로 병합 커밋을 생성하여, 브랜치의 존재 이력을 명확히 남기고 기능 단위로 커밋을 그룹화할 수 있게 합니다. 이는 특히 feature 브랜치 작업 이력을 보존하고 싶을 때 유용합니다.
- • Fast-forward는 포인터만 이동, 병합 커밋 없음
- • 3-way 병합은 공통 조상과 두 브랜치를 비교하여 병합 커밋 생성
- • --no-ff는 Fast-forward 가능해도 병합 커밋을 생성
- • 브랜치 이력 보존과 기능 단위 그룹화에 유용
git merge --squash 옵션의 동작 방식과 일반 병합과의 차이점을 설명해주세요.
Q. Git의 가비지 컬렉션(Garbage Collection)이 무엇인지 설명하고, git gc 명령어가 수행하는 작업과 언제 실행되는지 말씀해주세요.
Git 가비지 컬렉션은 더 이상 참조되지 않는 객체들을 정리하고 저장소를 최적화하는 프로세스입니다. git gc 명령어는 loose 객체들을 pack 파일로 압축하고, 도달할 수 없는 객체를 삭제하며, 중복 데이터를 제거하여 저장 공간을 절약합니다. Git은 일반적으로 자동으로 가비지 컬렉션을 수행하지만, 수동으로 git gc --aggressive를 실행하여 더 강력한 최적화를 할 수 있습니다. reflog에 의해 참조되는 객체는 기본적으로 90일간 보존되며, 완전히 도달 불가능한 객체는 2주 후 삭제됩니다.
- • 더 이상 참조되지 않는 객체 정리 및 저장소 최적화
- • loose 객체를 pack 파일로 압축하여 공간 절약
- • Git이 자동으로 수행하지만 수동 실행도 가능
- • reflog 참조 객체는 90일, 도달 불가능 객체는 2주 후 삭제
pack 파일과 loose 객체의 차이점과 Git이 pack 파일을 사용하는 이유를 설명해주세요.
Q. Git에서 서명된 커밋(Signed Commit)과 서명된 태그(Signed Tag)의 목적을 설명하고, GPG 키를 사용한 서명 과정을 간단히 설명해주세요.
서명된 커밋과 태그는 커밋 작성자의 신원을 암호학적으로 검증하고 코드의 무결성을 보장하기 위해 사용됩니다. Git 설정의 user.name과 user.email은 누구나 변경 가능하므로, GPG 서명을 통해 실제 작성자임을 증명할 수 있습니다. GPG 키 쌍을 생성한 후 공개키를 GitHub 등에 등록하고, git commit -S 또는 git tag -s 명령어로 서명하면 개인키로 암호화된 서명이 추가됩니다. 다른 사람들은 공개키로 서명을 검증하여 커밋이 실제 작성자로부터 온 것이며 변조되지 않았음을 확인할 수 있습니다.
- • 작성자 신원 검증과 코드 무결성 보장이 목적
- • GPG 키 쌍을 사용한 암호학적 서명
- • git commit -S와 git tag -s로 서명 생성
- • 공개키를 통해 누구나 서명 검증 가능
오픈소스 프로젝트에서 서명된 커밋을 요구하는 이유와 실무에서의 활용 사례를 설명해주세요.
Q. GitHub의 Protected Branch 기능의 목적과 설정할 수 있는 주요 규칙들을 설명하고, 이것이 팀 협업에서 중요한 이유를 말씀해주세요.
Protected Branch는 중요한 브랜치(main, develop 등)를 직접 수정하지 못하도록 보호하여 코드 품질과 안정성을 유지하는 기능입니다. 주요 규칙으로는 직접 push 금지, Pull Request를 통한 병합 강제, 최소 리뷰어 수 지정, CI 통과 필수, 강제 push 방지 등이 있습니다. 이를 통해 모든 코드 변경이 리뷰를 거치게 되고, 테스트를 통과한 코드만 병합되며, 실수로 인한 히스토리 손실을 방지할 수 있습니다. 팀 협업에서 코드 품질 관리와 배포 안정성을 보장하는 핵심 메커니즘입니다.
- • 중요 브랜치를 직접 수정 불가능하게 보호
- • PR 필수, 리뷰어 승인, CI 통과 등의 규칙 설정 가능
- • 강제 push 방지로 히스토리 보호
- • 코드 품질 관리와 배포 안정성 보장
CODEOWNERS 파일의 역할과 Protected Branch와 함께 사용할 때의 시너지 효과를 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!