상위 50개 GIT 인터뷰 질문 및 답변(2026)

작성자 : 루카스 베넷 루카스 베넷
Hours 업데이트

GIT 면접을 준비하시나요? 버전 관리 전문성을 평가하는 필수 질문들을 살펴보세요. GIT 면접 질문 문제 해결 능력, 협업 습관, 워크플로 관리 효율성을 파악하는 데 도움이 됩니다.

버전 관리 및 협업 분야는 탄탄한 기술 경험과 ​​도메인 전문 지식을 갖춘 전문가에게 엄청난 기회를 제공합니다. 신입부터 선임 엔지니어까지, 일반적이고 고급 개념을 숙지하면 까다로운 질의응답 세션을 해결하는 데 도움이 됩니다. 이 분야에서의 업무는 관리자와 팀 리더들이 중요하게 여기는 분석 능력, 팀워크, 그리고 실질적인 기술 전문성을 향상시킵니다.

기술 리더, 관리자, 개발자를 포함한 75명 이상의 전문가로부터 얻은 통찰력을 바탕으로, 이 가이드는 업계 전반의 GIT 면접 관점을 통합하여 모든 경험 수준에 대한 신뢰성, 실질적 정확성, 포괄적인 적용을 보장합니다.

GIT 면접 질문과 답변

GIT 면접 질문과 답변 상위 50개

1) Git이란 무엇이고 다른 버전 제어 시스템과 어떻게 다른가요?

Git은 분산 버전 관리 시스템으로 설계되었습니다. trac소프트웨어 개발 중 소스 코드에 발생하는 수많은 변경 사항을 관리할 수 있습니다. SVN이나 CVS와 같은 중앙 집중식 시스템과 달리 Git은 모든 개발자가 저장소의 전체 복사본과 변경 이력을 가질 수 있도록 합니다. 이러한 분산형 모델은 속도, 유연성 및 안정성을 향상시킵니다.

예: Git 저장소를 복제하면 오프라인으로 작업하고 로컬에서 커밋할 수 있는 반면, SVN에서는 모든 커밋에 인터넷 연결이 필요합니다.

요인 힘내 SVN
아키텍처 분산 중앙 집중식
속도 빠른 느린
오프라인 작업 지원 지원되지 않음
가지 가벼움 무겁고 느리다

👉 무료 PDF 다운로드: GIT 면접 질문 및 답변

2) Git 워크플로와 파일 수명 주기를 설명하세요.

Git 파일 수명 주기는 파일이 저장소에서 다양한 상태를 어떻게 이동하는지 나타냅니다.

Git의 파일은 다음 네 가지 기본 상태 중 하나로 존재할 수 있습니다. Untrac케드, 수정, 일부러 꾸민예산 및 최선을 다하고.

  1. Untrac케드: 새로 생성된 파일이 아직 Git에 추가되지 않았습니다.
  2. 수정 : 마지막 커밋 이후 편집된 파일입니다.
  3. 일부러 꾸민: 다음을 사용하여 추가된 파일 git add 그리고 헌신할 준비가 되었습니다.
  4. 헌신적인: 저장소에 영구적으로 저장된 파일 git commit.

예: 개발자가 새 파일을 생성합니다 → 실행 git add → 그런 다음 커밋합니다. 이 과정을 통해 파일의 생성부터 삭제까지 전체 수명 주기가 완료됩니다.trac헌신하기로 결심했다.

3) Git에서 브랜칭과 병합은 어떻게 이루어지나요?

브랜칭을 사용하면 여러 개발자가 기본 코드베이스에 영향을 주지 않고 동시에 개별 기능을 작업할 수 있습니다. 각 브랜치는 독립적인 개발 라인을 나타냅니다.

병합은 한 브랜치의 변경 사항을 다른 브랜치에 결합하는 것으로, 일반적으로 기능 브랜치를 다시 기본 브랜치에 통합하는 것입니다.

예: 당신이 만드는 경우 feature/login 브랜치를 만들고 독립적으로 작업한 다음 병합합니다. main, 새로운 기능을 안전하게 통합하세요.

Command 목적
git branch feature 새로운 지점을 만듭니다
git checkout feature 지점으로 전환
git merge feature 본점과 합병

4) Git 객체에는 어떤 유형이 있나요?

Git은 내부 데이터베이스에 데이터를 객체로 저장합니다. 네 가지 주요 객체 유형은 다음과 같습니다.

  1. 얼룩: 파일 데이터를 저장합니다.
  2. 나무: 디렉토리와 파일 구조를 나타냅니다.
  3. 범하다: 작성자, 날짜, 부모 커밋 등의 메타데이터로 변경 사항을 기록합니다.
  4. 태그: 특정 역사적 시점을 표시하며, 종종 출시에 사용됩니다.

이러한 객체는 Git의 무결성과 불변성을 구현하여 각 커밋이 SHA-1 해시를 통해 고유하게 식별되도록 보장합니다.

5) Git fetch와 Git pull의 차이점은 무엇인가요?

git fetch 원격 저장소에서 변경 사항을 다운로드하지만 자동으로 병합하지는 않습니다. 로컬 원격 저장소를 업데이트합니다.trac왕의 가지.

git pull 한 단계에서 가져오기와 병합을 모두 수행합니다.

Command 기술설명 적용 사례
git fetch 병합하지 않고 변경 사항을 다운로드합니다. 병합하기 전에 업데이트를 검사하려는 경우
git pull 변경 사항을 자동으로 다운로드하고 병합합니다. 즉각적인 동기화를 원할 때

예: git fetch 병합하기 전에 다른 사람의 변경 사항을 검토하기 위해 협업할 때.

6) Git은 어떻게 데이터 무결성을 보장하나요?

Git은 다음을 통해 데이터 무결성을 보장합니다. SHA-1 해싱모든 커밋, 트리, 블롭은 고유한 40자 해시로 식별됩니다. 이를 통해 단 하나의 비트만 변경되어도 해시가 변경되어 손상이나 변조를 방지할 수 있습니다.

또한 Git은 다음을 사용합니다. 방향성 비순환 그래프 (DAG) 커밋이 상위 커밋을 참조하는 구조를 통해 일관성을 보장합니다. trac재미있는 역사.

