2주차 위클리페이퍼

Branch merge 방법

Branch란?

Software 개발 시 개발자들은 동일한 소스코드 위에서 신규 개발, 버그 수정 등의 업무를 협업하곤 한다. 이럴 때, 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능이 "Branch" 이다.

즉, 브랜치(Branch)를 통해 하나의 프로젝트를 여러 갈래로 나누어서 관리할 수 있다. 각각의 독립된 Branch에서 마음대로 소스코드를 변경하여 작업 한 후 원래 버전과 비교하여 또 하나의 새로운 버전을 만들어 낼 수 있다.

merge란?

다른 브랜치(분기)의 변경 사항을 현재 브랜치로 통합하는 과정을 나타낸다. 즉, 하나의 브랜치에서 작업한 내용을 다른 브랜치와 병합하는 것이다. 여러 작업자가 동시에 작업하고, 나중에 그 작업을 통합할 때 특히 유용하다.

• merge는 다음과 같은 상황에서 사용될 수 있다.

  1. Feature 브랜치의 변경 내용을 Main 브랜치로 병합: 새로운 기능을 개발한 Feature 브랜치의 변경 내용을 Main 브랜치로 병합하여 프로젝트에 통합

  2. 다른 팀원의 작업을 통합: 다른 팀원이 작성한 변경 내용이 포함된 브랜치를 현재 브랜치로 병합하여 여러 팀원의 작업을 통합

  3. Hotfix 브랜치의 수정사항을 Main 브랜치로 병합: 버그 수정을 위해 생성한 Hotfix 브랜치의 변경 내용을 Main 브랜치로 병합하여 문제를 해결

• Git에서 merge는 주로 다음 두 가지 방법을 사용한다.

  1. Fast-Forward Merge : 한쪽 브랜치에서만 일어난 변경사항을 다른 브랜치로 병합하는 방식

  예시)
  시작 시점에서 main 브랜치와 feature 브랜치가 서로 다른 커밋을 가지고 있다.
  
  feature 브랜치에서 main 브랜치로 Fast-Forward Merge를 수행하면 main 브랜치가 feature 브랜치의 가장 최신 커밋 D를 가리키도록 이동한다. 새로운 커밋이 생성되지 않고 브랜치가 이동하는 것이 Fast-Forward Merge의 특징이다.
  
  Fast-Forward Merge는 주로 주제 브랜치를 메인 브랜치로 빠르게 통합할 때 사용된다. 새로운 기능이나 수정 사항을 개발한 브랜치의 변경 사항을 메인 브랜치로 빠르게 통합할 수 있다.

  2. Recursive Merge (Three-way Merge) : 서로 다른 두 커밋을 가진 브랜치가 하나로 병합하는 과정에서 두 브랜치가 양쪽의 이력을 그대로 보존하고자 병합 커밋을 만들면서 병합하는 방식

  예시)
  시작 시점에서 main 브랜치와 feature 브랜치가 서로 다른 커밋을 가지고 있다.
  
  feature 브랜치에서 main 브랜치로 Three-way Merge를 수행하면 Git은 main 브랜치와 feature 브랜치의 공통 조상을 찾는다. 이건 커밋 A다. 각 브랜치에서 이후의 변경 사항을 찾아내고 비교한다. feature 브랜치에서는 커밋 C와 D가 발견된다. 변경 사항이 충돌하지 않는 경우, Git은 새로운 병합 커밋을 생성하여 변경 사항을 통합한다.
  
  Three-way Merge는 주로 다른 브랜치와 현재 브랜치의 변경 사항을 병합할 때 사용된다. 충돌이 발생하는 경우에도 이를 효과적으로 해결하고, 두 브랜치에서 변경된 내용을 통합하는 데 도움을 준다.

Git Flow 브랜치 전략

Git Flow는 소프트웨어 개발 프로젝트의 브랜치 관리를 위한 일련의 규칙과 브랜치 전략을 정의한 모델이다. Git Flow는 Vincent Driessen이 2010년에 제안한 방법론(A successful Git branching model)으로, 프로젝트의 유지 및 개선을 위한 명확한 브랜치 구조와 규칙을 제공한다.

Git Flow의 주요 브랜치:

1. Main 브랜치:

   main 브랜치는 프로덕션 레디 상태인 코드가 저장되는 브랜치다. 이 브랜치는 항상 안정적이고 배포 가능한 코드를 유지한다.

2. Develop 브랜치:

   develop 브랜치는 다음 버전을 개발하기 위한 브랜치다. 새로운 기능 및 버그 수정과 같은 개발 작업은 주로 이 브랜치에서 진행된다.

Git Flow의 보조 브랜치:

1. Feature 브랜치:

   feature 브랜치는 새로운 기능을 개발하기 위한 브랜치다. 개발자는 개별 기능을 구현하고 develop 브랜치로 병합한다.

2. Release 브랜치:

   release 브랜치는 다음 버전의 릴리스를 준비하기 위한 브랜치다. develop 브랜치에서 완료된 기능을 검토하고 버그를 수정한 후, main와 develop에 병합됩니다.

3. Hotfix 브랜치:

   hotfix 브랜치는 프로덕션에서 발생한 긴급한 버그 수정을 위한 브랜치다. main 브랜치에서 릴리스되지 않은 버전에 대한 수정 사항을 포함하며, 수정이 완료되면 main와 develop에 병합된다.

Git Flow의 작업 흐름:

1. 새로운 기능 개발을 시작하려면 feature 브랜치를 생성하고 개발을 진행
2. 개발이 완료되면 develop 브랜치로 병합
3. 다음 버전을 릴리스할 때는 release 브랜치를 생성하고, 버그 수정 및 마무리 작업을 진행
4. 릴리스가 준비되면 main와 develop로 병합하고, 새로운 버전을 릴리스
5. 프로덕션에서 긴급한 버그 수정이 필요한 경우 hotfix 브랜치를 생성하고 수정을 진행
6. 수정이 완료되면 main와 develop로 병합하고, 새로운 릴리스를 생성

• Git Flow의 장점:

1. 프로젝트의 브랜치 관리를 체계화하고, 프로덕션 코드와 개발 코드를 분리한다.
2. 다른 작업자와의 협업을 향상시키고 충돌을 최소화한다.
3. 안정적인 프로덕션 환경과 개발 환경을 유지하며 개발자와 운영팀 간의 협력을 촉진한다.

• Git Flow의 단점:

1. 복잡한 프로젝트에서는 추가 오버헤드를 초래할 수 있고, 간단한 프로젝트에서는 과도한 일을 할 수 있다.
2. 긴급한 수정이 필요한 경우에도 프로세스가 복잡할 수 있다.