❓Git에서 branch merge 방법들과 각 방법의 특징을 설명해 주세요.

1. merge

• 현재 브랜치를 다른 브랜치와 병합함.
  ⚠️main 브랜치가 맨 왼쪽에 있어서 HEAD가 밀려버리는 상황이 발생하면 그래프 순서가 꼬인다는 단점!

2. Squash and merge

• 브랜치에서의 모든 변경 사항을 하나의 커밋으로 저장함.

git merge --sqaush [머지할 브랜치]

⚠️일반 merge에 비해 남아있는 정보량이 적어 개발용 브랜치에서 언제 어떤 코드를 바꿨는지에 대한 정보가 사라질 수 있다는 단점!

3. Rebase and merge

• rebase 기능을 이용해 브랜치를 머지함.
  ⚠️merge commit이 없어서 어느 시점에 merge가 되었는지 판단하기 어렵다는 단점

✔️fast-forward merge

• 새로운 커밋이 생기는 것이 아닌 단지 브랜치가 이동함.
• 다른 상태를 병합하는 것이 아니라 단순히 HEAD만 이동시키면 merge가 처리될 수 있는 환경에서 수행됨.

// rebase and merge를 할 때 머지했다는 커밋 메시지를 남기고 싶을 때
git merge -no-ff [머지할 브랜치]

// fast-forward가 아니면 머지를 하고 싶지 않을 때
git merge -ff-only [머지할 브랜치]

✔️3-way merge

• 3가지 커밋을 기준으로 머지 커밋을 자동으로 만듦.
• 브랜치마다 신규 커밋이 하나 이상 있는 경우 새로운 커밋을 생성하면서 합쳐줌.
  

❓Git Flow 브랜치 전략에 대해 설명해 주세요.

• main(master): 서비스를 직접 배포하는 역할을 하는 브랜치
• develop: feture에서 개발된 내용이 저장되는 브랜치
• feature: 기능 개발 브랜치
• release: 배포 전 내용을 QA하기 위한 브랜치
• hotfix: 출시 버전에서 발생한 버그를 수정하는 브랜치

• master와 develop 브랜치는 필수다. (develop 브랜치는 master에서 시작된 브랜치)
• develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가된다.
• 개로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성한다. (feature 브랜치는 항상 develop 브랜치에서 시작)
• 기능 추가 작업 완료 후 feature 브랜치는 항상 develop 브랜치로 merge됨.
• merge 후 QA 진행을 위해 release 브랜치 생성.
• release 브랜치에서 QA에서 진행된 버그를 수정한다.
• QA 통과 후, release 브랜치를 master와 develop 브랜치로 merge한다.