[Github 협업, 이것만은 알자] - Branch

💭 브랜치란?

브랜치는 본질적으로 독립적인 개발 라인입니다. 새 기능이나 버그 수정 작업을 할 때마다
기존 브랜치에서 각기 다른 브랜치를 분기하여 다른 작업과 분리할 수 있습니다.

또한 별도의 브랜치를 하나의 브랜치로 병합(Merge)할 수 있습니다.

브랜치마다 이름을 붙일 수 있으며, 이러한 특징을 활용하여 브랜치를 역할에 따라 정해둔 이름을 붙여 용도에 맞게 관리하는 브랜치 전략이라는 것이 존재합니다.

개발자마다 각자 방식이 있겠지만 틀을 갖춘 전략을 활용하여 관리하는 것이 더 효율적이고 유연합니다.

---

💭 브랜치 전략

이번 시간엔 대체적으로 많이 이용되고 있는 브랜치 전략인 Git-flow 전략에 대해 소개해드리려고 합니다.

⚙️ Git-flow

깃 플로우는 브랜치를 통해 프로젝트를 관리하는 전략으로 브랜치는 총 5개로 구분합니다.

• master: 배포됐거나 배포될 소스를 저장하는 브랜치
  • 보통 Repository 생성 초기엔 master 브랜치에서 프로젝트 기초 설정을 마친다.
• develop: 배포하기 위한 다음 버전을 개발하는 브랜치
• feature: '다음 릴리즈때 출시할' 또는 '언젠가 추가할' 기능을 개발하는 브랜치
• hotfixs: 배포된 버전에 생긴 문제를 해결하기 위한 개발이 필요할 때 쓰이는 브랜치
• release: 배포할 준비가 된 소스를 저장하는 브랜치

---

🤔 Git-flow 사이클 설명

이해가 잘 가시지 않을 거라 생각되어,
위의 설명을 바탕으로 한 번의 개발 사이클을 설명해보겠습니다.

1. master브랜치에서 프로젝트 기초 설정 수행합니다.

2. 배포할 새로운 버전의 애플리케이션 개발을 위해 master 브랜치에서 develop 브랜치를 분기합니다.

3. 추가할 기능들을 개발하기 위해 develop 브랜치에서 기능 단위로 feature 브랜치를 분기 후 기능 개발 시작합니다.

4. feature 브랜치에서 기능 개발이 완료되면 develop 브랜치로 합병(merge) 합니다.

5. 이번 버전에서 추가할 기능에 대한 개발이 모두 완료되어 develop 브랜치에 merge되면,
   develop에서 1.0버전 출시를 위해 release 브랜치를 분기하여 배포 준비합니다.
   (release 브랜치는 배포 직전 단계이므로 각종 테스트와 버그 수정 진행)
   

6. release 브랜치에서 버그가 수정될 때마다 develop 브랜치에 변경 사항을 계속 merge하여 수정된 코드와 상태를 동기화해줍니다.

7. release 브랜치에서 버그 수정이 끝나면, 버전 배포를 위해 master 브랜치로 merge 하여 새로운 버전 배포합니다. develop 브랜치에서도 최종 수정이 끝난 release 브랜치를 merge 하여 상태를 맞춤.

8. 이후 develop 브랜치에서 또다시 새로운 버전 개발

---

✅ 다음으로

설명을 통해서 이해가 좀 되셨나요?

하지만 글로만 보면 “브랜치 분기?”, “머지가 머지?(ㅋㅋㅋ)” 등등 제대로 이해할 수가 없는데요..!
브랜치를 생성 및 변경 사항에 대해 PR을 올리기, Merge 하기 등을 다음 주제인 Issue & PR에서 알아봅시다!