예: 파일의 내용이 변경되면 SHA-1 값도 변경되므로 Git은 이를 즉시 새로운 버전으로 인식합니다.

7) Git Rebase와 Git Merge의 차이점을 설명하세요.

모두 git merge git rebase 한 가지 분야의 변화를 다른 분야에 통합하는 것은 가능하지만 접근 방식은 서로 다릅니다.

  • 병합 : 히스토리를 결합하는 새로운 병합 커밋을 생성합니다.
  • 리베이스: 커밋을 한 브랜치에서 다른 브랜치로 이동하거나 재생하여 선형 기록을 만듭니다.
요인 병합 리베이스
커밋 기록 비선형 선의
새로운 커밋이 생성되었습니다 가능 아니
적용 사례 역사를 보존하다 더 깨끗한 역사

예: git rebase 깨끗한 프로젝트 기록을 유지하기 위해 git merge 공유된 공개 브랜치에 더 적합합니다.

관련 기사

8) Git Hooks란 무엇이고, 어떤 이점이 있나요?

Git 후크는 커밋, 병합, 푸시와 같은 특정 Git 이벤트에 의해 트리거되는 사용자 지정 스크립트입니다. 코딩 표준을 준수하고 워크플로를 자동화하는 데 도움이 됩니다.

후크의 종류:

  • 클라이언트 측 후크: 로컬 작업(예: 사전 커밋)을 실행합니다.
  • 서버 측 후크: 원격 저장소 작업(예: 사전 수신)을 실행합니다.

이점:

  • 포맷 오류가 있는 커밋을 방지합니다.
  • 코드 린팅이나 테스트를 자동화합니다.
  • 팀 전체에서 일관된 워크플로를 보장합니다.

예: A pre-commit 단위 테스트가 실패하면 hook이 커밋을 거부할 수 있습니다.

9) Git을 사용하는 데에는 어떤 장점과 단점이 있나요?

아래 장점 단점
성능 분기/병합에 빠르고 효율적입니다. 초보자에게는 복잡할 수 있음
협업 분산 개발을 가능하게 합니다 잠재적인 병합 충돌
유연성 오프라인에서 작동 설정 및 학습이 필요합니다
스토리지 대규모 프로젝트를 처리합니다 저장 공간이 빠르게 증가할 수 있습니다

전반적으로 Git의 분산 모델, 데이터 무결성, 유연성 덕분에 새로운 개발자에게는 학습 곡선이 있지만 업계 표준이 되었습니다.

10) Git에서 병합 충돌을 어떻게 해결하나요?

병합 충돌은 Git이 브랜치 간의 변경 사항을 자동으로 조정할 수 없을 때 발생합니다.

해결 단계:

  1. 충돌하는 파일을 식별하세요 git status.
  2. 파일을 열고 충돌 표시기를 찾습니다(<<<<<<<, =======, >>>>>>>).
  3. 파일을 수동으로 편집하여 변경 사항을 선택하거나 결합합니다.
  4. 파일을 사용하여 스테이징합니다. git add.
  5. 해결된 병합을 커밋합니다. git commit.

예: 두 개발자가 서로 다른 브랜치에 있는 파일의 같은 줄을 편집하면 Git은 병합하는 동안 충돌을 일으켜 수동으로 해결해야 합니다.

11) git reset, git revert, git checkout의 차이점은 무엇인가요?

이 세 가지 명령은 Git 기록을 각기 다르게 수정하며 각기 다른 목적을 위해 사용됩니다.

Command 함수 데이터 영향 적용 사례
git reset HEAD 포인터를 특정 커밋으로 뒤로 이동합니다. 변경 사항 커밋 기록 로컬에서 커밋 취소
git revert 이전 변경 사항을 취소하는 새 커밋을 생성합니다. 커밋 기록을 보존합니다 공유 브랜치에서 커밋을 안전하게 취소합니다.
git checkout 지점을 전환하거나 파일을 복원합니다. 커밋 기록에 영향을 미치지 않습니다 지점 간 이동 또는 로컬 변경 사항 삭제

예: 실수로 민감한 데이터를 유출한 경우 다음을 사용하세요. git revert 커밋 기록을 변경하지 않고 안전하게 실행 취소할 수 있습니다.

git reset --hard 푸시하기 전에 로컬 수정만 가능합니다.

12) Git의 재설정 유형을 설명하세요.

Git은 변경 사항을 취소할 시점에 따라 세 가지 주요 재설정 유형을 제공합니다.

타입 Command 행동
부드러움 git reset --soft <commit> HEAD를 이동하지만 인덱스와 작업 디렉토리는 그대로 유지됩니다.
혼합 된 git reset --mixed <commit> HEAD를 이동하고 인덱스를 재설정합니다. 변경 사항은 작업 디렉토리에 남아 있습니다.
하드 git reset --hard <commit> HEAD, 인덱스 및 작업 디렉토리를 완전히 재설정합니다.

예: 변경 사항을 조기에 적용한 경우 git reset --soft HEAD~1 수정 후 다시 커밋할 수 있습니다.

13) Git Stash란 무엇이고, 언제 사용해야 하나요?

git stash 커밋되지 않은 변경 사항을 일시적으로 저장하여 작업을 잃지 않고 브랜치를 전환할 수 있습니다.

이 기능은 멀티태스킹 중이거나 다른 부서를 긴급하게 검토해야 할 때 특히 유용합니다.

일반적인 명령:

  • git stash: 로컬 수정 사항을 저장합니다.
  • git stash pop: 저장된 변경 사항을 복원합니다.
  • git stash list: 저장된 모든 보관함을 표시합니다.

예: 기능을 구현하는 도중에 프로덕션 문제가 발생하면 변경 사항을 보관하고 문제를 해결한 다음 보관된 작업을 다시 적용합니다.

14) Git은 원격 저장소를 어떻게 처리하나요?

Git의 원격 저장소는 개발자 간 협업에 사용되는 인터넷이나 네트워크에 호스팅된 프로젝트 버전입니다.

일반적인 원격 명령:

