Git 면접 질문 TOP 10: 기술 면접 전 반드시 알아야 할 개념 총정리

개발자 기술 면접에서 Git 관련 질문은 사실상 단골 메뉴입니다. Git 면접 질문은 단순한 명령어 암기를 묻는 것이 아니라, 팀 협업 환경에서 버전 관리를 얼마나 깊이 이해하고 있는지를 검증하는 수단입니다. merge와 rebase의 차이를 막연히 알고 있는 것과 “왜 이 상황에서 이 방법을 선택했는지”를 논리적으로 설명하는 것은 완전히 다릅니다. 이 글에서는 현업 면접관이 실제로 자주 묻는 핵심 질문 10개를 예상 답변 구조와 함께 정리합니다.

Git이란 무엇인가: 분산 버전 관리 시스템의 개념
핵심 질문 ①~③: 기초 개념 (HEAD, staging area, branch)
핵심 질문 ④~⑥: 병합 전략 (merge, rebase, cherry-pick)
핵심 질문 ⑦~⑨: 실무 명령어 (reset, revert, stash)
핵심 질문 ⑩: 브랜치 전략 (Git Flow vs GitHub Flow)
면접관이 기대하는 ‘좋은 답변’의 구조
Git 면접 대비 체크리스트 및 추천 학습 순서

1. Git이란 무엇인가: 분산 버전 관리 시스템의 개념

본론에 들어가기 전에, Git의 근본적인 특성을 짚고 넘어가야 합니다. 면접에서 “Git을 한 문장으로 설명해보세요”라는 질문이 의외로 자주 나오기 때문입니다.

Git은 분산 버전 관리 시스템(Distributed Version Control System, DVCS) 입니다. SVN과 같은 중앙집중식 버전 관리 시스템(CVCS)과의 차이가 핵심입니다.

[중앙집중식 vs 분산 버전 관리 비교]

항목              CVCS (SVN 등)            DVCS (Git)
────────────────────────────────────────────────────────────
저장소 위치       중앙 서버 1개            로컬 + 원격 모두 완전한 저장소
오프라인 작업     불가 (서버 필요)          가능 (로컬 커밋 가능)
서버 장애 시      전체 작업 중단            로컬 작업 계속 가능
속도              네트워크 의존              로컬 처리로 빠름
브랜치 비용       비교적 무거움             매우 가볍고 빠름

Git은 각 개발자의 로컬 환경에 전체 히스토리를 포함한 완전한 저장소(repository) 가 존재합니다. 마치 도서관 원본 책을 복사해서 각자 가지고 있는 것과 같습니다. 이 덕분에 네트워크 없이도 커밋, 브랜치, 로그 조회가 가능합니다.

2. 핵심 질문 ①~③: 기초 개념

Q1. Git의 세 가지 영역(Working Directory, Staging Area, Repository)을 설명하세요.

이 질문은 Git 내부 동작 방식의 출발점입니다. 많은 면접자가 git add와 git commit을 쓸 줄 알면서도 왜 두 단계를 거치는지 설명하지 못합니다.

모범 답변 구조:

Git에서 파일은 세 가지 영역을 거쳐 이동합니다.

[Git의 세 가지 영역과 명령어 흐름]

┌─────────────────┐   git add    ┌──────────────┐  git commit  ┌──────────────┐
│ Working         │ ──────────► │ Staging Area │ ──────────► │ Repository   │
│ Directory       │             │ (Index)      │             │ (.git 폴더)  │
│ (작업 디렉토리)  │ ◄────────── │              │ ◄────────── │              │
└─────────────────┘  git restore └──────────────┘ git restore  └──────────────┘
                                                  --staged

Working Directory: 실제로 파일을 편집하는 공간입니다. 아직 Git이 추적하지 않은 변경 사항이 여기에 있습니다.
Staging Area(Index): git add 명령으로 커밋에 포함할 변경 사항을 선별해 올려두는 임시 공간입니다. 이 단계 덕분에 하나의 작업에서 논리적으로 관련 있는 파일만 골라 커밋할 수 있습니다.
Repository(.git 폴더): git commit 명령으로 스냅샷이 영구적으로 기록되는 로컬 저장소입니다.

면접 포인트: Staging Area가 존재하는 이유를 “논리적으로 연관된 변경 사항만 묶어 커밋할 수 있는 유연성을 제공하기 때문”이라고 설명하면 깊이 있는 이해를 보여줄 수 있습니다.

Q2. HEAD란 무엇이며, detached HEAD 상태는 무엇인가요?

모범 답변 구조:

