[Git] Git Flow 전략의 이해와 협업 시 활용

velog에서 보는 게 더 가독성이 좋습니다 :)

velog link

 

깃허브를 이용한 팀 프로젝트에서 브랜치를 규칙 없이 무분별하게 만들면
히스토리가 아주 복잡해지고, 팀원 간의 소통도 힘들어진다.

오늘은 브랜치 관리 전략 중 Git Flow에 대해 공부한 내용을 정리해보고자 한다.

Git Flow

말 그대로 flow, 흐름이다.
시간의 흐름에 따라 각 브랜치들이 어떻게 상호작용하여 메인 브랜치가 완성되는지에 집중해보면 될 것 같다.

구성 브랜치

• main
  배포(제품으로 출시되는)하는 주 브랜치이다.
  항상 배포 가능한 안정적인 상태를 유지해야 한다.
• develop
  다음 출시 버전을 만들기 위해 팀원들이 변경 내용을 모으는 개발 브랜치이다.
  새 기능(feature)들과 버그 수정(release/hotfix)들이 모이는 브랜치이다.
• feature
  새로운 기능을 개발하는 브랜치이다.
  독립적인 작업을 위한 브랜치로, develop 브랜치에서 시작한다.
  기능 개발이 완성되면, 나중에 develop 브랜치로 병합한다.
  • feature/user, feature/payment 식으로 feature임을 명시하면 좋다.
• release
  이번에 출시할 버전을 준비하는 브랜치이다.
  develop 브랜치에서 모든 feature 브랜치가 병합되면 develop 브랜치로부터 release 브랜치를 생성하여 테스트와 버그 수정 단계를 거친다.
  테스트와 버그 수정을 마치고 release 브랜치가 안정화되면 main, develop 브랜치에 병합한다.
• hotfix
  배포(출시)한 버전에서 버그가 발생하면 긴급 수정이 필요하다.
  이때, main 브랜치로부터 hotfix 브랜치를 생성한다.
  빠르게 버그를 수정한 후, main과 develop 브랜치에 병합한다.

개인적인 의견으로는 main, develop, feature 브랜치를 기본으로

팀의 특성과 필요에 따라 release와 hotfix 브랜치를 옵션으로 추가하면 될 것 같다.

시나리오

깃 플로우를 설명하는 글들 중에서 아주 유명한 그림이다. 이 그림을 참고해 시나리오를 그려보자.

이미지 출처: 🔗

1. 리포지터리를 생성한다. 함께 main 브랜치 0.1이 생성된다.
2. main 0.1 브랜치로부터 develop 브랜치가 생성된다. 필요에 따라 초기화 작업을 한다.
3. 본격적인 기능 개발을 위해 develop 브랜치로부터 feature 브랜치들을 만든다.
4. feature 브랜치에서 작업을 하며 완성 되면 develop 브랜치에 병합하기도 하며 업데이트 해간다.
5. 이번 출시를 위해 필요한 기능들(그림엣는 Major feature for next release)이 모두 develop에 병합되면 develop 브랜치로부터 release 브랜치를 만든다.
6. release 브랜치에서는 테스트를 하며 버그를 수정한다. 이렇게 완성된 버전은 develop과 main 브랜치에 병합하며 정식 출시 버전 main 1.0이 된다.

중간 중간 hotfix는 main에서 충돌이 나면 언제든지 생성되어 해결 후 develop과 main에 병합된다.

---

꽤나 체계적인 방법이다.
그러나 깃 플로우를 모든 프로젝트에 적용할 필요는 없고,
팀의 목적에 맞게 잘 변형하면 된다.

 

다만 언제든지 지켜야할 점은 커밋을 남기는 방법이라고 생각한다.
"하나의 티켓은 되도록 하나의 커밋으로 한다."
이때 티켓은 하나의 개발 작업 또는 이슈를 말한다. 즉, 한 작업을 여러 커밋으로 복잡하게 나누어 올리지 말란 말이다.

---

작은 규모의 팀이라면 한 리포지터리에서 함께 작업하면 되겠지만
어느 정도 규모 있는 프로젝트라면 두 개의 리포지터리를 쓰기도 한다.

우아한형제들의 기술 블로그와 우아한테크코스 달록팀의 기술 블로그를 참고하여 내가 직접 써볼만한 방식으로 정리해보았다.

팀 협업에서의 Git Flow 적용

개발 협업과 소스 코드 관리를 효율적으로 하기 위해서 두 개의 리포지터리를 사용하기도 한다. 각 리포지터리는 다음과 같다.

• Upstream Repository
  원본 리포지터리로, 팀 전체가 참조하는 공식 리포지터리이다.
• Origin Repository
  팀원 개인이 작업하기 위해 Upstream 리포지터리에서 내 원격 저장소로 복제(fork)해온 리포지터리이다.
  • 각 팀원들은 Origin 리포지터리의 로컬에서 작업한다.
  • 로컬에서 작업한 내용을 먼저 Origin 리포지터리에 푸시한다.
  • 팀 프로젝트의 최신 코드는 Upstream 리포지터리에서 가져온다.
  • 나의 Origin 리포지터리에서 Upstream 리포지터리 연결 명령어

    $ git remote add upstream [upstream repository url]

적용 예시

이런 방식으로 진행될 것이다.

유저-로그인 기능을 만들어야 한다고 가정하자.

1. Upstream Remote Repository를 기반으로 나의 원격 개인 저장소에 Fork 한다.
2. 나의 Origin Repository와 연결된 로컬 리포지터리를 생성한다.
   i. $ git clone [Origin Repository url
3. 나의 로컬 리포지터리에 Upstream 리포지터리를 등록한다.
   i. $ git remote add upstream [Upstream Repository url]
   ii. 이제 작업할 때는 업스트림으로부터 최신 코드를 pull해온다.
4. 나의 로컬 리포지터리에서 feature/user-login 브랜치를 생성하자.
   i. $ git checkout -b feature/user-login
   ii. 현재 feature/user-login 브랜치에 있는 상태
5. upstream의 develop 브랜치에서 최신 소스 코드를 받아 온다.
   i. $ git fetch upstream
   ii. $ git rebase upstream/develop
   iii. rebase는 내 로컬 브랜치의 커밋(A, B, C)을 Upstream 브랜치의 최신 상태(D, E) 위로 다시 배치한다 → 히스토리가 직선형으로 정리 (참고: https://tlatmsrud.tistory.com/156)
6. (선택) 만약 리베이스 후 다른 팀원이 Upstream develop에 새로운 코드를 업데이트해 다시 최신 코드를 받아와야 한다면 pull을 하면 된다.
   i. $ git pull upstream develop`
7. 최신 코드로 업데이트된 나의 로컬 feature/user-login 브랜치에서 작업한다.
8. 작업이 끝나면 Origin Repository로 푸시한다.
   i. $ git push origin feature/user-login
9. 이제 나의 로컬 작업 사항을 Upstream develop 브랜치로 보내기 위해 Pull Request를 하자.
   i. base repository: Upstream Repository / base: develop
   ii. head repository: Origin Repository / compare: feature/user-login

---

이러한 브랜치 전략과 팀 프로젝트에 빠르게 익숙해지는 가장 좋은 방법은
아무래도 프로젝트를 많이 해보는 방법 같다.

 

참고자료:

https://nvie.com/posts/a-successful-git-branching-model/
https://techblog.woowahan.com/2553/
https://dallog.github.io/git-branch-strategy/