Command 기술설명
git remote add origin <url> 로컬 저장소를 원격 저장소에 연결합니다.
git push 원격 저장소에 커밋을 보냅니다.
git pull 변경 사항을 검색하고 병합합니다.
git fetch 변경 사항을 검색하지만 병합하지 않습니다.

예: 개발자는 일반적으로 GitHub이나 GitLab과 같은 플랫폼에서 원격 저장소를 복제하여 공유 프로젝트에 기여합니다.

15) Git 태그란 무엇이고 왜 중요한가요?

태그는 특정 커밋을 가리키는 포인터로, 종종 릴리스 지점을 표시하는 데 사용됩니다(예: v1.0, v2.1).

이들은 변경 불가능한 코드베이스 버전을 참조하여 안정성을 제공합니다.

태그 유형:

  1. 가벼운 태그: 간단한 커밋 참조.
  2. 주석이 달린 태그: 메타데이터(작성자, 메시지, 날짜)를 저장합니다.
Command 목적
git tag v1.0 가벼운 태그를 생성합니다
git tag -a v2.0 -m "Release 2.0" 주석이 달린 태그를 만듭니다.
git push origin --tags 모든 태그를 원격으로 푸시합니다.

예: 릴리스 팀은 주석이 달린 태그를 사용하여 안정적인 제품 버전을 패키징하고 배포합니다.

16) Git Cherry-Pick이란 무엇이고, 어떻게 유용합니까?

git cherry-pick 한 브랜치의 특정 커밋을 다른 브랜치에 선택적으로 통합할 수 있습니다.

이 기능은 전체 브랜치를 병합하지 않고 특정 버그 수정이나 기능을 적용하려는 경우에 유용합니다.

예: 다음에서 수정을 적용할 수 있습니다. feature/bugfix 에 main 사용

git cherry-pick <commit-hash>

이점:

  • 커밋 통합에 대한 정확한 제어.
  • 불필요한 코드 병합을 방지합니다.
  • 중요한 브랜치에서 더 깨끗한 기록을 유지합니다.

17) Git Squash란 무엇이고, 어떤 장점이 있나요?

Git의 스쿼싱은 여러 커밋을 하나로 결합하여 더 간단하고 깔끔한 커밋 기록을 만듭니다.

명령 :

git rebase -i HEAD~3

그런 다음 squash 병합하려는 커밋에 대한 옵션입니다.

이점:

  • 간결한 역사를 작성합니다.
  • 풀 리퀘스트를 검토하기 쉽게 만듭니다.
  • 사소한 커밋으로 인한 혼란을 줄입니다.

예: 개발자는 기능 브랜치를 병합하기 전에 모든 작은 커밋을 하나의 의미 있는 커밋으로 압축하는 경우가 많습니다.

18) Git에서 푸시된 커밋을 되돌리려면 어떻게 해야 하나요?

커밋이 원격 저장소에 푸시되면 안전하게 삭제할 수 없지만 다음을 사용하여 되돌릴 수 있습니다.

git revert <commit-hash>
git push origin main

Reset과의 차이점 Revert:

요인 다시 쓰기 Revert
연혁 역사 다시 쓰기 역사를 보존하다
안전 공유 저장소에 안전하지 않음 공공 지점에 안전합니다
용법 로컬 실행 취소 원격 실행 취소

예: 잘못된 커밋이 이미 GitHub에 있는 경우 다음을 사용하세요. git revert 대신 git reset 일관된 공유 역사를 유지하기 위해.

19) Git과 GitHub의 차이점은 무엇인가요?

힘내 버전 제어 도구, GitHub은 클라우드 기반 플랫폼 Git 저장소를 호스팅하기 위해.

아래 힘내 GitHub의
자연 명령줄 도구 웹 기반 서비스
함수 Tracks 코드 변경 사항은 로컬에서 적용됩니다. 원격 협업을 가능하게 합니다
인터넷 요구 사항 Optional 필수
소유권 오픈 소스 (리누스 제작) Tor유효성) 에게 소유 된 Microsoft

예: 개발자는 Git을 사용하여 로컬에서 소스 코드 버전을 관리하고 GitHub을 사용하여 팀원과 코드를 공유하고 검토합니다.

20) Git 병합 전략에는 어떤 것이 있나요?

Git은 변경 사항을 결합하는 방법에 따라 다양한 병합 전략을 제공합니다.

전략 기술설명 적용 사례
재귀 기본값; 두 개의 브랜치를 병합합니다. 표준 병합
우리 것 현재 브랜치의 변경 사항을 유지합니다. 들어오는 변경 사항 삭제
그들의 것 들어오는 브랜치의 변경 사항을 유지합니다. 로컬 변경 사항 재정의
문어 (蛸) 여러 개의 브랜치를 동시에 병합합니다 통합 브랜치

예: 복잡한 통합 중에 개발자는 다음을 사용할 수 있습니다. recursive 표준 병합을 위한 전략 또는 ours 지역적 변화를 우선시합니다.

21) Git의 Detached HEAD란 무엇이고, 어떻게 수정하나요?

A 분리된 HEAD 때 발생합니다 HEAD 포인터는 브랜치를 가리키는 것이 아니라 특정 커밋을 가리킵니다. 이는 다음을 사용하여 이전 커밋을 직접 체크아웃할 때 발생합니다.

git checkout <commit-hash>

이 상태에서는 새로운 커밋이 브랜치와 연결되지 않으며, 제대로 참조되지 않으면 손실될 수 있습니다.

어떻게 고치는 지:

  1. 분리된 상태에서 새 브랜치를 만듭니다. 
    git checkout -b temp-branch
  2. 그런 다음 평소처럼 커밋하거나 병합합니다.

예: 이전 버전의 코드를 테스트할 때 분리된 HEAD를 입력할 수 있습니다. 변경 사항을 유지하려면 항상 브랜치를 생성하세요.

22) git reflog의 목적은 무엇이고 언제 사용해야 합니까?

git reflog 이는 강력한 명령입니다 tracks의 모든 움직임 HEAD 눈에 보이는 브랜치 히스토리에 포함되지 않은 커밋까지 포함하여 모든 커밋을 복구합니다. 손실된 커밋을 복구하기 위한 안전망 역할을 합니다.

용법:

git reflog
git checkout <commit-hash>

예:

실수로 실행하면 git reset --hard 최근 커밋을 잃어버리고, git reflog 찾아서 복원할 수 있습니다.

이점:

  • 잘못된 리베이스나 재설정 이후 손실된 작업을 복구합니다.
  • 자세한 커밋 탐색 기록을 제공합니다.
  • 복잡한 작업 흐름에서 안전성을 향상시킵니다.

23) Git 하위 모듈과 사용 사례를 설명하세요.

A Git 하위 모듈 하나의 Git 저장소를 다른 저장소 내의 하위 폴더로 포함할 수 있습니다. 다른 저장소에 의존하는 프로젝트를 관리할 때 사용됩니다.

일반적인 명령:

git submodule add <repo-url>
git submodule update --init

예: 웹 애플리케이션에는 여러 프로젝트에 걸쳐 Git 하위 모듈로 공유 인증 모듈이 포함될 수 있습니다.

장점 단점
Promo테스트 코드 재사용 CI/CD 파이프라인을 복잡하게 만들 수 있습니다.
독립적인 역사를 유지합니다 수동 업데이트 필요
버전 일관성을 보장합니다 더 높은 학습 곡선

24) Git 워크플로는 무엇이고, 어떤 유형이 있나요?

Git 워크플로는 팀이 Git을 사용하여 협업하는 데 사용하는 체계적인 접근 방식을 정의합니다. 가장 널리 사용되는 유형은 다음과 같습니다.

워크플로우 기술설명 적용 사례
깃 플로우 기능, 개발 및 릴리스 브랜치를 사용합니다. 대규모 프로젝트
GitHub 플로우 메인 및 기능 브랜치를 사용하여 단순화된 흐름 지속적인 배포
GitLab 흐름 CI/CD 통합과 Git Flow를 결합합니다. DevOps 중심 프로젝트
트렁크 기반 개발자는 단일 공유 브랜치에 커밋합니다. 민첩하고 빠른 배송 팀

예: 스타트업은 종종 다음을 채택합니다. 트렁크 기반 기업은 속도를 위해 워크플로를 선호합니다. 깃 플로우 통제된 방출을 위해.

25) Git Bisect란 무엇이고 디버깅에 어떻게 도움이 되나요?

git bisect 버그를 발생시킨 커밋을 식별하기 위해 이진 검색을 사용하는 강력한 디버깅 도구입니다.

예시 워크플로:

  1. 이등분 시작: git bisect start
  2. 현재 커밋을 잘못된 커밋으로 표시: git bisect bad
  3. 마지막으로 알려진 좋은 커밋을 표시하세요: git bisect good <commit>
  4. Git은 중간점을 자동으로 체크아웃합니다.
  5. 잘못된 커밋을 찾을 때까지 테스트하고 계속합니다.

이점:

  • 속도 향상 버그 trac대규모 코드베이스에서 작업합니다.
  • 수동 커밋 검사를 줄입니다.
  • CI/CD 회귀 테스트에 이상적입니다.

26) Git Merge Conflict와 Rebase Conflict의 차이점은 무엇인가요?

두 가지 문제 모두 Git이 코드 차이를 자동으로 조정할 수 없을 때 발생하지만, 서로 다른 맥락에서 발생합니다.

타입 그것이 발생할 때 분해능
병합 충돌 시 git merge 가지 사이 대상 브랜치에서 해결
리베이스 충돌 시 git rebase 커밋을 재생하는 동안 리베이스하면서 해결한 후 계속 진행하세요. git rebase --continue

예: 두 개의 브랜치에서 동일한 줄이 다르게 편집되면 병합 충돌이 발생하고, 리베이스하는 동안에도 비슷한 변경 사항이 리베이스 충돌을 유발합니다.

27) Git을 CI/CD 파이프라인에 어떻게 통합할 수 있나요?

Git은 각 커밋이나 풀 요청 시 자동화된 프로세스를 트리거하여 현대 CI/CD 워크플로의 기반을 형성합니다.

통합 예:

  • 커밋 푸시 → Triggers a CI pipeline (via Jenkins, GitHub Actions, or GitLab CI).
  • 빌드 및 테스트 → 자동화된 테스트는 커밋을 검증합니다.
  • 배포 → 변경 사항은 스테이징이나 프로덕션으로 푸시됩니다.

이점:

  • 일관된 배포를 보장합니다.
  • 빠른 피드백 주기를 가능하게 합니다.
  • 출시 과정에서 발생하는 인적 오류를 줄입니다.

예: GitHub Actions는 변경 사항이 푸시될 때 프로젝트를 자동으로 테스트하고 배포할 수 있습니다. main 분기.

28) git clean과 git reset의 차이점은 무엇인가요?

Command 목적 범위 예시
git clean 제거tracked 파일 작업 디렉토리 git clean -f -d
git reset HEAD 포인터를 이동합니다 커밋, 인덱스 및 작업 트리 git reset --hard HEAD~1

예: 워크스페이스에 임시 파일이나 생성된 파일이 있는 경우 tracGit에 의해 ked, 사용 git clean커밋을 취소해야 하는 경우 다음을 사용하세요. git reset.

Tip 항상 검토하세요 git clean -n 실수로 삭제하는 것을 방지하려면 실행하기 전에 확인하세요.

29) Git Reflog와 Git Log의 차이점은 무엇인가요?

둘 다 커밋 기록을 표시하지만, 목적은 서로 다릅니다.

Command Tracks 삭제된 커밋 포함 적용 사례
git log 보이는 커밋 기록 아니 Rev프로젝트 진행 상황 보기
git reflog 모든 HEAD 움직임 가능 손실된 커밋 복구

예: 실수로 브랜치를 삭제한 후에는 다음을 사용할 수 있습니다. git reflog 마지막 커밋을 찾아 복구하려면 다음이 필요합니다. git log.

