[Git] GIT 브랜치 전략

최동근·2023년 1월 9일

오늘은 대표적인 Git Branch 전략인 Git-Flow 와 Github-Flow 전략에 대해 알아보겠습니다 👨‍💻

📌 GIT 브랜치 전략

Git Branch 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow 입니다 🙆🏻
branch 생성,삭제,병합 등 Git 의 유연한 구조를 활용해서, 각 개발자들의 혼란을 최대한 줄이며 다양한 방식으로 소스를 관리하는 역할을 합니다 👨‍💻

팀프로젝트를 통해 협업을 진행해보았더라면 Git을 사용한 경험이 있을텐데요.
팀원들은 프로젝트를 시작하기 전에 미리 어떤 Git branch 전략을 사용할지 결정해야 합니다.

📌 GIT 브랜치 전략이 왜 필요한가?

개발자로써 협업은 매우 어려운 작업입니다.
1인 개발과는 달리, 모든 것을 협의를 통해서 결정해야 하며 다른 팀원이 작성한 코드 또한 이해를 해야합니다.
또한, 팀원 각자의 코딩 스타일이 반영되기 때문에, 미리 규칙을 정해서 협업을 유연하게 할 필요가 있습니다 👨‍💻

만약 어떤 방식으로 Branch 를 사용할지에 대한 공통 규칙이 없으면 어떨까요?
이는 협업에 참여하는 개발자에게 다양한 궁금중을 자아낼 수 있습니다.

어떤 브랜치가 최신 브랜치지?
어떤 브랜치를 가지고 와서 개발을 시작해야 할까?
긴급한 수정이 필요해 보이는데, 어떤 브랜치를 기준으로 수정해야 할까?
배포 버전은 어떤 걸 골라야지?
어디에 push 를 보내야 할까?

이러한 궁금중은 협업을 뎌디게 하며, 개발자에게 혼란을 줄 수 있는 큰 요인이 될 수 있습니다 😥
다행히, 이미 많은 개발자들이 채택해서 사용하고 있는 Git Branch 전략이 있습니다.
이번 포스팅은 가장 대중적인 Git Branch 전략인 Git-Flow & GitHub-Flow 대해 알아보겠습니다 👨‍💻

📌 GIT-FLOW 전략

⚙️ Branch 상세 설명

해당 이미지는 GIT-FLOW 전략을 소개하는 이미지입니다.
총 5가지 Branch 가 존재합니다 🤔

master : 실제 제품으로 출시되는 branch ( 서비스 출시 )
develop : 다음 출시 버전을 대비하여 개발하는 branch
feature : 추가 기능 개발 branch, 완성 시 develop branch에 병합
release : 다음 버전 출시를 준비하는 branch , develop branch를 release branch로 옮긴 후 QA 테스트를
진행하고 master branch로 합침.
hotfix : master branch 에서 발생한 버그를 급하게 수정하는 branch
[메인 branch]
- master branch
- develop branch
- 앞에서 설명한 바와 같이, master branch는 배포 가능한 상태만을 관리하는 branch 이며,
  develop branch는 다음에 배포할 것을 개발하는 branch 입니다.
  즉, develop branch 는 통합 branch 역할을 하며, 개발자는 이 branch 를 기반으로 개발을 진행합니다.

[보조 branch]
- feature branch
- 새로 변경될 개발코드를 분리하고 각각 보존하는 역할을 합니다.
  즉, 보조 branch는 기능을 다 완성할 때까지 유지하고, 다 완성되면 develop branch 에 merge 하고
  결과가 좋지 못하면 버리는 방향을 취합니다.

[릴리즈 branch]
- release branch
- 배포를 위한 최종적인 버그 수정 등의 개발을 수행하는 브랜치를 말합니다.
- develop branch에 버전에 포함되는 기능이 merge 되었다면 QA를 통해 develop branch
  부터 release branch를 생성합니다.
- 배포 상태가 완료 되면 master branch로 병합시킵니다.
- release branch에서 버그 발생시 기능을 점검하여 수정하고, develop branch에도 적용합니다.
[핫픽스 branch]
- hotfix branch
- master branch에서 긴급하게 수정할 필요가 있을 때 master branch에서 분리하는 branch를 의미합니다.
- 버그 수정 후에는 다시 develop, master branch로 병합하며, tag를 통해 관련 정보를 기록합니다.
- hotfix branch는 긴급하게 버그를 수정하기 위해 생성되는 branch이기 때문에, 버그를 해결하면 보통 제거하는 일회성 branch입니다.
⚙️ Git-Flow 흐름

1) 신규 기능 개발
- 개발자는 develop branch 부터 본인이 신규 개발할 기능을 위한 feature branch를 생성한다.
- feature branch 에서 기능을 완성하면 develop branch 에 merge를 진행하게 된다.
2) 라이브 서버로 배포
- feature branch 가 모두 develop branch에 merge 되었다면 QA를 위해 release branch를 생성한다.
- release branch를 통해 오류가 확인된다면 release branch 내에서 수정을 진행한다.
- QA 및 테스트를 모두 통과했다면, 배포를 위해 release branch를 master branch로 merge 한다.
- 동기화를 위해 develop branch 쪽에도 merge를 진행한다.
3) 배포 후 관리
- 만일 배포된 라이브 서버(master) 에서 예상치 못한 버그가 발생한다면, hotfix branch를 생성하여 버그 픽스를 진행한다.
- 버그 수정 후 master 와 develop 양 쪽에 merge 하여 동기화 시킨다.

