Git / 협업 면접 질문

Git은 크게 Working Directory, Staging Area, Repository 세 부분으로 구성됩니다.

Working Directory는 실제 파일들을 수정하고 작업하는 공간입니다. 여기서 변경된 파일들은 바로 Repository에 반영되지 않습니다.

Staging Area는 Working Directory에서 변경된 파일 중 Repository에 반영하고 싶은 변경 사항들을 모아두는 곳입니다. git add 명령어를 통해 변경 사항을 Staging Area에 추가할 수 있습니다. Staging Area는 Index라고도 불립니다.

Repository는 모든 버전 관리 정보와 파일들의 변경 이력을 저장하는 데이터베이스입니다. git commit 명령어를 통해 Staging Area에 있는 변경 사항들을 Repository에 저장합니다. 커밋을 할 때마다 변경 이력이 기록되고, HEAD는 현재 체크아웃된 브랜치의 최신 커밋을 가리킵니다.

git stash는 현재 작업 디렉토리와 Staging Area(Index)의 변경 사항을 임시로 저장하는 명령어입니다. 아직 완료되지 않은 작업을 커밋하지 않고 다른 브랜치로 전환해야 할 때 유용하게 사용됩니다.

stash를 사용하면 워킹 디렉토리를 깨끗하게 만들 수 있습니다. git stash 명령어로 변경 사항을 저장하고, git stash list로 저장된 stash 목록을 확인할 수 있습니다.

저장된 stash는 git stash pop 또는 git stash apply 명령어로 복구할 수 있습니다. pop은 stash를 적용하고 목록에서 제거하며, apply는 stash를 적용하되 목록에 유지합니다. 더 이상 필요 없는 stash는 git stash drop 명령어로 삭제할 수 있습니다.

예를 들어, 급하게 다른 브랜치에서 수정해야 할 사항이 생겼을 때, 현재 작업 내용을 stash에 저장하고 해당 브랜치로 이동하여 작업을 완료한 후, 다시 원래 브랜치로 돌아와 stash를 복구하여 작업을 이어나갈 수 있습니다.

좋은 커밋 메시지는 협업 효율성을 높이고 코드 변경 이력을 효과적으로 관리하는 데 필수적입니다. 저는 다음과 같은 방식으로 커밋 메시지를 작성하려고 노력합니다.

먼저, Conventional Commits 규칙을 따릅니다. Conventional Commits는 커밋 메시지에 일관된 구조를 부여하여 자동화된 도구들이 변경 사항을 쉽게 파악하고 Changelog를 생성하도록 돕습니다.

커밋 메시지는 "타입(type): 스코프(scope) - 제목(subject)" 형태로 작성합니다. 타입은 feat, fix, docs, refactor, test 등을 사용하여 변경 사항의 종류를 명확히 나타냅니다. 스코프는 변경된 코드의 특정 영역을 나타내고, 제목은 변경 사항을 간결하게 설명합니다.

예를 들어, "feat(user): 사용자 프로필 이미지 업로드 기능 추가" 와 같이 작성할 수 있습니다.

본문(body)에는 변경 사항에 대한 자세한 설명과 이유를 명시하고, 필요하다면 꼬리말(footer)에 관련 이슈 번호나 Breaking Changes 정보를 추가합니다. 이렇게 작성된 커밋 메시지는 코드 리뷰를 돕고, 추후 코드 변경 이력을 추적하는 데 유용합니다.

.gitignore 파일은 Git이 추적하지 않아야 할 파일이나 디렉토리를 명시하는 역할을 합니다. 예를 들어, 빌드 결과물, 로그 파일, IDE 설정 파일 등을 저장소에 포함시키지 않도록 할 수 있습니다.

작성 방법은 간단합니다. 각 줄에 제외할 파일 또는 디렉토리의 패턴을 적습니다. 와일드카드(*)를 사용하거나, 특정 디렉토리 안의 파일만 제외하는 등 다양한 패턴을 활용할 수 있습니다.

이미 추적 중인 파일을 .gitignore에 추가해도 Git은 계속 추적합니다. 이 경우 git rm --cached <파일> 명령어로 추적을 중단하고 다시 커밋해야 합니다.