30) 대규모 팀에서 Git을 효과적으로 사용하기 위한 모범 사례는 무엇입니까?

  1. 지점 명명 규칙을 사용하세요: 다음과 같은 패턴을 따르세요 feature/login-ui or bugfix/payment.
  2. 자주, 그러나 의미 있게 헌신하세요: 각 커밋을 단일 논리적 변경 사항에 집중하세요.
  3. 쓰다 Descriptive 커밋 메시지: 명령형을 사용하세요. 예를 들어, "Fix user login validation."
  4. 병합하기 전에 리베이스하세요: 커밋 기록을 깔끔하게 유지합니다.
  5. 풀 리퀘스트를 사용하세요 Rev보기: Promo테스트 협업 및 코드 품질.
  6. 태그를 지속적으로 릴리스합니다. 버전 제어와 롤백에 도움이 됩니다.
  7. CI/CD를 통한 테스트 자동화: 안정적인 통합과 더 빠른 릴리스를 보장합니다.

예: 기업 개발에서 체계적인 Git 사용은 충돌을 방지하고 릴리스 관리를 간소화합니다.

31) Git 내부란 무엇이고 Git은 어떻게 데이터를 저장합니까?

Git 내부는 Git 기능을 구동하는 저수준 아키텍처를 의미합니다. Git은 모든 것(파일, 디렉터리, 커밋)을 다음과 같이 저장합니다. 사물 인간을 .git/objects 디렉토리. 이러한 객체는 다음으로 식별됩니다. SHA-1 해시 그리고 다음과 같이 분류됩니다. 블롭, 트리, 커밋 및 태그.

데이터 저장 수명 주기:

  1. 파일이 추가되면 해당 내용은 다음과 같이 저장됩니다. blob.
  2. A tree 맵 파일 구조.
  3. A commit 나무와 메타데이터를 연결합니다.
  4. A tag 릴리스를 위한 커밋을 참조합니다.

예: 달리는 git cat-file -p <hash> Git 객체를 직접 검사할 수 있습니다.

이 디자인은 다음을 보장합니다. 데이터 무결성, 버전 trac능력예산 및 경량 성능따라서 Git은 SVN과 같은 기존 시스템에 비해 매우 효율적입니다.

32) Git Rebase Interactive와 Git Merge의 차이점은 무엇인가요?

요인 Git Rebase Interactive(git rebase -i) Git 병합
목적 커밋 편집, 재정렬 및 ​​스쿼싱을 허용합니다. 역사를 결합하다
연혁 역사 다시 쓰기 모든 커밋을 보존합니다
적용 사례 병합 전 정리 원래 타임라인 유지

예: 기능 브랜치를 병합하기 전에 개발자는 다음을 사용할 수 있습니다.

git rebase -i main

불필요한 커밋을 제거하고 더 깔끔하고 선형적인 기록을 생성합니다.

병합 협업 브랜치에서는 더 안전하지만 리베이스 개인 개발 워크플로의 가독성을 향상시킵니다.

33) Git의 Sparse Checkout이란 무엇이고, 어떤 이점이 있나요?

스파스 체크아웃 개발자가 대규모 저장소에서 일부 파일만 복제하거나 작업할 수 있으므로 로컬 저장소 사용량이 줄어들고 작업 속도가 빨라집니다.

명령 :

git clone --no-checkout <repo-url>
git sparse-checkout init --cone
git sparse-checkout set <folder-path>

이점:

  • 모노레포의 성능이 향상됩니다.
  • 디스크 사용량을 줄입니다.
  • 마이크로서비스 아키텍처에 이상적입니다.

예: 대규모 기업 프로젝트에서는 개발자에게 다음 사항만 필요할 수 있습니다. /frontend 폴더. Sparse Checkout은 해당 디렉토리만 다운로드하므로 불필요한 기가바이트 단위의 백엔드 코드가 생성되는 것을 방지합니다.

34) 얕은 클론이란 무엇이고 언제 사용해야 합니까?

A 얕은 클론 저장소 기록의 일부만 다운로드하므로 복제 속도가 훨씬 빨라집니다.

명령 :

git clone --depth=1 <repo-url>

이점:

  • 대규모 저장소의 복제 시간을 줄여줍니다.
  • 대역폭과 디스크 공간을 절약합니다.
  • 최근 커밋만 필요한 CI 파이프라인에 유용합니다.

단점 :

  • 이전 커밋에 접근할 수 없고 가져온 깊이를 넘어서 리베이스할 수 없습니다.
  • 제한된 과거 내역 공개.

예: CI/CD 시스템은 종종 완전한 커밋 기록 없이 자동화된 빌드를 위한 최신 코드 버전을 빠르게 가져오기 위해 얕은 복제본을 사용합니다.

35) Git LFS(대용량 파일 저장소)란 무엇이고, 왜 사용되나요?

힘내 LFS (대용량 파일 저장소)는 Git 내에서 대용량 파일(예: 이미지, 데이터 세트, 바이너리)을 가벼운 텍스트 포인터로 대체하는 확장 기능으로, 실제 내용은 원격 LFS 서버에 저장합니다.

명령 예:

git lfs install
git lfs track "*.zip"

장점:

  • 저장소를 가볍게 유지합니다.
  • 대용량 바이너리 파일의 성능을 향상시킵니다.
  • GitHub, GitLab 등과 완벽하게 연동됩니다. Bitbucket.

예: 게임 개발팀은 Git LFS를 사용하여 일반적인 Git 작업 속도를 늦추지 않고 대규모 3D 자산을 처리합니다.

36) 최적의 성능을 위해 Git을 어떻게 구성할 수 있나요?

구성 매개변수를 미세 조정하면 Git의 속도와 사용성을 개선할 수 있습니다.

모범 사례:

  • 압축 활성화: git config --global core.compression 9
  • 자동 GC(가비지 수집) 설정: git gc --auto
  • 병렬 페칭 사용(v2.31+): git config --global fetch.parallel 4
  • 자격 증명 캐싱 활성화: git config --global credential.helper cache

예: 기업 규모의 저장소의 경우 Git의 가져오기 및 압축 설정을 최적화하면 복제 및 가져오기 지연 시간이 크게 줄어들어 분산된 팀의 생산성이 향상됩니다.

37) Git의 커밋 서명(GPG)이란 무엇이고 왜 중요한가요?

