FrontEnd Develop

Github 이해하기 #1. 두 사람의 브랜치 병합 협업

Frisbeen 2025. 5. 19. 18:35

 

이번 글에서는 Git 협업에서 자주 마주하게 되는 브랜치 병합 과정을, 두 명의 개발자 Jessica와 John의 사례를 통해 단계별로 설명합니다. 이 글은 Git의 기본 구조를 이해하고자 하는 분에게 적합합니다.

상황 가정

  • John과 Jessica는 동일한 원격 저장소(origin)에서 각각 작업을 진행합니다.
  • 둘 다 master 브랜치를 기준으로 작업을 시작했으며, 각자의 로컬에서 feature를 개발한 후, 이를 다시 master로 병합하려고 합니다.

1.  원격 저장소를 클론

두 사람은 각각 다음과 같이 원격 저장소를 클론하여 작업을 시작합니다:

$ git clone git@host:simplegit.git

이때 로컬에는 다음과 같은 브랜치가 생성됩니다:

  • master (로컬 작업 브랜치)
  • origin/master (원격 저장소의 master를 가리키는 로컬 추적 포인터)

master 브랜치가 실제 주가지수라면

origin/master는 브랜치가 아닌 그 실제 주가지수를 추종하는 ETF라고 이해하면 쉽습니다.

2. 각자의 작업

John:

  • master 브랜치에서 코드를 수정하고 커밋합니다.
  • 커밋 ID: 738ee (예시)

Jessica:

  • 별도 브랜치 issue54에서 작업하고 3개의 커밋을 완료했다고 가정합니다.
  • 이후 master로 병합할 준비를 합니다.

3. Jessica가 먼저 push

Jessica는 origin/master에 아무 변경사항이 없는 상태에서 자신의 issue54 브랜치를 병합한 결과를 origin에 push합니다:

$ git checkout master
$ git merge issue54
$ git push origin master

origin/master는 이제 Jessica의 변경사항을 포함하게 됩니다.

4. John의 push 실패

John도 자신의 master에서 작업을 완료하고 push를 시도하지만 다음과 같은 오류가 발생합니다:

! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'origin'

이는 Jessica가 먼저 origin/master를 업데이트했기 때문입니다. John의 로컬 master는 origin/master보다 뒤처진 상태입니다.

따라서 Jessica의 작업을 병합하지 않으면 Push를 할 수가 없겠습니다. (fast-forward) 상태가 아니니까요!

웬만하면, Fast-forward 상태가 아니면 Push가 거부됩니다. (깃허브 정책)

5. John의 fetch와 병합

John은 다음과 같이 Jessica의 변경사항을 로컬로 가져옵니다:

 

Push를 하기 위해선 변경사항을 가져와야하니까요!

$ git fetch origin

이제 origin/master는 Jessica의 최신 커밋(fbff5)을 가리키게 됩니다.

 

John은 자신의 master 브랜치에서 병합을 진행합니다:

$ git merge origin/master

병합 커밋이 하나 생성되며, 로컬 master는 Jessica와 John의 작업을 모두 포함하게 됩니다.

이제야, John의 로컬은 Fast-Forward git 상태가 됩니다.

6. John의 push 성공

병합 이후 John은 다음과 같이 push할 수 있습니다:

$ git push origin master

이제 origin/master는 병합된 커밋을 반영한 상태가 됩니다.

7. 핵심 개념 정리

master 로컬에서 실제 작업 중인 브랜치
origin/master 원격 저장소의 master 브랜치를 로컬에서 추적하는 읽기 전용 포인터
  • git push origin master는 로컬 master의 상태를 원격 저장소의 master 브랜치에 반영합니다.
  • origin/master에 직접 push하지는 않습니다. 이는 추적용 포인터일 뿐이기 때문입니다. 
  • fetch는 원격 브랜치 상태(origin/master)를 갱신만 할 뿐, 로컬 작업 브랜치에는 영향을 주지 않습니다.

마무리

이와 같은 협업 흐름은 실제 팀 프로젝트에서 자주 발생합니다.

중요한 것은 항상 최신 origin/master 상태를 기준으로 작업을 병합하고 push하는 것입니다.

이를 통해 충돌을 최소화하고 협업을 원활히 유지할 수 있습니다.