전역적으로 무시할 파일은 git config --global core.excludesfile ~/.gitignore_global 명령어를 통해 설정할 수 있습니다. 이렇게 하면 모든 Git 저장소에 공통적으로 적용됩니다.

면접관님, fork와 clone은 모두 Git 저장소를 복사하는 명령어이지만, 목적과 대상에 차이가 있습니다.

Fork는 주로 GitHub와 같은 원격 저장소에서 사용되며, 다른 사람의 저장소를 제 계정으로 복사해오는 것을 의미합니다. 마치 개인적인 복사본을 만드는 것과 같습니다. 반면, clone은 원격 저장소 또는 로컬 저장소의 내용을 제 컴퓨터로 가져오는 명령어입니다.

오픈소스 기여 시 fork 기반 워크플로우는 다음과 같습니다. 먼저 기여하고 싶은 오픈소스 프로젝트를 fork하여 제 GitHub 계정에 복사본을 만듭니다. 그 다음, 제 계정의 저장소를 clone하여 로컬 환경에서 작업합니다. 변경 사항을 적용하고 커밋한 후, 제 저장소에 push합니다. 마지막으로, 원본 프로젝트 저장소에 Pull Request(PR)를 보내 변경 사항을 제안합니다. 이때, 원본 저장소를 upstream으로 추가하여 최신 변경 사항을 동기화하는 것이 중요합니다.

git remote add upstream [원본 저장소 URL]
git fetch upstream
git merge upstream/main

이러한 과정을 통해 오픈소스 프로젝트에 안전하고 효율적으로 기여할 수 있습니다.

Git의 객체 모델에서 각 객체는 데이터를 효율적으로 관리하기 위해 역할을 분담합니다.

먼저 blob 객체는 실제 파일의 내용을 저장합니다. 파일이 변경될 때마다 새로운 blob 객체가 생성되며, 파일의 내용 자체를 해시값으로 식별합니다.

tree 객체는 디렉터리 구조를 나타냅니다. 디렉터리 내의 파일(blob 객체)과 하위 디렉터리(다른 tree 객체)에 대한 정보를 담고 있으며, 각 항목은 이름과 해당 객체의 해시값으로 구성됩니다.

마지막으로 commit 객체는 특정 시점의 스냅샷 메타데이터를 저장합니다. 이전 커밋에 대한 참조, 작성자 정보, 커밋 메시지, 그리고 해당 커밋이 가리키는 루트 tree 객체의 해시값 등을 포함하여 프로젝트의 변경 이력을 기록합니다.

Git에서 blob 객체는 파일의 실제 내용을 저장하는 역할을 합니다. 파일 이름은 blob 객체에 직접 저장되지 않고, 대신 tree 객체에 기록됩니다.

tree 객체는 디렉토리 구조를 표현하는 객체라고 생각하시면 됩니다. 각 tree 객체는 여러 개의 항목을 포함할 수 있는데, 각 항목은 파일 이름과 해당 파일의 blob 객체 해시값, 그리고 파일의 권한 정보 등을 연결합니다.

결론적으로, 파일 이름은 tree 객체 내에서 해당 파일의 내용(blob 객체)과 연결되어 관리됩니다. 그리고 이 tree 객체는 최종적으로 커밋 객체에 의해 참조되어 프로젝트의 특정 시점 상태를 나타내게 됩니다.

Git에서 Merge, Rebase, Squash는 브랜치를 합치는 방법이지만, 각각 다른 특징과 사용 시나리오를 가지고 있습니다.

Merge는 브랜치들을 합칠 때 Merge Commit을 생성하여 이력을 남깁니다. 히스토리를 중요하게 생각하고, 브랜치 작업 내역을 보존하고 싶을 때 사용합니다. 예를 들어, 기능 개발 브랜치를 main 브랜치에 합칠 때 사용할 수 있습니다.