HEAD는 현재 작업 중인 커밋을 가리키는 포인터입니다. 보통은 현재 체크아웃된 브랜치의 최신 커밋을 간접적으로 가리킵니다.

[HEAD의 동작 방식]

일반 상태:
HEAD → main 브랜치 → 최신 커밋 (C3)

커밋 히스토리:
C1 ──► C2 ──► C3
                ▲
               main
                ▲
               HEAD

Detached HEAD 상태는 HEAD가 브랜치가 아닌 특정 커밋을 직접 가리키는 상태입니다. git checkout <커밋 해시> 명령을 실행하면 발생합니다.

bash

# detached HEAD 상태 진입
git checkout a1b2c3d

# 이 상태에서 커밋을 하면...
# 브랜치에 연결되지 않은 커밋이 생성됨
# → 다른 브랜치로 이동하면 해당 커밋은 GC(Garbage Collection)로 사라질 수 있음

detached HEAD 상태에서 작업 내용을 보존하려면 새 브랜치를 만들어야 합니다.

bash

# detached HEAD 상태에서 브랜치 생성으로 작업 보존
git checkout -b new-branch-name

Q3. `git fetch`와 `git pull`의 차이를 설명하세요.

면접에서 “둘 다 원격 저장소에서 가져오는 거 아닌가요?”라고 반문하는 면접자가 많습니다. 차이를 명확히 설명할수록 좋은 인상을 줍니다.

모범 답변 구조:

[fetch vs pull 동작 비교]

git fetch:
원격 저장소 ──► 로컬 원격 추적 브랜치(origin/main) 업데이트
                로컬 작업 브랜치는 그대로 유지
                → 확인 후 수동으로 merge/rebase 결정 가능

git pull:
원격 저장소 ──► fetch + merge(또는 rebase)를 한 번에 실행
                로컬 작업 브랜치에 자동으로 병합
                → 편리하지만 예상치 못한 충돌 발생 가능

명령어	동작	적합한 상황
`git fetch`	원격 변경 사항 가져오기만 함	변경 내용을 먼저 확인 후 병합하고 싶을 때
`git pull`	fetch + merge 자동 실행	빠르게 최신 상태로 동기화할 때

실무 팁으로 추가할 내용: 협업 프로젝트에서는 git fetch 후 git log origin/main..main 으로 변경 내역을 확인한 뒤 병합하는 습관이 안전합니다.

3. 핵심 질문 ④~⑥: 병합 전략

Q4. `git merge`와 `git rebase`의 차이를 설명하고, 각각 언제 사용하나요?

이 질문은 Git 면접 질문 중 가장 빈출입니다. 단순한 정의 나열보다 트레이드오프와 사용 시점을 함께 설명해야 합니다.

모범 답변 구조:

[merge vs rebase 히스토리 비교]

초기 상태:
main:    A ──► B ──► C
feature:          └──► D ──► E

── git merge 후 ──────────────────────────────
main: A──►B──►C──────────────────►M (머지 커밋)
                  └──►D──►E──►┘
결과: 병합 커밋(M)이 생성되어 브랜치 히스토리가 그대로 보존

── git rebase 후 ─────────────────────────────
main: A──►B──►C──►D'──►E'
결과: feature 커밋이 main 끝에 재배치, 선형 히스토리 생성

항목	merge	rebase
히스토리	브랜치 분기 그대로 보존	선형으로 정리됨
병합 커밋	생성됨	생성되지 않음
충돌 처리	한 번에 처리	커밋마다 처리 필요
협업 안전성	안전	공유 브랜치에 사용 금지
적합한 상황	공개 브랜치, 팀 협업	로컬 피처 브랜치 정리

면접 포인트: “rebase는 커밋 해시를 새로 만들기 때문에, 이미 원격에 push된 공유 브랜치에 사용하면 다른 팀원의 히스토리가 충돌합니다. 이것이 ‘The Golden Rule of Rebasing’ — 공유된 브랜치에는 rebase하지 않는 원칙입니다”라고 설명하면 깊이가 느껴집니다.

Q5. Fast-forward merge란 무엇이고, 언제 발생하나요?

모범 답변 구조:

Fast-forward merge는 병합 대상 브랜치가 현재 브랜치의 직접적인 후손 커밋일 때 발생합니다. 별도의 병합 커밋 없이 브랜치 포인터만 앞으로 이동시킵니다.

[Fast-forward merge 동작]

병합 전:
main: A ──► B
              └──► C ──► D  (feature)

Fast-forward merge 후:
main: A ──► B ──► C ──► D
                         ▲
                     main (포인터만 이동)

