본문 바로가기
VCS/GitHub

Git 병합(Merge) 종류

by Jinger 2025. 2. 19.

서론

   Git에서 여러 브랜치를 병합하는 방식은 프로젝트의 형상 관리에 중요한 영향을 미친다. 각 병합 방식의 특징과 적절한 사용 사례를 이해하면 보다 효율적인 협업과 코드 관리가 가능하다.


1. Fast-Forward Merge

   Fast-Forward Merge는 대상 브랜치가 최신 상태이며, 병합할 브랜치가 대상 브랜치의 최신 커밋 이후에만 변경 사항이 있는 경우 사용할 수 있다. 새로운 병합 커밋을 생성하지 않고 브랜치를 앞으로 이동시키는 방식이다.

장점

  • 병합 커밋이 생성되지 않아 Git 히스토리가 깔끔함
  • 변경 사항을 단순히 이어붙이는 방식으로 속도가 빠름

단점

  • 변경 이력이 단순해 보여 협업 시 어떤 브랜치에서 작업했는지 명확히 알기 어려울 수 있음
  • 브랜치가 분기된 이후 다시 병합하려면 Fast-Forward가 불가능함

사용 예시

  • 메인 브랜치(master/main)가 최신 상태이며, 기능 브랜치(feature)가 최신 커밋 이후에만 변경된 경우
  • 개인 프로젝트에서 브랜치 사용을 최소화하며 작업할 때

2. Merge Commit (Non-Fast-Forward Merge, 3-way)

   독립적으로 개발된 두 개의 브랜치를 하나의 공통 브랜치로 병합할 때 사용된다. 새로운 병합 커밋이 생성되며, 브랜치가 어디에서 합쳐졌는지 명확하게 기록된다.

장점

  • 브랜치의 병합 기록이 명확하여 협업 시 히스토리를 추적하기 쉬움
  • 여러 브랜치에서 작업한 내용을 하나의 브랜치로 통합할 때 유용

단점

  • 불필요한 병합 커밋이 많아지면 Git 로그가 복잡해질 수 있음
  • 단순한 변경 사항도 병합 커밋이 추가되므로 히스토리가 늘어남

사용 예시

  • 여러 명이 협업하는 프로젝트에서 기능 개발 브랜치를 메인 브랜치로 병합할 때
  • 이력을 명확하게 남겨야 하는 상황

3. Squash Merge

  병합 시 여러 개의 커밋을 하나의 커밋으로 압축(squash)하여 병합하는 방식이다. 병합 후에는 단일 커밋만 남게 되며, 병합 커밋이 생성되지 않는다.

장점

  • 불필요한 커밋을 줄여 Git 히스토리를 깔끔하게 유지 가능
  • 코드 리뷰 후 병합할 때 커밋을 정리하여 가독성을 높일 수 있음

단점

  • 개별 커밋의 변경 사항이 사라지므로 세부 이력을 확인하기 어려움
  • 협업 시 누가 어떤 작업을 했는지 추적하기 힘들 수 있음

사용 예시

  • 기능 개발 브랜치에서 여러 개의 작은 커밋을 하나의 커밋으로 정리하여 병합할 때
  • PR(Pull Request) 병합 시 코드 리뷰 후 히스토리를 깔끔하게 정리할 때

4. Rebase Merge

   Rebase는 특정 브랜치의 변경 사항을 다른 브랜치 위로 이동하여 재배열하는 방식이다. 병합 커밋을 생성하는 대신, 기존 커밋을 재작성하여 마치 처음부터 해당 브랜치에서 작업한 것처럼 만든다.

장점

  • 불필요한 병합 커밋을 없애고, Git 히스토리를 깔끔하게 유지 가능
  • 병합 충돌이 발생했을 때 보다 세밀하게 조정할 수 있음

단점

  • 커밋 히스토리가 변경되므로, 이미 공유된 브랜치에서 rebase를 하면 충돌이 발생할 수 있음
  • 협업 중 잘못 사용하면 Git 히스토리가 꼬일 위험이 있음

사용 예시

  • 개인 작업 시 깔끔한 Git 히스토리를 유지하고 싶을 때
  • 기능 브랜치를 메인 브랜치에 맞추기 위해 최신 상태로 업데이트할 때

5. Cherry-Pick

   Cherry-Pick은 특정 브랜치에서 선택한 커밋만 다른 브랜치로 적용하는 방식이다. 전체 브랜치를 병합하는 것이 아니라, 특정 변경 사항만 가져오는 데 유용하다.

장점

  • 원하는 변경 사항만 선택적으로 반영 가능
  • 실수로 잘못된 브랜치에 커밋했을 때 수정하기 쉬움

단점

  • 커밋이 여러 브랜치에 중복될 수 있어 히스토리가 혼란스러워질 수 있음
  • 충돌이 발생하면 해결하는 데 시간이 걸릴 수 있음

사용 예시

  • 특정 기능 또는 버그 수정 사항만 따로 가져와 적용할 때
  • 긴급 패치를 메인 브랜치에 적용할 때

어떤 병합 방식을 사용할 것인가?

  • Fast-Forward Merge: 히스토리를 단순하게 유지하고 싶을 때
  • Merge Commit: 팀 협업 시 브랜치 이력을 명확하게 남기고 싶을 때
  • Squash Merge: 코드 리뷰 후 불필요한 커밋을 정리하고 싶을 때
  • Rebase Merge: 히스토리를 깔끔하게 유지하면서 변경 사항을 반영하고 싶을 때
  • Cherry-Pick: 특정 변경 사항만 따로 적용하고 싶을 때

경험

  • Fast-Forward Merge: 개인 프로젝트 혹은 브랜치 관리를 할 필요가 없을 정도의 작은 변경할 때 주로 사용한다.
  • Merge Commit: 일반적인 병합이자 가장 많이 사용되는 방식으로 대규모 프로젝트에서 여러 개발자가 동시에 작업할 때 사용된다.
  • Squash Merge: 기능 브랜치에서 여러 개의 작은 커밋을 남긴 상태에서 메인 브랜치와 병합할 때 충돌이 발생하면, 충돌을 해결한 후 스쿼시 머지를 수행하여 하나의 깔끔한 커밋으로 정리할 수 있다.
  • Rebase Merge: 코드 히스토리를 단순하게 유지하면서도 최신 변경 사항을 반영하기 위해서 사용된다. 특히, CI/CD에서 유용하게 사용된다.
  • Cherry-Pick: 최신 개발과 현재 라이브 운영 빌드를 나눌 때 혹은 운영 중 긴급 버그 발견할 때 주로 사용된다.

참고

 

VCS 프로젝트 브랜치 전략

서론   한 프로그램을 만드는 데 많은 사람들이 투입된다. 그중 코딩은 서로 얽히고 얽혀 개발 과정이 매우 복잡한 형태가 된다. 아무 전략을 세우지 않고 하다 보면 아무리 서로에게 보고를 잘

jinger.tistory.com

반응형

'VCS > GitHub' 카테고리의 다른 글

프로젝트 위기에서 구할 git 명령어  (1) 2024.11.24
Git 간단 사용 방법  (0) 2024.07.10
깃허브 Wiki  (0) 2023.04.17
깃허브 Project  (0) 2023.04.17
깃허브 Discussion  (0) 2023.04.16

댓글