Rebase는 브랜치의 시작점을 옮겨서 커밋 히스토리를 선형으로 만듭니다. 깔끔한 히스토리를 유지하고 싶을 때 유용하지만, 이미 공유된 브랜치에 Rebase를 하면 문제가 발생할 수 있으므로 주의해야 합니다. 특히 Force Push가 필요할 수 있습니다.

Squash는 여러 커밋을 하나의 커밋으로 합치는 기능입니다. 불필요하게 많은 커밋을 정리하거나, 의미있는 단위로 커밋을 묶을 때 사용합니다. 예를 들어, 기능 개발 브랜치에서 여러 개의 작은 커밋들을 하나의 완성된 기능 커밋으로 만들 수 있습니다. Interactive Rebase를 통해 Squash를 수행할 수 있습니다.

Git Flow는 릴리스 주기가 긴 프로젝트에 적합한 브랜치 전략입니다. main, develop, feature, release, hotfix 브랜치를 사용하죠. develop 브랜치에서 기능 개발을 위한 feature 브랜치를 분기하고, 릴리스 준비 시 release 브랜치를 생성합니다. 핫픽스는 main 브랜치에서 분기하여 긴급 수정에 대응합니다.

반면 GitHub Flow는 main 브랜치를 중심으로 모든 변경 사항을 Pull Request(PR)를 통해 통합하는 방식입니다. 기능 개발은 main 브랜치에서 바로 분기한 브랜치에서 진행하고, PR을 통해 코드 리뷰와 테스트를 거친 후 main 브랜치에 병합됩니다.

Git Flow는 복잡하지만 릴리스 관리가 용이하고, GitHub Flow는 단순하지만 지속적인 배포에 적합합니다. Git Flow는 릴리스 브랜치 관리에 overhead가 있고, GitHub Flow는 빠른 피드백과 통합이 장점입니다. 프로젝트의 특성과 릴리스 주기에 따라 적절한 전략을 선택하는 것이 중요합니다.

세 명령어 모두 변경 사항을 되돌리는 데 사용되지만, 방식에 차이가 있습니다.

git reset은 HEAD가 가리키는 커밋을 변경하여 히스토리를 조작합니다. --soft, --mixed, --hard 옵션에 따라 HEAD, 인덱스, 작업 트리를 초기화하는 범위가 달라집니다. 히스토리를 완전히 삭제할 수 있기 때문에 공개된 브랜치에서는 사용에 주의해야 합니다.

git revert는 특정 커밋의 변경 사항을 취소하는 새로운 커밋을 생성합니다. 히스토리를 변경하지 않고 되돌리기 때문에 안전하게 사용할 수 있습니다.

git restore는 작업 트리의 파일을 특정 시점의 상태로 되돌립니다. 인덱스나 HEAD의 내용을 사용하여 파일을 복원하며, 스테이징 영역이나 작업 디렉토리의 변경 사항을 되돌릴 때 유용합니다.

git cherry-pick은 특정 브랜치의 커밋 하나를 선택해서 현재 브랜치에 적용하는 명령어입니다. 쉽게 말해, "체리처럼 콕 찍어서 원하는 커밋만 가져온다"고 생각하면 됩니다.

주로 핫픽스 브랜치에서 수정된 내용을 빠르게 메인 브랜치에 적용해야 할 때, 또는 특정 기능 개발 브랜치의 커밋을 다른 브랜치에 적용하고 싶을 때 사용합니다. 예를 들어, git cherry-pick <커밋 해시> 명령어를 사용하면 해당 커밋이 현재 브랜치에 적용됩니다.

다만, cherry-pick을 너무 자주 사용하면 커밋 이력이 복잡해질 수 있고, 동일한 변경 사항이 여러 곳에 존재하게 되어 관리하기 어려워질 수 있습니다. 또한, cherry-pick 과정에서 충돌이 발생할 수 있는데, 이 경우에는 일반적인 병합 충돌 해결과 동일하게 충돌을 해결하고 커밋해야 합니다.

Pull Request(PR) 프로세스에서 코드 리뷰를 효과적으로 진행하는 것은 코드 품질을 높이고 팀원 간 지식을 공유하는 데 매우 중요합니다.

