DevOps

[Git] Merge 전략

kyoulho 2024. 8. 25. 16:52

Git에서 브랜치를 병합할 때 사용할 수 있는 다양한 병합 전략들이 있다. 각 전략은 특정 상황에 맞게 사용되며, 프로젝트의 커밋 히스토리를 관리하는 데 중요한 역할을 한다.

 

Fast-Forward Merge

병합할 브랜치가 다른 브랜치에서 파생된 이후 해당 브랜치에 새로운 커밋이 없을 때 사용된다. 이 경우, 병합 브랜치는 대상 브랜치의 최상위 커밋 위에 그대로 이어지게 된다.

  • 사용 방법:
    • git merge --ff-only <branch-name>
    • 기본적으로 git merge <branch-name>로도 Fast-Forward 병합이 수행된다. --ff-only 옵션을 추가하면 Fast-Forward 병합이 불가능한 경우 병합이 거부된다.
  • 언제 사용해야 하는가?
    • 독립적인 작업이 없을 때: main 브랜치에서 새로운 커밋이 없고, feature 브랜치에서만 작업이 이루어진 경우.
    • 히스토리를 간단하게 유지하고 싶을 때: 모든 작업이 선형으로 이어지도록 하여, 브랜치 구조를 깔끔하게 유지하고자 할 때.
  • 장점:
    • 히스토리가 간결하고 직관적이다.
    • 불필요한 병합 커밋이 생성되지 않는다.
  • 예시:
    • 새로운 기능을 개발한 feature 브랜치를 main 브랜치에 병합할 때, main 브랜치에서 다른 작업이 없었다면 Fast-Forward 병합이 적합하다.

병합 전:

   A---B---C  (main)
            \
             D---E  (feature)

병합 후:

   A---B---C---D---E  (main, feature)

 

 

Recursive Merge

두 브랜치가 각각 독립적으로 커밋을 가지고 있을 때 사용된다. Git은 공통 조상(commit)을 찾은 다음, 두 브랜치의 변경 사항을 병합하여 새로운 병합 커밋을 생성한다.

  • 사용 방법:
    • git merge <branch-name>
    • 기본적인 병합 명령어로, 대부분의 병합 시 Recursive Merge가 기본적으로 사용된다.
  • 언제 사용해야 하는가?
    • 여러 작업이 동시에 진행되었을 때: mainfeature 브랜치에서 각각 독립적으로 작업이 이루어졌을 때.
    • 충돌을 해결하고 기록을 남기고 싶을 때: 병합 충돌이 발생할 가능성이 있는 상황에서, 병합 커밋을 통해 명확한 기록을 남기고자 할 때.
  • 장점:
    • 각 브랜치의 작업 내역이 모두 보존된다.
    • 병합 충돌을 해결할 수 있는 기회를 제공한다.
  • 예시:
    • main 브랜치에서 버그를 수정하는 동안, feature 브랜치에서 새로운 기능을 개발한 경우, 두 브랜치를 병합할 때 Recursive Merge가 사용된다.

병합 전:

   A---B---C  (main)
    \     \
     D---E---F  (feature)

병합 후:

   A---B---C-----G  (main)
    \     \     /
     D---E---F  (feature)

 

Squash & Merge

브랜치를 병합할 때 여러 개의 커밋을 하나의 커밋으로 압축(squash)하여 병합하는 방식이다. 이 방식은 작은 커밋이 여러 개 쌓여 있는 경우, 히스토리를 간단하게 유지하는 데 유용하다.

  • 사용 방법:
    • git merge --squash <branch-name>
    • 이 명령어를 사용하면 병합할 브랜치의 모든 커밋이 하나로 압축되며, 병합 후에 수동으로 커밋을 생성해야 한다(git commit).
  • 언제 사용해야 하는가?
    • 히스토리를 간단하게 유지하고 싶을 때: 여러 개의 작은 커밋으로 복잡해진 히스토리를 단순화하고 싶을 때.
    • 작업 단위를 통합하고 싶을 때: 작업 중 많은 세부 커밋이 발생했을 때, 이를 하나의 커밋으로 합쳐 병합하면 히스토리가 깔끔해진다.
  • 장점:
    • 히스토리가 단순하고 명확하다.
    • 불필요한 커밋을 제거하여 커밋 로그를 깔끔하게 유지할 수 있다.
  • 예시:
    • feature 브랜치에서 여러 개의 작은 커밋(디버깅, 테스트 등)이 이루어졌다면, 이를 하나의 커밋으로 묶어 main 브랜치에 병합할 때 Squash & Merge를 사용한다.

병합 전:

   A---B---C  (main)
            \
             D---E---F  (feature)

병합 후:

   A---B---C---G  (main)
            (G: D+E+F 합쳐진 커밋)

 

 

Rebase & Merge

한 브랜치의 커밋을 다른 브랜치의 최상위 커밋 위로 이동시켜 병합하는 방식이다. 이 방법은 선형적인 히스토리를 유지하고자 할 때 유용하다.

  • 사용 방법:
    • git rebase <branch-name>
    • rebase를 사용하여 feature 브랜치의 커밋을 main 브랜치의 최신 커밋 위로 이동시킨 후, 병합한다.
  • 언제 사용해야 하는가?
    • 선형적인 히스토리가 필요할 때: 복잡한 병합 기록을 피하고, 깔끔한 히스토리를 유지하고자 할 때.
    • 커밋 히스토리를 재구성하고 싶을 때: 작업 순서에 따라 커밋을 재구성하여 이해하기 쉽게 만들고자 할 때.
  • 장점:
    • 히스토리가 직관적이고, 불필요한 병합 커밋이 생성되지 않는다.
    • 충돌이 발생할 경우, 각 커밋에서 개별적으로 해결할 수 있다.
  • 예시:
    • main 브랜치에서 업데이트가 이루어진 후, feature 브랜치에서 계속 작업한 경우, Rebase를 통해 main의 최신 커밋을 기반으로 feature 브랜치를 재정렬한 후 병합할 수 있다.

병합 전:

   A---B---C  (main)
    \
     D---E---F  (feature)

Rebase 후:

       A---B---C  (main)
                \
                 D'---E'---F'  (feature)

병합 후:

   A---B---C---D'---E'---F'  (main)
728x90

'DevOps' 카테고리의 다른 글

[MW] Flyway  (0) 2024.08.31
[Git] Git 워크플로우 비교: GitHub Flow, Gitflow, GitLab Flow  (0) 2024.07.30
RabbitMQ, Apache Kafka, AWS SQS 비교  (0) 2024.01.13
Apache Kafka  (0) 2023.12.30