커밋 서명 사용 GPG(GNU 프라이버시 가드) 커밋의 진위를 암호화하여 검증하고, 변경 사항이 신뢰할 수 있는 기여자로부터 이루어졌는지 확인합니다.

설정 예:

git config --global user.signingkey <GPG-key>
git commit -S -m "Signed commit"

이점:

  • 허가되지 않은 커밋이나 사칭된 커밋을 방지합니다.
  • 저장소 보안과 감사 기능을 강화합니다.
  • 조직 내 신뢰를 구축합니다.

예: 오픈소스 프로젝트에서는 외부 개발자의 기여의 진위를 확인하기 위해 GPG 서명 커밋이 필요한 경우가 많습니다.

38) Git은 텍스트 파일과 어떻게 다르게 바이너리 파일을 처리합니까?

Git은 텍스트 기반 소스 코드에 최적화되어 있습니다. tracks 줄별 변경이 방식은 바이너리 파일에는 적합하지 않습니다. 바이너리 파일은 단일 블롭(blob)으로 저장되므로, 수정하면 diff가 아닌 새 버전이 생성됩니다.

파일 형식 스토리지 효율성 Diff 지원 권장 취급
본문 매우 효율적이다. 가능 기본 Git
이진 무능한 아니 Git LFS 사용

예: 이미지가 많은 저장소의 경우 Git LFS를 활성화하면 빈번한 바이너리 파일 업데이트로 인한 성능 저하를 방지할 수 있습니다.

39) 분리된 HEAD나 병합 오류와 같은 일반적인 Git 문제는 ​​어떻게 해결하시나요?

일반적인 문제 및 해결 방법:

발행물 원인 해법
분리된 HEAD 특정 커밋의 체크아웃 브랜치를 생성하세요 git checkout -b new-branch
병합 충돌 파일에서 충돌하는 편집 수동으로 해결한 다음 git add git commit
손실된 커밋 실수로 재설정하거나 리베이스함 git reflog 회복
푸시 거부됨 원격 업데이트가 앞으로 진행됩니다 푸시하기 전에 풀하거나 리베이스하세요

예: "빠른 전달 불가" 오류가 발생하는 경우 일반적으로 원격 변경 사항이 존재한다는 것을 의미합니다. git pull --rebase 다시 시도하기 전에 동기화하세요.

40) Git 저장소의 보안 모범 사례는 무엇입니까?

  1. SSH 또는 HTTPS 인증을 사용하세요: 일반 자격 증명을 사용하지 마세요.
  2. Git 호스팅 플랫폼에서 2FA를 활성화합니다.
  3. 비밀이나 열쇠를 유출하지 마세요. .gitignore 또는 GitGuardian과 같은 도구.
  4. GPG 키로 커밋에 서명합니다.
  5. 접근 제어 제한: 최소 권한 원칙을 시행합니다.
  6. 지점 보호 규칙을 사용하세요 main or master.
  7. 정기적으로 저장소 감사를 수행합니다.

예: 기업에서는 종종 비밀 스캐닝을 통합하고 CI/CD 파이프라인에 서명된 커밋을 적용하여 데이터 유출과 무단 변경을 방지합니다.

41) 쉘을 사용하여 Git 작업을 자동화하는 방법은 무엇입니까? Python 스크립트?

Git 자동화는 커밋, 병합, 배포와 같은 반복적인 작업의 생산성과 일관성을 향상시킵니다.

예 - 쉘 스크립트:

#!/bin/bash
git add .
git commit -m "Auto commit on $(date)"
git push origin main

예 - Python 스크립트(Git 사용)Python):

from git import Repo
repo = Repo('.')
repo.git.add(A=True)
repo.index.commit("Automated commit")
origin = repo.remote(name='origin')
origin.push()

이점:

  • 수동 작업이 줄어듭니다.
  • 일관된 커밋 패턴을 보장합니다.
  • CI/CD 및 DevOps 파이프라인과 완벽하게 통합됩니다.

42) Git Hooks란 무엇이고 자동화에 어떻게 사용할 수 있나요?

힘내 후크 특정 Git 이벤트에 의해 트리거되는 스크립트로, 규칙을 적용하거나 프로세스를 자동화하는 데 사용됩니다.

후크의 종류:

타입 실행 중 예시
고객 입장에서 개발자의 기계 pre-commit, prepare-commit-msg
서버 측 원격 저장소 pre-receive, post-receive

예: A pre-commit hook은 커밋을 허용하기 전에 린터나 단위 테스트를 실행할 수 있습니다.

이점:

  • 코드 품질을 유지합니다.
  • 정책 위반을 방지합니다.
  • 워크플로에서 반복적인 검증 작업을 자동화합니다.

43) SVN이나 Mercurial에서 Git으로 프로젝트를 마이그레이션하려면 어떻게 해야 하나요?

다음과 같은 중앙화된 시스템에서 마이그레이션 SVN 에 힘내 커밋 기록을 유지하기 위해 구조화된 변환이 필요합니다.

단계 :

  1. 마이그레이션 도구 설치: git svn or svn2git.
  2. SVN 저장소 복제: 
    git svn clone <SVN_URL> --trunk=trunk --branches=branches --tags=tags
  3. 태그와 브랜치를 변환합니다.
  4. 원격 Git 저장소(예: GitHub)에 푸시합니다.

장점:

  • 분산된 워크플로를 지원합니다.
  • 성능과 유연성이 향상됩니다.
  • 분기화와 병합을 간소화합니다.

예: 레거시 SVN 시스템에서 마이그레이션하는 조직은 다음을 사용합니다. svn2git 저자의 신분을 보호하고 역사를 기록합니다.

44) Git Flow와 Trunk 기반 개발의 차이점은 무엇입니까?

아래 깃 플로우 트렁크 기반 개발
가지 여러 브랜치(개발, 릴리스) 단일 메인 브랜치
출시 모델 고정된 릴리스 주기 지속적인 배포
복잡성 보통에서 높음 높음
가장 좋은 대규모의 안정적인 팀 민첩하고 빠르게 움직이는 팀