먼저, 리뷰어는 PR의 목적과 변경 사항을 명확히 이해해야 합니다. PR은 작고 집중된 단위로 관리하는 것이 좋습니다. 그래야 리뷰어가 변경 사항을 쉽게 파악하고 집중할 수 있습니다.

건설적인 피드백은 구체적이고 실행 가능해야 합니다. 단순히 "이건 틀렸어"가 아니라, "이 부분은 이렇게 개선하면 가독성이 더 좋아질 것 같습니다"와 같이 제안하는 방식이 좋습니다. 코드 컨벤션 준수 여부, 잠재적인 버그, 성능 개선점 등을 중점적으로 확인합니다.

리뷰 체크리스트를 활용하는 것도 좋은 방법입니다. 이를 통해 중요한 부분을 놓치지 않고 일관성 있는 리뷰를 진행할 수 있습니다. 또한, 자동화 도구를 활용하여 스타일 검사나 간단한 테스트를 미리 통과하도록 하면 리뷰어는 더 핵심적인 로직에 집중할 수 있습니다.

마지막으로, PR 작성자는 리뷰어의 피드백을 겸허히 수용하고 적극적으로 반영하는 자세가 필요합니다. 이를 통해 PR은 단순한 코드 검토를 넘어 팀 전체의 성장 기회가 됩니다.

Git에서 충돌은 주로 여러 브랜치에서 같은 파일의 같은 부분을 동시에 수정하고, 이 변경사항들을 병합(merge)하려고 할 때 발생합니다. Git은 자동으로 변경사항을 합칠 수 없을 때 충돌을 일으킵니다.

충돌이 발생하면 해당 파일에 특별한 마커(<<<< HEAD, ====, >>>> branch_name)가 표시됩니다. HEAD는 현재 브랜치의 변경사항을, branch_name은 병합하려는 브랜치의 변경사항을 나타냅니다.

충돌을 해결하는 방법은 다음과 같습니다. 먼저, 충돌 마커를 확인하고 어떤 변경사항을 유지할지, 혹은 두 변경사항을 어떻게 조합할지 결정합니다. 필요한 부분을 직접 수정하여 코드를 올바르게 만듭니다. 충돌 마커를 모두 제거하고, 수정한 파일을 git add로 스테이징한 후 git commit으로 커밋합니다. 이렇게 하면 충돌이 해결되고 병합이 완료됩니다.

git 태그는 특정 커밋을 가리키는 포인터로, 주로 릴리스 버전을 표시하는 데 사용됩니다. Lightweight 태그와 Annotated 태그가 있는데, Annotated 태그는 작성자, 메시지, 날짜 등의 추가 정보를 포함하여 더 자세한 기록을 남길 수 있습니다.

릴리스 관리는 보통 Semantic Versioning(SemVer) 규칙을 따릅니다. SemVer는 MAJOR.MINOR.PATCH 형식으로 버전을 관리하며, 각 숫자는 API 호환성이 깨지는 변경, 새로운 기능 추가, 버그 수정 등을 의미합니다.

GitHub Release는 태그를 기반으로 릴리스를 생성하고 관리하는 기능입니다. 릴리스 노트를 작성하여 변경 사항을 사용자에게 알리고, 바이너리 파일 등을 첨부하여 배포할 수 있습니다. GitFlow 전략을 사용한다면, release 브랜치를 사용하여 릴리스 준비를 하고, 릴리스 태깅 후 master와 develop 브랜치에 병합하는 방식으로 관리할 수 있습니다.

git bisect는 코드에 버그가 발생했을 때, 어떤 커밋에서 해당 버그가 처음 나타났는지 효율적으로 찾아주는 강력한 도구입니다. 이진 탐색 알고리즘을 사용하여 커밋 히스토리를 절반씩 줄여나가면서 문제의 원인이 되는 커밋을 빠르게 찾아냅니다.

먼저 git bisect start 명령으로 bisect를 시작하고, 버그가 없는 마지막 커밋(good)과 버그가 있는 커밋(bad)을 각각 git bisect good [커밋 해시]와 git bisect bad [커밋 해시] 명령으로 지정합니다.

그러면 git은 중간 커밋을 체크아웃하고, 해당 커밋에서 버그가 있는지 확인합니다. 버그가 있다면 git bisect bad, 없다면 git bisect good 명령을 실행합니다. 이 과정을 반복하면 문제 커밋 범위를 좁혀나가 최종적으로 원인 커밋을 찾아낼 수 있습니다.

git bisect run [테스트 스크립트] 명령을 사용하면 이 과정을 자동화할 수도 있습니다. 테스트 스크립트는 각 커밋에서 자동으로 실행되어 버그 유무를 판단하고, git bisect는 스크립트 결과를 기반으로 다음 커밋을 체크아웃합니다. 원인 커밋을 찾으면 git bisect reset 명령으로 bisect를 종료합니다.

면접관님, 모노레포와 멀티레포는 코드 관리 방식의 차이입니다. 모노레포는 하나의 저장소에 모든 프로젝트 코드를 담는 방식이고, 멀티레포는 각 프로젝트마다 별도의 저장소를 사용하는 방식입니다.

모노레포의 장점은 코드 공유와 재사용이 용이하고, 의존성 관리가 편리하며, 전체 프로젝트에 대한 가시성이 높다는 점입니다. 단점으로는 저장소 크기가 커지고, 빌드 및 테스트 시간이 길어질 수 있으며, 특정 부분만 수정해도 전체 빌드를 해야 할 수도 있다는 점입니다. Turborepo나 Nx 같은 도구를 사용하면 이러한 단점을 어느 정도 해소할 수 있습니다.

반면, 멀티레포는 각 프로젝트가 독립적이어서 빌드 및 테스트 속도가 빠르고, 권한 관리가 용이하다는 장점이 있습니다. 하지만 코드 공유가 어렵고, 의존성 관리가 복잡해지며, 프로젝트 간 변경 사항 추적이 어렵다는 단점이 있습니다.

어떤 방식을 선택할지는 프로젝트의 규모, 팀 구성, 개발 문화 등을 고려하여 결정해야 합니다.

Trunk-based Development는 모든 개발자가 'trunk'라는 단일 메인 브랜치에 직접 또는 매우 짧은 수명 주기의 피처 브랜치를 통해 자주 커밋하는 개발 방식입니다. 이를 통해 지속적인 통합(CI)을 극대화하고, 작은 단위의 변경 사항을 빠르게 배포할 수 있습니다.

Git Flow와 가장 큰 차이점은 브랜치 전략입니다. Git Flow는 develop, feature, release, hotfix 등 여러 개의 영구적인 브랜치를 사용하여 복잡한 릴리스 관리를 하지만, Trunk-based Development는 'trunk' 브랜치 하나에 집중합니다. 미완성 기능은 Feature Flag(또는 Feature Toggle)를 사용하여 'trunk'에 병합하더라도 사용자에게 노출되지 않도록 관리합니다. 이 방식은 배포 빈도를 높이고 통합 문제를 조기에 발견하는 데 유리합니다.

GitHub Actions를 이용한 CI/CD 파이프라인은 YAML 파일로 정의된 Workflow를 통해 구성됩니다. Workflow는 특정 이벤트(push, pull request 등)에 의해 트리거될 수 있습니다.

Workflow는 하나 이상의 Job으로 구성되고, 각 Job은 실행될 Step들의 집합입니다. 각 Step은 Action을 사용하여 정의됩니다. Action은 미리 만들어진 재사용 가능한 코드 조각으로, 테스트 실행, 빌드, 배포 등 다양한 작업을 수행할 수 있습니다.

예를 들어, push 이벤트 발생 시 테스트를 자동화하고, 테스트 통과 후 Docker 이미지를 빌드하여 배포하는 파이프라인을 구성할 수 있습니다. 테스트 결과나 빌드된 이미지는 Artifact로 저장하여 다음 Job에서 사용할 수 있도록 합니다. YAML 파일에서 이러한 모든 단계를 정의하고, GitHub Actions가 이를 자동으로 실행합니다.

Git의 객체 데이터베이스는 blob, tree, commit 세 가지 주요 객체로 구성됩니다.

