Git 브랜치 전략이란?

💡 브랜치 전략은 소프트웨어 개발에서 여러 개발자가 동시에 작업할 때 코드 변경 사항을 효과적으로 관리하기 위한 방법입니다.
각 개발자는 기능이나 버그 수정을 위해 별도의 브랜치를 생성하고, 작업이 완료되면 이를 주 브랜치에 병합하는 방식으로 진행됩니다.

---

Git Flow 와 GitHub Flow 비교

가장 유명한 브랜치 전략인 Git Flow 와 GitHub Flow 중 어떤 전략을 사용하는게 좋을까요?

다양한 관점에서 두 전략을 비교해보겠습니다.

1. 브랜치 수

🏸 Git Flow: 다양한 종류의 브랜치를 사용.

🎾 GitHub Flow: 단일 브랜치 (main) 사용.

2. 배포 방식

🏸 Git Flow: release와 hotfix 브랜치를 통해 명확한 배포 절차를 갖춤.

🎾 GitHub Flow: 단순하며 지속적인 배포를 강조, main 브랜치에서 배포 수행.

3. 복잡성

🏸 Git Flow: 복잡한 프로젝트나 대규모 팀에 적합.

🎾 GitHub Flow: 단순하며 빠른 개발 및 배포에 적합.

각각의 전략은 장, 단점이 존재하기에 프로젝트의 규모, 요구 사항 및 팀의 작업 방식에 맞추어 적절하게 채택하는 것이 좋습니다.

🏸 Git Flow는 더 많은 제어와 복잡성을 가지고 있어 특정 기능이나 수정을 빠르게 배포해야 할 경우 등에서 유연성이 다소 떨어집니다.

그러나 그만큼 배포 안정성과 버전 관리 및 롤백 등 체계적인 운영이 가능합니다.

🎾 GitHub Flow 는 테스트와 검증 절차를 거치지 않고 바로 master 브랜치로 Merge 되므로 위험성을 가지고 있습니다.

하지만 그만큼 단순하고 빠르게 기능을 테스트하고 Agile 하게 배포할 수 있기 때문에, 주로 각 환경의 구분이 명확하지 않고 작은 규모의 프로젝트에 적합한 전략입니다.

---

🎾GitHub Flow

GitHub Flow는 간단하고 직관적인 방식으로 널리 사용되는 브랜치 전략입니다. 다음과 같은 기본 원칙을 따릅니다:

1. 주 브랜치 (Main)

main 또는 master라는 이름의 주 브랜치가 있으며, 이 브랜치는 항상 배포 가능한 상태를 유지해야 합니다.

2. 기능 브랜치 (Feature)

새로운 기능이나 버그 수정을 위해 main 브랜치에서 분기된 기능 브랜치를 생성합니다. 이 브랜치는 작업이 완료되면 main 브랜치에 병합됩니다.

3. Pull Request

기능 브랜치에서 작업이 완료되면, main 브랜치에 병합하기 위해 Pull Request를 생성합니다. 이 과정에서 코드 리뷰와 테스트가 이루어집니다.

4. 병합

Pull Request가 승인되면, 기능 브랜치를 main 브랜치에 병합합니다. 이후, 기능 브랜치는 삭제할 수 있습니다.

---

GitHub Flow의 흐름

1. main 브랜치는 배포를 위한 소스코드를 관리하는 브랜치입니다.

2. 신규 기능 개발이 필요할 때, feature 브랜치를 따서 작업을 진행합니다.

3. 태스크가 완료되면, Pull Request를 생성하여 Review를 요청합니다.

4. 리뷰가 완료되고, 피드백이 모두 반영되면 해당 feature 브랜치를 main 브랜치로 Merge합니다.

---

GitHub Flow 단계별 예시

1. Main 브랜치 생성

먼저, main 브랜치를 생성합니다.

이 브랜치는 항상 Stable한 상태여야 합니다. 이때, Stable하다는 것은 Main의 모든 커밋은 언제 배포하든 문제 없어야하고, 언제든 브랜치를 새로 만들어도 문제가 없어야 합니다.

git checkout -b main
# 작업 후 커밋
git commit -m "Initial commit"

2. Feature 브랜치 생성

새로운 기능을 개발하기 위해 main 브랜치에서 기능 브랜치를 생성합니다. 예를 들어, "새로운 로그인 기능"을 개발한다고 가정해 보겠습니다.

(이때, 체계적인 분류 없이 브랜치 하나에 의존하게 되므로 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 중요합니다.)

git checkout -b feature/login

3. 기능 개발

기능 브랜치에서 코드를 작성하고 변경 사항을 커밋합니다.

# 코드 작성
git add .
git commit -m "Add login feature"

4. 원격 저장소에 푸시

기능 브랜치를 원격 저장소에 푸시합니다.

git push origin feature/login

5. Pull Request 생성

merge 준비가 완료되었을 때는, GitHub에서 feature/login 브랜치에 대한 Pull Request 를 생성합니다.

이 과정에서 팀원들이 코드를 리뷰하고 피드백을 줄 수 있습니다.

6. 코드 리뷰 및 수정

팀원들이 Pull Request 를 리뷰하고, 필요한 경우 수정 요청을 합니다. 수정 후 다시 커밋하고 푸시합니다.

# 수정 후
git add .
git commit -m "Fix login feature based on review"
git push origin feature/login

7. Pull Request 승인 및 병합

코드 리뷰가 완료되면 Pull Request를 승인하고, main 브랜치에 merge 합니다.

8. 기능 브랜치 삭제

병합이 완료되면, 더 이상 필요하지 않은 기능 브랜치를 삭제합니다.