Fast-forward가 불가능한 경우(main에 추가 커밋이 있을 때)에는 3-way merge가 이루어지며 병합 커밋이 생성됩니다. --no-ff 옵션으로 fast-forward 가능한 경우에도 강제로 머지 커밋을 만들 수 있습니다.

bash

# fast-forward merge 방지 → 항상 머지 커밋 생성
git merge --no-ff feature-branch
# → 브랜치가 존재했음을 히스토리에 명시적으로 남길 때 사용

Q6. `git cherry-pick`은 무엇이며, 어떤 상황에서 사용하나요?

모범 답변 구조:

cherry-pick은 특정 브랜치의 원하는 커밋 하나(또는 여러 개)만 골라서 현재 브랜치에 적용하는 명령입니다. 브랜치 전체를 병합하는 merge와 달리, 필요한 커밋만 선택적으로 가져옵니다.

bash

# feature 브랜치의 특정 커밋만 main에 적용
git checkout main
git cherry-pick a1b2c3d

# 여러 커밋 적용
git cherry-pick a1b2c3d e4f5g6h

# 범위 지정 (a 이후부터 b까지)
git cherry-pick a1b2c3d..e4f5g6h

실제 사용 사례:

긴급 버그 수정 커밋을 release 브랜치에 적용해야 할 때
develop 브랜치의 특정 기능만 hotfix 브랜치에 백포팅(backporting)할 때
실수로 다른 브랜치에 커밋한 내용을 올바른 브랜치로 이식할 때

주의점: cherry-pick을 남용하면 동일한 내용의 커밋이 여러 브랜치에 중복 생성되어 히스토리가 복잡해집니다. 나중에 전체 브랜치를 merge할 때 충돌이 생길 수도 있으므로 꼭 필요한 경우에만 사용합니다.

4. 핵심 질문 ⑦~⑨: 실무 명령어

Q7. `git reset`과 `git revert`의 차이를 설명하세요.

협업 환경에서 커밋을 되돌리는 방법에 대한 질문입니다. 잘못 사용하면 팀원의 작업을 망칠 수 있어 실무 감각을 평가하기 좋은 질문입니다.

모범 답변 구조:

[reset vs revert 비교]

git reset: 커밋 히스토리 자체를 되돌림 (히스토리 수정)
C1 ──► C2 ──► C3   →   git reset --hard C1   →   C1
                C3가 히스토리에서 사라짐

git revert: 되돌리는 새 커밋을 추가 (히스토리 보존)
C1 ──► C2 ──► C3   →   git revert C3   →   C1 ──► C2 ──► C3 ──► C3'
                C3를 취소하는 C3' 커밋이 추가됨

항목	reset	revert
히스토리	수정(삭제)	보존
새 커밋 생성	없음	있음
공유 브랜치 사용	위험 (사용 금지)	안전
적합한 상황	로컬 작업 정리	push된 커밋 취소

git reset의 세 가지 옵션도 함께 알아두세요.

bash

git reset --soft HEAD~1   # 커밋만 취소, 변경 사항은 staging area에 유지
git reset --mixed HEAD~1  # 커밋 취소, 변경 사항은 working directory에 유지 (기본값)
git reset --hard HEAD~1   # 커밋 취소 + 변경 사항까지 모두 삭제 (복구 어려움)

면접 포인트: “이미 push된 커밋은 반드시 revert를 사용합니다. reset 후 강제 push(--force)는 팀원의 로컬 히스토리와 충돌을 일으키기 때문입니다”라고 덧붙이면 협업 경험이 있음을 어필할 수 있습니다.

Q8. `git stash`는 무엇이며, 어떤 상황에서 유용한가요?

모범 답변 구조:

git stash는 현재 작업 중인 변경 사항을 임시로 저장하고 Working Directory를 깨끗한 상태로 되돌리는 명령입니다. 커밋하기에는 아직 미완성인 작업을 잠시 치워두고, 다른 브랜치로 이동해야 할 때 유용합니다.

bash

# 현재 변경 사항 임시 저장
git stash

# stash 목록 확인
git stash list
# stash@{0}: WIP on feature: a1b2c3d 로그인 기능 작업 중

# 가장 최근 stash 복원 (stash에서 제거됨)
git stash pop

# 특정 stash 복원 (stash에 유지됨)
git stash apply stash@{1}

# stash에 이름 붙여서 저장 (관리 용이)
git stash save "로그인 UI 작업 임시 저장"

# stash 삭제
git stash drop stash@{0}
git stash clear  # 전체 삭제

실제 사용 시나리오:

1. feature/login 브랜치에서 작업 중 (미완성)
2. 갑자기 긴급 버그 수정 요청이 들어옴
3. git stash → Working Directory 정리
4. git checkout hotfix/urgent-bug 로 이동
5. 버그 수정 후 커밋 및 push
6. git checkout feature/login 으로 복귀
7. git stash pop → 이전 작업 내용 복원

Q9. `git rebase -i`(interactive rebase)는 어떤 용도로 사용하나요?

모범 답변 구조:

git rebase -i는 과거의 커밋 히스토리를 대화형으로 편집할 수 있는 강력한 기능입니다. PR(Pull Request) 제출 전 커밋 이력을 깔끔하게 정리할 때 특히 많이 씁니다.

bash

# 최근 3개 커밋을 대화형으로 편집
git rebase -i HEAD~3

편집기가 열리면 다음과 같은 목록이 표시됩니다.

pick a1b2c3d 로그인 폼 UI 추가
pick e4f5g6h 오타 수정
pick i7j8k9l 로그인 API 연결

# 명령어 옵션:
# pick   = 커밋 그대로 유지
# reword = 커밋 메시지만 수정
# edit   = 커밋 내용 수정
# squash = 이전 커밋에 합치기 (메시지 합침)
# fixup  = 이전 커밋에 합치기 (메시지는 버림)
# drop   = 커밋 삭제

주요 활용 사례:

squash / fixup: “오타 수정”, “주석 추가” 같은 잡다한 커밋을 의미 있는 단위로 합칠 때
reword: 오타나 불명확한 커밋 메시지를 수정할 때
drop: 실수로 만든 커밋을 히스토리에서 제거할 때

주의: interactive rebase도 커밋 해시를 바꾸므로, 이미 push된 브랜치에는 사용 후 --force-with-lease 옵션으로 신중하게 push해야 합니다.

5. 핵심 질문 ⑩: 브랜치 전략

Q10. Git Flow와 GitHub Flow의 차이를 설명하고, 각각 어떤 프로젝트에 적합한지 말해주세요.

팀 협업 경험과 프로젝트 설계 능력을 동시에 묻는 질문으로, 시니어 면접으로 갈수록 빈출도가 높아집니다.

모범 답변 구조:

Git Flow

Git Flow는 main, develop, feature, release, hotfix 총 5가지 브랜치 역할을 정의한 엄격한 브랜치 전략입니다.

[Git Flow 브랜치 구조]

main    ──●─────────────────────────●──────────────●──
           │(v1.0)                  │(v1.1)        │(v1.1.1)
hotfix  ──────────────────────────────────────────●──►
release ──────────────────────●──►
develop ──●──────●──────●──────────────────────────●──
            │     │      │
feature ────●──►  ●──►   ●──►

main: 프로덕션 배포 이력만 존재 (태그로 버전 관리)
develop: 다음 배포를 위한 통합 브랜치
feature/xxx: 각 기능 개발 브랜치 (develop에서 분기 → 병합)
release/x.x: 배포 준비 브랜치 (QA, 버전 번호 부여)
hotfix/xxx: 프로덕션 긴급 버그 수정

GitHub Flow

GitHub Flow는 main 브랜치 하나와 feature 브랜치만으로 운영하는 단순한 전략입니다.

[GitHub Flow 브랜치 구조]

main    ──●──────────────────────●──────────────●──
           │                    ▲               ▲
feature ────●──►... PR 승인 ──►┘               │
feature ──────────●──►... PR 승인 ─────────►──┘

main에서 기능 브랜치를 분기
작업 완료 후 PR(Pull Request) 오픈
코드 리뷰 통과 → main에 merge → 즉시 배포

항목	Git Flow	GitHub Flow
브랜치 수	5종 (복잡)	2종 (단순)
배포 주기	정기 배포 (버전 관리)	수시 배포 (CI/CD)
적합한 환경	모바일 앱, 패키지 소프트웨어	SaaS 웹 서비스, 스타트업
롤백 전략	release 브랜치 활용	main 즉시 revert
복잡도	높음	낮음

면접 포인트: “어느 전략이 더 좋다기보다, 배포 주기와 팀 규모에 맞는 전략을 선택하는 것이 중요합니다. 잦은 배포가 필요한 웹 서비스에는 GitHub Flow가 간결하고, 명확한 버전 관리가 필요한 패키지 제품에는 Git Flow가 더 적합합니다”라고 마무리하면 판단력이 있는 개발자로 보입니다.

6. 면접관이 기대하는 ‘좋은 답변’의 구조

Git 면접 질문에서 면접관이 실제로 기대하는 것은 다음 세 가지입니다.

