What Happen When Pull Event On Bare

1 분 소요

Overview


클라이언트에서 pull event 가 발생했을때의 흐름을 설명한다.
클라이언트에서 git pull 명령이 실행되면, 서버에서는 Fetch 요청에 응답하는 과정만 담당한다.
이때 서버는 읽기 중심의 동작(read only)을 수행하며, 실제 Merge나 Rebase 등의 작업은 클라이언트 측에서 진행된다.

Key Terms Explained


  • Pack: Git 객체를 효율적으로 저장하기위한 압축 파일 형식으로, .pack 파일과 인덱스역할을 하는.idx 파일로 구성된다.
  • Bare Repository: .git 폴더만 존재하며, 작업 디렉터리(working tree)가 없는 저장소 형태로, 서버에서 원격 저장소로 사용된다.
  • git-upload-pack: 클라이언트의 Pull(혹은 Fetch) 요청을 처리하는 읽기 전용 엔드포인트
  • git-receive-pack: 클라이언트의 Push 요청을 처리하는 쓰기 전용 엔드포인트

Flow


Git 클라이언트가 git pull 수행시 서버에서는 fetch 요청에 응답하는 과정만 담당하며, 읽기 중심의 작업이 진행됨

sequenceDiagram
    autonumber
    participant C as Client (git pull)
    participant G as Git Server (JGit GitServlet)
    participant R as Bare Repo (.git) (FS)

    Note over C: git pull = fetch + (merge/rebase)<br/>서버는 fetch 단계만 처리

    C->>G: GET /<repo>.git/info/refs?service=git-upload-pack
    G->>R: refs 조회 + capability 확인
    R-->>G: refs 목록
    G-->>C: refs + capabilities (Discovery 단계)

    C->>G: POST /<repo>.git/git-upload-pack<br/>(want/have, shallow 옵션 등)
    G->>R: 객체 그래프 탐색 및 필요한 객체 계산
    Note over G,R: thin-pack / ofs-delta / bitmap index 등 최적화 수행

    G-->>C: side-band 스트림 시작<br/>ch1: pack 데이터<br/>ch2: 진행률<br/>ch3: 에러
    Note over C: packfile 수신 (.pack + .idx)

    C->>C: 로컬 객체 DB 갱신 및 인덱스 작성
    C->>C: (pull의 후반) merge 또는 rebase 수행

Flow Detail


1. Discovery

원격 상태 파악과 필요 데이터 판단까지의 전반 흐름

1-1. Advertise-Refs

클라이언트가 git pull 수행 시, 서버의 git-upload-pack 엔드포인트로 refs 정보를 요청

  • 클라이언트 요청
    GET /<repo>.git/info/refs?service=git-upload-pack
    
  • 서버 응답 항목
    • HEAD
    • refs/heads/* (브랜치 정보)
    • refs/tags/* (태그 정보)
    • capabilities 목록
1-2. Negotiation (wants/haves 결정)

서버 광고(refs)와 로컬 상태를 대조해 필요한 객체 산출 wants, have 산출,

  • 요청 전송
    POST /<repo>.git/git-upload-pack
    
  • 요청 구성: want, have, shallow
  • 목적: 공통 조상 확인, 부족한 객체만 선별 요청

2. Packfile 송수신

필요 객체에 대한 팩 생성, 전송, 수신 및 적용 흐름(클라이언트는 위 Negotiation 단계에서 받은 refs 정보를 바탕으로, 서버가 가지고 있지만 로컬에는 없는 커밋들을 요청한다.) 요청에는 want, have, shallow 옵션 등이 포함됨

2-1. 서버 → 클라이언트 전송 (side-band)
  • side-band 스트림: ch1(pack 데이터), ch2(진행률), ch3(에러)
  • thin-pack, ofs-delta, bitmap index 등 최적화 적용 가능
2-2. 클라이언트 수신·적용
  • .pack 수신 및 .idx 인덱스 생성
  • 로컬 객체 DB 반영

3. Merge or Rebase

Fetch 완료 후 로컬 브랜치 반영 단계

Trace


TL;DR

Conclusion


  1. 서버는 refs 정보를 제공
  2. 클라이언트는 이를 기반으로 필요한 객체만 요청함.
  3. 서버는 Pack 파일을 생성 및 응답해 효율적 동기화를 지원
  4. 최종적으로 클라이언트는 Pack 파일을 받아 Merge나 Rebase를 수행함



카테고리:

업데이트: