[Weekly Paper] 2. Git branch merge & Git Flow

Git Branch Merge

• Merge(일반적인 merge 방법)
  • 변경 내용의 커밋 내역이 모두 그대로 남는다 → 각각의 브랜치에 남은 커밋을 히스토리에 그대로 남긴다 
  • merge를 할 경우 merge 커밋이 새로 생긴다 → 불필요한 커밋 내역이 생겨 히스토리가 복잡하고 지저분해져 협업 과정에서 커밋 확인에 불편함이 생길 수 있다
  • Fast-Foward 방법과 3-Way-Merge 방법이 있다
  •  Fast-Forward
    • 하나의 브랜치와 다른 브랜치의 변경 내역 merge 하는방법이다
    • 서로 다른 상태를 병합하는 것이 아니라 단순히 HEAD만 이동시키면 Merge가 처리될 수 있는 환경에서 수행한다
    • git merge —no-ff <머지할 브랜치>: 병합 대상 브랜치와 현재 브랜치와의 관계가 Fast-Forward라고 하더라도 머지 커밋을 남기고 싶다면 사용한다
    • git merge —ff-only <머지할 브랜치> : fast-forward가 아니면 머지를 하지 않을 때 사용한다
  • 3-Way-Merge
    • 파생된 브랜치와 Master 브랜치 둘 다 변경사항이 있을 경우에 하는 merge 방법으로 가장 일반적인 경우다
    • 각 브랜치의 최신 커밋과 공통 조상(Base) 커밋을 비교하여 새로운 커밋을 만들어 merge한다

git merge <branch name>
git merge —no-ff <머지할 브랜치>
git merge —ff-only <머지할 브랜치>

• Rebase Merge
  • 공통 조상(Base)을 가진 두 브랜치에서 하나의 브랜치의 base를 다른 브랜치의 최신 커밋을 base로 하게끔 재정렬하는 것을 의미한다
  • rebase를 수행할 경우 merge와 다르게 merge 커밋이 생기지 않는다
  • 하나의 브랜치에서 작업한 것처럼 보이므로 히스토리를 간결하게 하고 싶을 때 사용한다
  • 히스토리의 base를 직접 옮겨서 처리하는 방식이다
  • 개발용 브랜치에서 변경한 내용을 중앙 브랜치에서 변경한 것처럼 바꿀 수 있다
  • 기본적으로 merge 커밋이 없기 때문에 어느 시점에 merge가 되었는지 나중에 찾기 어렵다 → 보완하기 위해 어디서 merge가 되었는지 태그를 남기기도 한다
  • git rebase -i HEAD~<n> : 해당 명령어를 통해 단일 브랜치 내에서 rebase의 기능을 활용해 커밋 메시지를 변경할 수 있다

git checkout test-branch
git rebase main
git checkout main
git merge test-branch

• Squash Merge
  • 여러개의 커밋을 하나의 커밋으로 만들어준다
  • 개발용 브랜치에 있던 내용들을 하나로 합쳐서 중앙 브랜치에 하나의 커밋으로 저장하는 전략이다
  • 새롭게 발생하는 merge 커밋은 개발용 브랜치에서의 변경사항들을 하나로 뭉쳐놓은 커밋이다
  • 기존 변경사항들의 변경 이력보다는 merge가 되었다는 것에 더 집중한 방법이다
  • 기본 merge 방법에 비해 남아있는 정보량이 적기 때문에 개발용 브랜치에서 코드를 언제 수정했는지에 대한 정보를 잃을 수 있다는 단점이 있다
  • pick과 squash를 같이 사용하면 하나의 커밋이 아닌 원하는 커밋 수로 압축할 수 있다

git checkout main
git merge --squash test-branch
git commit -m "commit test"

---

Git Flow

• 소스코드를 관리하고 출시하기 위한 브랜치 관리 전략(branch management strategy)이다
• git flow에서 사용하는 브랜치 종류는 5가지로 항상 유지되는 메인 브랜치(Master, Develop)와 일정 기간 유지되는 보조 브랜치(feature, release, hotfix)로 나뉜다
• master(main), develop 브랜치는 항상 유지되는 필수 브랜치, 나머지 브랜치는 유지보수를 목적으로 하는 옵셔널한 브랜치이다.
  • Master : 제품으로 출시될 수 있는 브랜치
  • Develop : 다음 출시 버전을 개발하는 브랜치
  • Feature : 기능을 개발하는 브랜치
  • Release : 출시 버전을 준비하는 브랜치. 배포를 하기 전 내용을 QA(품질 검사)하기 위한 브랜치
  • Hotfix : master 브랜치로 배포를 하고 나서 버그가 발생할 경우 빨리 수정하기 위한 브런치
• 관리 순서
  • repository를 생성하면 master branch에 위치한다
  • 개발을 할 때는 develop 브랜치를 만들어 해당 브랜치에서 개발한다
  • develop 브랜치에서도 특정 기능을 개발할 때는 feature 브랜치를 생성하여 개발한다
  • feature 브랜치의 개발이 끝나면 develop 브랜치로 pull request한다
  • develop 브랜치의 개발 리더 또는 동료 직원들이 해당 request를 확인하고 문제가 없다면 merge한다
    • merge 이후에 feature 브랜치가 필요없으면 삭제한다
  •  develop 브랜치에서 어느 정도 개발이 완료되면 release 브랜치를 생성하여 QA를 진행한다
    • release 브랜치에서 발생한 버그들은 release 브랜치에서 수정한다
  •  QA를 통과하여 제품이 출시될 수 있다면 master와 develop 브랜치로 merge한다
  • 마지막 master 브랜치에 버전 태그 추가한다
  • 만약 이미 출시되어 master로 관리되고 있는 버전에서 버그가 발생하여 빠르게 수정을 해야 하는 상황이 발생한다면 master 브랜치에서 hotfix브랜치를 생성하고 오류를 수정 후 master와 현재 개발 중인 develop 브랜치에 반영한다
• 장점 
  • 안정적인 배포를 위한 구조가 갖춰져 있다
  • 긴 개발 주기에 적합하고 복잡한 기능 개발과 버그 수정에 유용하다장점 
• 단점
  • 관리해야 할 브랜치 개수가 많다
  • 작은 규모의 프로젝트보다는 큰 규모의 프로젝트에 적합하다

git flow