① 개념 정의 → ② 동작 원리 → ③ 실무 사용 경험 또는 트레이드오프

예를 들어 “rebase가 뭔가요?”라는 질문에 이렇게 답변하면 좋습니다.

“rebase는 현재 브랜치의 커밋들을 다른 브랜치의 최신 커밋 위로 재배치하는 명령입니다. 내부적으로는 기존 커밋을 삭제하고 새로운 해시를 가진 커밋을 생성합니다. 저는 feature 브랜치에서 작업할 때 PR 제출 전에 rebase -i로 커밋을 정리하는 편인데, 공유 브랜치에는 히스토리가 바뀌어 팀원에게 혼란을 줄 수 있으므로 사용하지 않습니다.”

이처럼 개념 + 원리 + 본인 경험/판단을 묶어 답변하는 구조를 연습하세요.

7. Git 면접 대비 체크리스트 및 추천 학습 순서

면접 전 자가 점검 체크리스트

아래 항목을 말로 설명할 수 있는지 직접 점검해보세요.

□ Git의 세 가지 영역(Working Dir / Staging / Repository)을 설명할 수 있다
□ HEAD와 detached HEAD의 차이를 설명할 수 있다
□ fetch와 pull의 차이를 실무 맥락에서 설명할 수 있다
□ merge와 rebase의 차이와 각 사용 시점을 설명할 수 있다
□ fast-forward merge가 발생하는 조건을 설명할 수 있다
□ cherry-pick의 용도와 주의점을 설명할 수 있다
□ reset --soft / --mixed / --hard의 차이를 설명할 수 있다
□ reset과 revert를 언제 각각 써야 하는지 설명할 수 있다
□ stash의 사용 시나리오를 실제 경험과 연결해 설명할 수 있다
□ Git Flow와 GitHub Flow의 차이와 선택 기준을 설명할 수 있다

결론

Git 면접 질문은 명령어 암기 시험이 아닙니다. 면접관이 보고 싶은 것은 버전 관리의 원리를 이해하고, 팀 협업 상황에서 올바른 판단을 내릴 수 있는 개발자인지입니다. merge와 rebase 중 어느 것이 더 좋다고 외우는 것이 아니라, 상황에 따라 어느 것을 선택하고 그 이유를 설명할 수 있어야 합니다. 이 글의 체크리스트를 기준으로 모든 항목을 소리 내어 설명해보는 연습을 해보세요. 설명할 수 있다면 이해한 것이고, 설명이 막힌다면 아직 더 파야 할 부분입니다.

Related Posts:

Comments

답글 남기기 응답 취소

목차

1. Git이란 무엇인가: 분산 버전 관리 시스템의 개념

2. 핵심 질문 ①~③: 기초 개념

Q1. Git의 세 가지 영역(Working Directory, Staging Area, Repository)을 설명하세요.

Q2. HEAD란 무엇이며, detached HEAD 상태는 무엇인가요?

Q3. git fetch와 git pull의 차이를 설명하세요.

3. 핵심 질문 ④~⑥: 병합 전략

Q4. git merge와 git rebase의 차이를 설명하고, 각각 언제 사용하나요?

Q5. Fast-forward merge란 무엇이고, 언제 발생하나요?

Q6. git cherry-pick은 무엇이며, 어떤 상황에서 사용하나요?

4. 핵심 질문 ⑦~⑨: 실무 명령어

Q7. git reset과 git revert의 차이를 설명하세요.

Q8. git stash는 무엇이며, 어떤 상황에서 유용한가요?

Q9. git rebase -i(interactive rebase)는 어떤 용도로 사용하나요?

5. 핵심 질문 ⑩: 브랜치 전략

Q10. Git Flow와 GitHub Flow의 차이를 설명하고, 각각 어떤 프로젝트에 적합한지 말해주세요.

Git Flow

GitHub Flow

6. 면접관이 기대하는 ‘좋은 답변’의 구조

7. Git 면접 대비 체크리스트 및 추천 학습 순서

면접 전 자가 점검 체크리스트

추천 학습 순서

결론

Related Posts:

Comments

답글 남기기 응답 취소

Q3. `git fetch`와 `git pull`의 차이를 설명하세요.

Q4. `git merge`와 `git rebase`의 차이를 설명하고, 각각 언제 사용하나요?

Q6. `git cherry-pick`은 무엇이며, 어떤 상황에서 사용하나요?

Q7. `git reset`과 `git revert`의 차이를 설명하세요.

Q8. `git stash`는 무엇이며, 어떤 상황에서 유용한가요?

Q9. `git rebase -i`(interactive rebase)는 어떤 용도로 사용하나요?