Git 신입 기술면접
새 면접Q. Git에서 .gitignore 파일의 역할과 사용 목적을 설명하고, 어떤 종류의 파일들을 .gitignore에 추가해야 하는지 예시와 함께 설명해주세요.
버전 관리를 하지 말아야 할 파일들을 생각해보세요.
.gitignore는 Git 저장소에서 버전 관리를 하지 않을 파일이나 디렉토리를 지정하는 파일입니다. 빌드 결과물(target/, build/), 의존성 폴더(node_modules/), 환경 설정 파일(.env), IDE 설정 파일(.idea/, .vscode/), 로그 파일(*.log) 등을 추가합니다. 이를 통해 저장소 크기를 줄이고, 민감한 정보 유출을 방지하며, 협업 시 불필요한 충돌을 예방할 수 있습니다. .gitignore는 저장소 루트에 위치하며, 패턴 매칭을 사용해 파일을 지정합니다.
- • .gitignore는 버전 관리에서 제외할 파일을 지정
- • 빌드 결과물, 의존성, 환경변수, IDE 설정 등을 제외
- • 저장소 크기 감소와 보안, 충돌 방지 목적
프로젝트 초기 세팅 시 .gitignore를 작성해 민감한 API 키나 DB 비밀번호가 포함된 환경 변수 파일이 원격 저장소에 올라가는 것을 방지합니다.
이미 commit된 파일을 .gitignore에 추가하면 어떻게 되나요? 그리고 이미 추적 중인 파일을 제거하려면 어떻게 해야 하나요?
Q. 팀 프로젝트나 협업 경험에서 Git을 사용하며 겪었던 어려움이나 실수, 그리고 그것을 어떻게 해결했는지 구체적으로 설명해주세요.
실제 경험을 STAR 방식(상황-과제-행동-결과)으로 구성해보세요.
이 질문은 경험 기반 질문으로, 상황(Situation)에서는 어떤 프로젝트에서 어떤 문제가 발생했는지, 과제(Task)에서는 본인이 해결해야 할 것이 무엇이었는지, 행동(Action)에서는 구체적으로 어떤 조치를 취했는지, 결과(Result)에서는 어떤 결과와 배움을 얻었는지 순서대로 답변하면 좋습니다. 예를 들어 merge conflict 해결 경험, 잘못된 commit 되돌리기, branch 전략 수립 등의 경험을 구체적으로 설명하세요. 기술적 해결 방법뿐만 아니라 팀원과의 소통 과정도 포함하면 더 좋습니다.
- • STAR 방식으로 구조화된 답변
- • 구체적인 Git 관련 문제 상황 제시
- • 기술적 해결책과 협업 과정 모두 언급
실무에서는 여러 개발자가 동시에 작업하므로 Git 사용 중 발생하는 문제를 신속하게 해결하고 팀원과 소통하는 능력이 중요합니다.
그 경험을 통해 배운 점을 현재 프로젝트나 업무에 어떻게 적용하고 있나요?
Q. Git에서 stash의 개념과 사용 목적을 설명하고, 어떤 상황에서 stash를 사용하면 유용한지 구체적인 시나리오와 함께 설명해주세요.
작업 중인 변경사항을 임시로 저장해야 하는 상황을 생각해보세요.
stash는 현재 작업 중인 변경사항을 임시로 저장하고 Working Directory를 깨끗한 상태로 되돌리는 기능입니다. git stash 명령어로 저장하고, git stash pop으로 다시 불러올 수 있습니다. 예를 들어 feature 브랜치에서 작업 중 긴급한 버그 수정을 위해 main 브랜치로 전환해야 할 때, 현재 작업을 commit하기에는 불완전한 상태라면 stash로 저장합니다. 버그 수정 후 다시 feature 브랜치로 돌아와 stash를 적용해 작업을 이어갈 수 있습니다. 여러 개의 stash를 관리할 수 있으며, git stash list로 목록을 확인할 수 있습니다.
- • stash는 작업 중인 변경사항을 임시 저장
- • 브랜치 전환 시 불완전한 작업을 보존
- • git stash와 git stash pop 명령어 사용
기능 개발 중 갑자기 프로덕션 버그 수정 요청이 들어왔을 때, 현재 작업을 stash로 저장하고 hotfix 브랜치로 전환해 긴급 대응합니다.
stash를 사용할 때 Staged 상태의 파일과 Unstaged 상태의 파일이 어떻게 처리되나요?
Q. Git Flow와 GitHub Flow의 차이점을 설명하고, 각각 어떤 프로젝트나 팀 환경에 적합한지 비교해주세요.
브랜치 전략의 복잡도와 배포 주기를 고려해보세요.
Git Flow는 master, develop, feature, release, hotfix 등 여러 브랜치를 사용하는 복잡한 전략으로, 정기적인 릴리즈 주기를 가진 대규모 프로젝트에 적합합니다. GitHub Flow는 main 브랜치와 feature 브랜치만 사용하는 단순한 전략으로, 지속적 배포(CD)를 하는 웹 서비스에 적합합니다. Git Flow는 릴리즈 준비와 버전 관리가 명확하지만 복잡하고, GitHub Flow는 단순하고 빠르지만 여러 버전을 동시에 관리하기 어렵습니다. 스타트업이나 애자일 환경에서는 GitHub Flow가, 엔터프라이즈 소프트웨어는 Git Flow가 선호됩니다.
- • Git Flow는 복잡한 브랜치 전략, GitHub Flow는 단순한 전략
- • 배포 주기와 프로젝트 규모에 따라 선택
- • 각각의 장단점과 적용 환경 이해
팀의 배포 방식과 프로젝트 특성에 맞는 브랜치 전략을 선택해야 협업 효율성과 코드 품질을 모두 확보할 수 있습니다.
현재 진행 중인 프로젝트나 학습 프로젝트에서는 어떤 브랜치 전략을 사용하고 있나요? 그 이유는 무엇인가요?
Q. 팀원과 같은 파일의 같은 부분을 동시에 수정해 push를 시도했는데 'rejected' 오류가 발생했습니다. 이 상황이 발생한 원인과 해결 방법을 단계별로 설명해주세요.
원격 저장소의 변경사항을 먼저 가져와야 합니다.
이 오류는 원격 저장소에 로컬에 없는 새로운 commit이 존재할 때 발생합니다. 먼저 git pull 또는 git fetch로 원격 저장소의 최신 변경사항을 가져와야 합니다. git pull을 실행하면 자동으로 merge가 시도되며, 같은 부분을 수정했다면 conflict가 발생합니다. conflict 발생 시 해당 파일을 열어 충돌 마커를 확인하고 수동으로 해결한 후 git add와 git commit으로 병합을 완료합니다. 최종적으로 git push로 원격 저장소에 반영합니다. 이를 방지하려면 작업 시작 전 항상 pull을 받아 최신 상태를 유지하고, 작은 단위로 자주 commit하고 push하는 습관이 중요합니다.
- • 원격 저장소에 새로운 commit이 있어 발생
- • git pull로 최신 변경사항 가져오기
- • conflict 해결 후 add, commit, push 순서로 진행
여러 개발자가 동시에 작업하는 환경에서 자주 발생하는 상황으로, 충돌을 최소화하기 위한 커뮤니케이션과 작업 단위 조정이 필요합니다.
git pull 대신 git fetch와 git merge를 따로 사용하는 것과 어떤 차이가 있나요?
Q. Git에서 HEAD가 무엇을 의미하는지 설명하고, detached HEAD 상태는 언제 발생하며 어떤 주의사항이 있는지 설명해주세요.
HEAD는 현재 작업 중인 위치를 가리키는 포인터입니다.
HEAD는 현재 체크아웃된 commit을 가리키는 포인터로, 일반적으로 브랜치의 최신 commit을 가리킵니다. detached HEAD 상태는 특정 commit을 직접 체크아웃했을 때 발생하며, 이때 HEAD가 브랜치가 아닌 특정 commit을 직접 가리킵니다. 이 상태에서 새로운 commit을 만들면 어떤 브랜치에도 속하지 않아 나중에 잃어버릴 수 있습니다. detached HEAD 상태에서 작업하려면 git checkout -b 명령어로 새 브랜치를 만들어야 합니다. 일반적으로 과거 코드를 확인할 때만 사용하고, 수정이 필요하면 브랜치를 생성합니다.
- • HEAD는 현재 체크아웃된 commit을 가리키는 포인터
- • detached HEAD는 브랜치가 아닌 특정 commit을 가리키는 상태
- • 이 상태에서 commit하면 변경사항을 잃을 수 있음
특정 버전의 코드를 확인하거나 과거 시점으로 돌아가 디버깅할 때 detached HEAD 상태를 이해하고 안전하게 사용해야 합니다.
git log 명령어에서 HEAD, origin/main 같은 표기는 각각 무엇을 의미하나요?
Q. Git에서 rebase의 개념과 merge와의 차이점을 설명하고, rebase를 사용할 때의 장단점과 주의사항을 설명해주세요.
commit 히스토리를 어떻게 관리하는지 차이를 생각해보세요.
rebase는 한 브랜치의 변경사항을 다른 브랜치 위에 재배치하는 작업으로, commit 히스토리를 선형으로 만듭니다. merge는 두 브랜치의 변경사항을 합치는 새로운 merge commit을 생성하지만, rebase는 commit들을 재작성해 깔끔한 히스토리를 유지합니다. rebase의 장점은 히스토리가 직관적이고 깔끔하다는 것이고, 단점은 commit hash가 변경되어 이미 push한 commit을 rebase하면 협업자에게 문제가 발생할 수 있다는 것입니다. 따라서 로컬에서만 작업한 commit에만 rebase를 사용하고, 이미 공유한 브랜치에는 merge를 사용하는 것이 안전합니다.
- • rebase는 commit을 재배치해 선형 히스토리 생성
- • merge는 merge commit을 만들어 히스토리 보존
- • 공유된 브랜치에는 rebase 사용 금지
feature 브랜치를 main에 병합하기 전 rebase로 히스토리를 정리하면 코드 리뷰와 추후 디버깅이 용이해집니다.
interactive rebase(git rebase -i)는 어떤 경우에 사용하나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!