예: Git Flow는 제어된 릴리스를 사용하는 엔터프라이즈 프로젝트에 가장 적합한 반면, Trunk-Based는 속도가 중요한 스타트업이나 마이크로서비스에 이상적입니다.

혜택 비교:

  • Git 흐름: 강력한 버전 제어.
  • 트렁크 기반: 더 빠른 피드백과 CI/CD 정렬.

45) 매우 큰 저장소의 경우 Git 성능을 최적화할 수 있는 전략은 무엇입니까?

커밋이나 기여자가 수천 명인 기업 규모 프로젝트의 경우, Git을 최적화하지 않으면 성능이 저하될 수 있습니다.

주요 최적화 전략:

  1. 얕은 클론 (--depth=1)을 눌러 더 빠른 결제를 받으세요.
  2. 스파스 체크아웃 관련 디렉토리만 가져옵니다.
  3. 달리기 쓰레기 수거: git gc --aggressive.
  4. 모노레포를 하위 모듈이나 마이크로서비스로 분할합니다.
  5. 정기적으로 객체를 압축하고 파일을 압축합니다.

예: 10GB를 초과하는 모노레포의 경우, 스파스 체크아웃과 정기적인 가비지 수집을 활성화하면 복제 및 페치 시간이 크게 줄어듭니다.

46) Git은 분산 팀에서 협업 개발을 어떻게 지원합니까?

Git은 전체 저장소 사본을 개발자 간에 배포하여 협업을 지원합니다. 각 개발자는 로컬에서 커밋하고, 원격 저장소에 변경 사항을 푸시하고, 다른 개발자의 작업을 병합할 수 있습니다.

협업 워크플로우 예:

  1. 저장소를 포크합니다.
  2. 기능 브랜치를 생성합니다.
  3. 변경 사항을 푸시하고 풀 리퀘스트를 엽니다.
  4. Rev보기 및 병합 main.

이점:

  • 병렬 기능 개발이 가능합니다.
  • 종속성 병목 현상을 줄입니다.
  • 오프라인 작업과 유연한 워크플로를 지원합니다.

예: 전 세계의 오픈소스 기여자들은 GitHub에 호스팅된 포크와 풀 리퀘스트를 통해 비동기적으로 협업합니다.

47) Git 가비지 컬렉션이란 무엇이고 왜 중요한가요?

git gc (가비지 컬렉션)은 불필요한 파일을 정리하고 객체를 압축하고 도달할 수 없는 커밋을 정리하여 저장소 저장소를 최적화합니다.

명령 :

git gc --aggressive --prune=now

이점:

  • 디스크 공간을 확보합니다.
  • 저장소 성능이 향상됩니다.
  • 커밋 객체의 중복을 줄입니다.

예: 개발자들은 종종 다음을 실행합니다. git gc 특히 장기 프로젝트에서 여러 번 병합하거나 브랜치를 삭제한 후에도 저장소 상태를 유지하기 위해 사용됩니다.

48) Git Blame이란 무엇이고 디버깅에 어떻게 사용되나요?

git blame 파일의 각 줄을 마지막으로 수정한 커밋과 작성자를 식별합니다.

명령 예:

git blame app.py

사용 사례:

  • Trac버그를 도입하는 것.
  • 코드 섹션의 소유권을 식별합니다.
  • 책임성을 위해 변경 사항을 감사합니다.

예: 최근 업데이트 이후 기능이 실패하기 시작한 경우 git blame 변경 사항을 만든 특정 커밋과 개발자를 정확히 찾아 디버깅 속도를 높일 수 있습니다.

49) Git에서 포킹과 클로닝의 차이점은 무엇인가요?

요인 포크 복제
정의 호스팅 서비스의 계정에 있는 저장소 사본 저장소의 로컬 복사본
오시는 길 서버 측(예: GitHub) 개발자의 기계
적용 사례 다른 프로젝트에 기여하기 지역 개발
관계 풀 리퀘스트를 통해 연결됨 원격과 직접 동기화

예: 오픈소스 프로젝트에 기여할 때는 저장소를 포크하고, 복제한 후 로컬에서 변경하고, 검토를 위해 풀 리퀘스트를 제출합니다.

50) 가장 흔한 Git 실수는 무엇이며, 이를 피하는 방법은 무엇입니까?

잘못 기술설명 예방
민감한 데이터 커밋 비밀이나 자격증명 포함 .gitignore 또는 GitGuardian
공유 브랜치에 강제 푸시 다른 사람의 작업을 덮어씁니다 --force-with-lease
대규모 바이너리 커밋 레포 성능이 저하됩니다 Git LFS 사용
건너뛰기ping 코드 리뷰 품질이 좋지 않음 풀 리퀘스트를 사용하세요
리베이스 충돌 무시 병합 혼란을 야기합니다 푸시하기 전에 갈등을 신중하게 해결하세요

예: 개발자가 실수로 .env 자격 증명이 있는 파일은 민감한 정보를 노출할 수 있습니다. 이는 다음을 통해 방지할 수 있습니다. .gitignore 규칙과 사전 커밋 후크.

🔍 실제 시나리오와 전략적 대응을 담은 GIT 면접 질문 모음

1) Git이란 무엇이고, 다른 버전 제어 시스템과 어떻게 다른가요?

후보자에게 기대하는 것: 면접관은 Git의 기본 원리와 중앙 집중식 시스템에 비해 Git이 갖는 장점에 대한 이해도를 평가하고 싶어합니다.

예시 답변: Git은 개발자들이 버전 관리를 할 수 있도록 해주는 분산 버전 관리 시스템입니다. tracGit을 사용하면 코드베이스의 변경 사항을 쉽게 확인하고 효율적으로 협업할 수 있습니다. SVN과 같은 중앙 집중식 시스템과 달리 Git은 모든 개발자가 변경 이력을 포함한 저장소의 전체 복사본을 가질 수 있도록 합니다. 이러한 구조는 오프라인 작업, 빠른 작업 속도, 향상된 브랜칭 및 병합 기능을 지원합니다.

2) git fetch, git pull, git merge의 차이점을 설명해 주시겠습니까?

후보자에게 기대하는 것: 면접관은 일반적인 Git 명령어와 그 목적에 대한 지식을 테스트합니다.

