Dev./Git

[Git] merge 진행 과정

limitation01 2025. 11. 30. 09:25

merge를 이해하기

Git에서 협업 할 때 내가 가장 중요하다고 생각하는 것은

내 작업 브랜치는 어떤 dev를 기준으로 만들어졌는가?

이다. dev는 공용 개발 브랜치이며 모든 feature 브랜치는 dev의 특정 시점에서 분기된다. 문제는 dev는 계속 변한다는 것인데 본질을 이해하고 넘어가면 실수할 일이 줄어든다.

그래서 merge의 본질은 내 브랜치를 최신 dev 기준으로 다시 맞추는 과정이라고 생각한다.

merge의 기준점은 항상 dev

  1. dev를 항상 최신으로 만든 뒤
  2. 작업 브랜치에 dev를 merge

fetch와 pull의 역할

git fetch

형상 확인용, 정보 동기화용

git fetch origin
  • 원격 저장소의 최신 상태를 복사만 해옴
  • origin/dev가 업데이트됨
  • 내 로컬 브랜치에는 아무 변화 없음

 

git pull

물리적으로 최신화

git pull origin dev

pull은 두 단계를 포함하고 있다.

git fetch origin
git merge origin/dev
  • 원격 dev의 변경사항을
  • 현재 브랜치에 실제로 반영

merge 과정

1. 로컬 dev로 이동

git switch dev

2. 원격 상태 가져오기

git fetch origin

3. 로컬 dev를 최신화

git merge origin/dev

여기까지 오면 로컬 dev와 원격 dev의 형상이 일치하게된다.

4. 작업 브랜치 이동

5.dev merge

git merge dev
  • 내 작업 브랜치에 최신 dev에서 변경된 모든 내용을 합치겠다
  • merge의 대상은 origin/dev가 아니라 이미 최신이기 때문에 dev여야 한다

작업 브랜치에서는 fetch를 할 필요가 없을까?

그렇다.

fetch는 원격 상태를 가져오는건데 이미 dev는 최신이기 때문에 또 하게되면 중복, dev는 merge만 진행한다.


내가 실수했던 포인트

작업 브랜치에서 바로 pull origin dev 하면 안되나?

기술적으로 틀리진 않았음 그러나 

위에서 언급햇던 내용대로 해당 명령은

1. git fetch origin
2. git merge origin/dev   // ← 기준

다음과 같이 원격 브랜치를 지금 작업 브랜치에 바로 머지 시키겠다는 이야기로 git이 해석한다.

발생할 수 있는 문제 - 관리 포인트가 흐려짐

  1. 기준 브랜치가 사라진다.
    • 내가 위에서 중요하다고 생각했던 기준에 위배가 된다. 그냥 내 작업 브랜치에서 명령하면 로컬 dev를 거치지 않아 이 작업브랜치는 어떤 시점의 dev를 기준으로 하는지 알기가 힘들다.
  2. 로컬 dev의 상태 보장이 되지 않는다.
    • 예를 들어 내가 겪었던 상황으로 보면
    • 나: origin/dev에 커밋 push
    • 팀원 A: 작업 브랜치에서 git pull origin dev
    • A 로컬 dev는 여전히 예전 상태
    • 작업 브랜치는 최신 dev 반영되었지만 로컬 dev는 맞지 않는 상황
  3.  히스토리 추적이 어려워진다.
    • dev에서 충돌이 났는지, 작업브랜치에서 dev를 끌고 온건지, 어떤 시점의 dev인지 추적이 어려워진다

'Dev. > Git' 카테고리의 다른 글

[Git] git switch와 checkout 차이  (0) 2025.11.26
[Git] README 파일에 이미지 올리기  (0) 2025.10.30
[Git] git cherry-pick 특정 커밋 가져오기  (0) 2025.10.18