📌 GITHUB-FLOW 전략

앞에서 공부한 Git-flow 방식이 어떤가요?
관리해야할 branch가 많아 복잡하다는 생각이 들지 않나요? 🤔
사실 실제 개발을 진행하면서 Git-flow 방식이 무조건 필요하지는 않습니다. 물론 프로젝트 내에서 팀원끼리 상의하여 불필요한 부분을 제거 하여 Git-flow 방식을 최소화할 수 있지만, Git-flow 방식을 단순화한 branch 전략이 있습니다. 그것은 바로 Github-flow 방식입니다 👨‍💻

⚙️ GITHUB-FLOW 출현 배경

Git flow가 좋은 방식이지만 GitHub에 적용하기에는 복잡하다는 Scott Chacon의 판단에 따라 만들어진 새로운 깃 관리 방식입니다.
자동화 개념이 들어가 있다 라는 큰 특징이 존재하며 만일 자동화가 적용되어 있지 않은 곳에서만 수동으로 진행하면 됩니다.
Git-flow 에 비해 흐름이 단순해짐에 따라 그 규칙도 단순해졌습니다.
master branch 대한 규칙만 정확하게 정립되어 있다면 나머지 branch에 대해서는 특별한 관여를 하지 않으면 PR 기능을 사용하도록 권장합니다.

⚙️ GITHUB-FLOW 특징

release branch가 명확하게 구분되지 않은 시스템에서의 사용이 유용합니다.
GitHub 자체의 서비스 특성상 배포의 개념이 없는 시스템으로 되어있기 때문에 이 flow가 유용합니다.
웹 서비스들에 배포의 개념이 없어지고 있는 추세이기 때문에 앞으로도 Git flow에 비해 사용하기에 더 수월할 것입니다.
hotfix와 가장 작은 기능을 구분하지 않습니다.
모든 구분사항들도 결국 개발자가 전부 수정하는 일들 중 하나이기 때문입니다.
이 대신 구분하는 것은 우선 순위가 어떤 것이 더 높은지에 대한 것입니다.
branch 가 별도로 분리되어 있지 않고 master 로 부터 모든 branch 들이 뻗어나옵니다.
branch 의 성격은 branch 이름에 의해 좌우됩니다.

⚙️ GITHUB-FLOW 흐름

1) branch 생성

- branch 성격은 branch 이름을 통해 의도를 명확하게 드러내는 것이 매우 중요합니다.
- master branch는 항상 최신 상태며, stable 상태로 product 에 배포되는 branch 입니다.
- 항상 master branch에서 새로운 branch 생성합니다.

2) 개발 & 커밋 & 푸쉬

개발을 진행하면서 커밋을 남깁니다.
이때 branch와 함께 커밋 메세지에 의존해야하는데, 커밋 메세지를 최대한 상세하게 적어주는 것이 중요합니다.

원격지 브랜치로 수시로 push 합니다.

3) PR(Pull Request) 생성

피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request 를 생성합니다.

PR을 이용해 자신의 코드를 공유하고, 리뷰 받습니다.

merge 준비가 완료되었다면 master branch 반영을 요구합니다.

4) Review & Discussion

Pull Request가 master branch 쪽으로 합쳐진다면 곧장 라이브 서버에 배포되는 것과 다름이 없음으로, 그 전에 상세한 리뷰와 토의가 이루어집니다.

5) Test

Review 와 Discusstion이 끝났다면 해당 내용을 라이브 서버에 배포해봅니다.

버그 발생시, 곧장 master branch 내용을 다시 배포하여 초기화 시킵니다.

6) 최종 Merge

라이브 서버에 배포했음에도 문제가 발견되지 않았다면 그대로 master branch를 push 하고 배포를 진행합니다.

📌 Git flow VS Git hub flow

1개월 이상의 긴 호흡으로 개발하여 주기적으로 배포, QA 및 테스트, hotfix 등 수행할 수 있는 여력이 있는 팀이라면 Git flow가 적합하다 🔥

수시로 릴리즈 되어야 할 필요가 있는 서비스를 지속적으로 테스트하고 배포하는 팀이라면 Github flow 와 같은 간단한 work-flow가 적합하다 🔥

📌 마무리

현재 가장 대중적인 2가지의 Branch 전략을 살펴보았습니다 💡
개발을 함에 있어 조직의 규모, 서비스의 특징, 팀원들의 수준정도가 다양하기 때문에 같은 목적의 개발이라도 팀원끼리의 협의 결과에 따라 다른 branch 전략을 사용 할 수 있습니다 👨‍💻
또한 처음에 결정한 branch 전략이 개발 상황에 따라 변경될 수 도 있습니다.

따라서 팀원은 지속적인 협의를 통해 branching과 배포에 대한 전략을 결정하고 운영해야 하며, 이 전략은 공유되어 팀원들이 학습 & 체득화 할 수 있는 것이 중요하다는 결론을 내릴 수 있습니다 💪