blob 객체는 파일의 실제 내용을 저장합니다. 파일 내용의 SHA-1(또는 SHA-256) 해시 값을 고유 식별자로 사용하며, 내용이 같으면 해시 값도 같아집니다.

tree 객체는 디렉터리 구조를 나타냅니다. 각 tree 객체는 해당 디렉터리에 포함된 파일(blob 객체)과 하위 디렉터리(다른 tree 객체)의 목록을 저장합니다. 여기서 각 항목은 파일 이름과 해당 blob 또는 tree 객체의 해시 값을 참조합니다.

commit 객체는 특정 시점의 스냅샷을 나타냅니다. 각 commit 객체는 부모 commit 객체(들), 작성자 정보, 커밋 메시지, 그리고 해당 커밋 시점의 루트 tree 객체의 해시 값을 참조합니다.

동일한 내용의 파일이 여러 디렉터리에 존재하더라도, blob 객체는 파일 내용이 동일하면 단 하나의 객체만 생성됩니다. 즉, 내용이 같은 파일은 모두 동일한 blob 객체를 참조하게 되어 저장 공간을 효율적으로 사용합니다. tree 객체는 각 디렉터리 구조에 맞게 해당 blob 객체를 참조하는 방식으로 관리됩니다.

git add를 실행하면 Git은 먼저 작업 디렉터리의 변경된 파일을 스캔합니다. 각 파일의 내용을 읽어 SHA-1 해시값을 계산하고, 이 해시값과 파일 경로를 조합하여 고유한 blob 객체를 생성합니다. 이 blob 객체는 파일 내용의 스냅샷이라고 생각하면 됩니다.

이후, git add는 이 blob 객체의 정보(해시값, 파일 경로, 모드 등)를 .git/index 파일, 즉 인덱스에 기록합니다. 인덱스는 단순히 파일 목록이 아니라, 다음 커밋의 내용을 미리 준비해두는 스테이징 영역이자 캐시 역할을 합니다.

Git은 작업 디렉터리, 인덱스, 그리고 마지막 커밋의 트리 객체를 비교하여 변경 사항을 추적합니다. 작업 디렉터리의 파일은 실제 파일 시스템에 존재하며, 인덱스는 스테이징된 파일들의 상태를 나타냅니다. 마지막 커밋의 트리 객체는 이전 커밋 시점의 파일 구조와 내용을 담고 있습니다. Git은 이 세 가지를 비교하여 어떤 파일이 새로 추가되었는지, 수정되었는지, 삭제되었는지를 파악하고, 이를 바탕으로 다음 커밋을 준비합니다.

커밋 해시는 해당 커밋을 구성하는 여러 정보들의 해시값입니다. 구체적으로는 커밋이 가리키는 트리 객체의 해시, 부모 커밋들의 해시, 작성자 이름, 이메일, 커밋 시간 등의 메타데이터, 그리고 커밋 메시지가 모두 입력으로 사용됩니다.

커밋 메시지나 작성자만 다르고 트리 내용이 동일한 두 커밋이 서로 다른 해시를 갖는 이유는 바로 이 메타데이터와 커밋 메시지가 해시 계산에 포함되기 때문입니다. 트리 내용이 같더라도 커밋을 만든 사람이나 시점, 혹은 남긴 설명이 다르다면 이는 분명히 다른 커밋으로 간주되어야 합니다.

이러한 특성은 히스토리 무결성에 매우 중요합니다. 각 커밋은 고유한 해시를 가지며, 이 해시는 해당 커밋의 내용뿐만 아니라 그 이전 커밋들의 정보까지 연쇄적으로 반영합니다. 만약 누군가 과거의 커밋 내용을 조금이라도 변경한다면, 해당 커밋의 해시는 물론이고 그 이후의 모든 커밋 해시가 달라지게 됩니다. 따라서 Git은 이러한 해시 체인을 통해 히스토리의 변조 여부를 쉽게 감지할 수 있으며, 이는 코드의 신뢰성과 안정성을 보장하는 핵심 메커니즘입니다.