> For the complete documentation index, see [llms.txt](https://leehyokyun.gitbook.io/openbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://leehyokyun.gitbook.io/openbook/1-2.-git.md).

# 1-2. Git

형상관리 및 git에 대하여

### 1. Git의 3대 아키텍처 구조

* Working Directory: 개발자가 로컬 컴퓨터에서 코드를 추가, 수정, 삭제하는 실제 물리적인 작업 공간이다.
* Index (Staging Area): 커밋(Commit)을 실행하기 전, 변경이 완료된 파일들을 임시로 저장하고 준비시키는 가상 공간이다.
* .git (Repository): 프로젝트의 모든 파일 변경 내역, 커밋 히스토리, 브랜치 정보, 태그 등을 온전히 보관하는 물리 저장소 공간이다.
* 핵심 사상: Git은 단순한 파일 저장을 넘어 Working Directory, Index, Repository의 3가지 영역을 유기적으로 제어하여 파일의 상태를 추적하고 관리하는 고유한 체계다.

### 2. git init의 옵션별 저장소 유형 차이 (Bare)

* 기본 git init: 개발자가 직접 코드를 수정할 수 있는 Working Directory와 형상 관리를 위한 .git 저장소가 함께 생성되는 구조다. 로컬에서 변경 사항을 직접 추적하는 용도로 사용된다.
* git init --bare: 개발자의 직접적인 작업 공간인 Working Directory가 생성되지 않는 특수 저장소다. 오로지 원격 서버(Bare Server) 역할을 수행하기 위해 생성되며, 내부에는 개별 파일 형태가 아닌 objects, refs, HEAD 등 순수한 Git 데이터 구조체만 존재한다. 여러 개발자가 push하고 pull하는 중간 공유 서버 저장소의 표준 역할을 담당한다.

### 3. Repository 이관을 위한 Mirror링 메커니즘

* git clone --mirror 및 git push --mirror: 저장소를 다른 원격지(예: GitLab에서 GitHub로 전체 이동)로 완벽하게 이관할 때 사용되는 옵션이다.
* 일반 clone과의 차이점: 일반 clone은 원격지의 최신 파일들을 가져와 Working Directory에 checkout하는 반면, mirror clone은 작업 디렉토리를 생성하지 않고 원격지의 .git 데이터 자체만을 통째로 복제해 온다.
* 데이터 무결성 보장: HEAD, refs, remote 브랜치, local 브랜치, 태그 정보뿐만 아니라 삭제된 내역까지 원격지와 100% 동일한 상태로 완벽하게 동기화하여 통째로 밀어넣을 수 있다. 파일 충돌이나 checkout 의존성 없이 순수한 형상 관리 히스토리 자체를 안전하게 보존하여 이관하는 최적의 방식이다.

### 4. Git Checkout과 Detached HEAD 상태의 본질

* git checkout의 핵심: 단순히 브랜치를 이동하는 가벼운 명령어가 아니다. 내부의 Working Directory, .git 저장소의 HEAD, Index의 시점을 특정 커밋이나 과거 상태로 되돌리고 맞추는 정밀한 제어 동작이다.
* 브랜치 이동: git checkout develop 명령을 실행하면 현재의 작업 위치를 해당 브랜치로 변경한다.
* 파일 복원: git checkout HEAD file.txt 명령을 내리면 특정 파일의 상태를 마지막 커밋 시점으로 즉시 강제 롤백시킨다.
* Detached HEAD 상태: 브랜치 이름(예: main, develop)을 지정하지 않고, 특정 커밋 ID를 타깃으로 기재하여 git checkout 를 실행할 때 발생한다. HEAD 포인터가 실시간 추적이 가능한 브랜치를 가리키지 못하고, 특정 고정 커밋을 직접 바라보게 되면서 브랜치와의 연결 고리가 끊어진 격리 상태를 뜻한다.

### 5. git merge와 git rebase의 동작 및 결과 차이

* git merge: 분기된 두 브랜치의 히스토리를 그대로 유지하면서 하나로 통합하는 방식이다. feature 브랜치의 독립된 작업 분기 구조가 그래프 상에 선명하게 보존되며, 결합 시점에 두 브랜치의 변경 사항을 병합한 새로운 'Merge Commit(머지 커밋)'이 강제로 생성된다.
* git rebase: 가지가 뻗어나간 feature 브랜치의 부모 커밋 기준점(Base)을 최신 main 브랜치의 종착점으로 강제로 옮겨서 다시 작성하는 기법이다. 이 과정에서 기존 feature 브랜치의 커밋 내역들은 완전히 고아(Garbage) 상태가 되어 폐기되고, 완전히 새로운 커밋 해시(Hasing)를 가진 대체 커밋들이 일렬로 재적용된다.
* 실무 활용 가이드: 히스토리를 깨끗한 일직선 형태로 유지하고자 할 때 유용하며, 특히 Pull Request(PR)를 올리기 전에 난잡하게 쪼개진 무의미한 커밋들(오타 수정, 디버깅용 등)을 하나로 깔끔하게 정리하는 squash 및 fixup 용도로 가장 많이 활용된다. 다만, 이미 원격지에 푸시되어 동료들과 공유 중인 브랜치에 rebase를 적용하면 커밋 해시가 전부 뒤바뀌어 심각한 히스토리 충돌을 유발하므로 주의해야 한다.

### 6. Fast-Forward Merge와 3-Way Merge 조건

* Fast-Forward Merge: 분기된 feature 브랜치가 작업을 진행하는 동안, 베이스가 되는 main 브랜치에 아무런 추가 커밋이 발생하지 않고 뒤처져 있는 상황일 때 발동한다. 이때 merge를 실행하면 새로운 머지 커밋을 만들지 않고, main 브랜치의 포인터를 최전방에 위치한 feature 브랜치의 최신 커밋 위치로 그대로 이동시킨다.
* 3-Way Merge: feature 브랜치가 작업하는 도중 main 브랜치에도 다른 개발자에 의해 서로 다른 새로운 커밋이 누적되어 분기가 명확히 발생했을 때 발동한다. 이 경우에는 두 브랜치의 공통 조상이 되는 커밋(Base Commit), 현재 브랜치의 최신 커밋, 머지 대상 브랜치의 최신 커밋이라는 총 3가지 기준점을 동시에 비교 및 연산하여 병합을 수행하며, 그 결과물로 반드시 독립적인 머지 커밋이 생성된다.

### 7. Cloud 환경 내 GitLab 구축 시 필수 인프라 요소

* DNS (도메인 네임 시스템): 외부 사용자들이 gitlab.company.com과 같은 도메인 주소 체계로 안정적으로 접근할 수 있도록 경로를 연결해 주는 Route53 기반의 DNS 설정이 필수적이다.
* Load Balancer (부하 분산 장치): 대규모 인입 트래픽을 안전하게 분산 처리하기 위한 ALB(Application Load Balancer) 혹은 NLB(Network Load Balancer)의 구축이 수반되어야 한다. 외부 통신의 보안을 위해 HTTPS 통신을 일괄적으로 복호


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://leehyokyun.gitbook.io/openbook/1-2.-git.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.