예시 답변: git fetch 원격 저장소에서 새로운 데이터를 다운로드하지만 현재 브랜치에 통합하지는 않습니다. git pull 가져오기를 수행한 후 자동 병합을 수행하여 새로운 커밋을 통합합니다. git merge 업데이트를 가져온 후 한 브랜치의 변경 사항을 다른 브랜치로 수동으로 결합하는 데 사용됩니다.

3) 병합 충돌을 해결해야 했던 상황을 설명해 보세요. 어떻게 처리하셨나요?

후보자에게 기대하는 것: 면접관은 지원자의 갈등 해결 능력과 협업 워크플로 관리 능력을 알고 싶어합니다.

예시 답변: 이전 직장에서는 공유 브랜치에서 자주 작업했는데, 이로 인해 가끔 병합 충돌이 발생했습니다. 충돌이 발생하면 다음과 같이 했습니다. git status 충돌하는 파일을 파악하고 두 버전을 모두 검토하여 어떤 변경 사항을 유지할지 결정했습니다. 파일을 편집하고 테스트한 후, 충돌을 해결된 것으로 표시하고 변경 사항을 커밋했습니다. 또한, 향후 유사한 문제가 발생하지 않도록 지점 관리 관행을 개선하기 위해 팀과 소통했습니다.

4) Git에서 프로젝트 관리를 위해 분기 전략을 어떻게 사용하시나요?

후보자에게 기대하는 것: 면접관은 Git Flow나 트렁크 기반 개발과 같은 구조화된 워크플로를 이해하는지 보고 싶어합니다.

예시 답변: 나는 일반적으로 다음을 포함하는 Git Flow 전략을 사용합니다. main, develop및 기능 브랜치. 기능 브랜치는 새 작업마다 생성되어 병합됩니다. develop 완료 후 병합하기 전에 테스트했습니다. main이 방법은 통제된 통합과 깔끔한 ​​릴리스 주기를 보장합니다.

5) 실수로 민감한 정보를 Git 저장소에 커밋한 경우 어떤 조치를 취해야 합니까?

후보자에게 기대하는 것: 면접관은 보안이나 규정 준수 문제에 효과적으로 대응하는 능력을 평가합니다.

예시 답변: 먼저 다음을 사용하여 민감한 파일을 제거합니다. git rm --cached 그리고 변경 사항을 커밋합니다. 다음으로 다음과 같은 도구를 사용합니다. git filter-branch or BFG Repo-Cleaner 기록에서 정보를 삭제합니다. 마지막으로, 노출된 자격 증명을 교체하고 관련 이해 관계자에게 알려 잠재적 위험을 방지합니다.

6) 여러 개발자가 동시에 커밋하는 경우 코드 일관성을 어떻게 보장합니까?

후보자에게 기대하는 것: 면접관은 협업 환경에서 코드 무결성을 어떻게 유지하는지 알고 싶어합니다.

예시 답변: 이전 직장에서는 모든 커밋이 풀 리퀘스트와 코드 리뷰를 거치도록 하는 정책을 시행했습니다. 자동화된 CI 검사를 통해 테스트 및 검토를 거친 코드만 병합되도록 했습니다. 이러한 접근 방식을 통해 모든 브랜치에서 품질과 일관성을 유지할 수 있었습니다.

7) 이미 공유 브랜치에 푸시된 커밋을 되돌리려면 어떻게 해야 하나요?

후보자에게 기대하는 것: 면접관은 공유 저장소에서 실수를 안전하게 관리하는 방법을 이해하고 있는지 알고 싶어합니다.

예시 답변: 가장 안전한 방법은 다음과 같습니다. git revert <commit_id>, 지정된 커밋의 변경 사항을 취소하는 새 커밋을 생성합니다. 이렇게 하면 프로젝트 히스토리가 유지되고 다른 개발자의 작업을 방해하지 않습니다. git reset역사를 다시 쓰는 것입니다.

8) 다양한 릴리스를 위해 여러 개의 브랜치를 관리해야 했던 때에 대해 말씀해 주세요.

후보자에게 기대하는 것: 면접관은 버전 관리에서 복잡성을 관리하는 능력에 대한 통찰력을 원합니다.

예시 답변: 이전 업무에서는 고객을 위해 여러 릴리스 버전을 유지 관리했습니다. 각 버전마다 별도의 릴리스 브랜치를 사용하고, 체리픽(Cherry-pick) 방식을 사용하여 중요한 수정 사항을 적용했습니다. 이를 통해 최신 버전에서 회귀를 일으키지 않고 업데이트가 일관되게 적용되도록 했습니다.

9) 성능을 최적화하기 위해 많은 기여자가 있는 대규모 저장소를 어떻게 처리하시나요?

후보자에게 기대하는 것: 면접관은 Git을 효과적으로 확장하는 방법에 대한 지식을 평가합니다.

예시 답변: 나는 얕은 복제를 장려합니다.--depth) 더 빠른 접근과 사용을 위해 .gitignore 불필요한 파일을 제외합니다. 또한 오래된 브랜치를 정기적으로 정리하고, 바이너리 애셋에는 Git LFS(대용량 파일 저장소)를 사용합니다. 이러한 단계를 통해 저장소의 효율성과 관리 용이성을 유지합니다.

10) 개발을 방해하는 Git 이슈를 디버깅해야 했던 상황을 설명해 주세요. 어떤 접근 방식을 사용하셨나요?

후보자에게 기대하는 것: 면접관은 지원자의 분석적 사고와 문제 해결 능력을 보고 싶어합니다.

예시 답변: 이전 직책에서 팀원의 브랜치 기록이 잘못된 리베이스로 인해 손상되었습니다. 다음을 사용하여 조사했습니다. git log git reflog 에 trac문제를 해결한 후, 다음 명령어를 사용하여 올바른 커밋을 복원했습니다. git cherry-pick 모든 지점의 로컬 지점이 고정된 원격 버전과 동기화되도록 했습니다. 이를 통해 추가적인 업무 중단을 방지하고 팀 생산성을 유지할 수 있었습니다.

이 게시물을 요약하면 다음과 같습니다.