[Git / Git Flow] Git Flow 수립 도전기!

💡Git Flow 란?

• 버전 관리와 개발자 간의 분업을 위해 일종의 규칙과 프로세스에 맞춰 git을 사용하는 것
• 상황에 맞게 브랜치를 만들고 머지 
• 기본적인 틀이 있지만 팀바팀! 

 

기본적으로 git flow에서 사용되는 브랜치는 main / dev / feature / hotfix 로 이루어져 있다. 브랜치 별로 각 역할과 의미가 있지만 팀마다 조금씩 다르게 규칙을 정의해 운영하기도 한다.

 

현재 진행 중인 사이드 프로젝트 '어비로' 가 구글 출시 심사 과정에 있고, 본격적인 운영에 앞서 Git Flow를 적용하는 것이 좋다는 말을 들었다. 그래서 같은 팀의 ios 개발자이신 성훈님의 가르침과 여러가지 사항들을 고려해 ‘어비로’ 만의 git flow 를 구축해 운영해보려고 한다.

 

 

✔️ Main

• 최종 배포 버전 브랜치 / 운영 브랜치
• 모든 개발이 완료되고, 최종 배포를 할 경우 이곳으로 merge 한다 (배포를 위해 모이는 곳)
• 만약 심사과정 혹은 배포 이후 오류/버그/피드백가 발견된 경우, hotfix 브랜치에서 처리한다
• (추후 : 실제 플레이스토어에 출시하기 위한 배포를 main 브랜치에서 자동화 하고자 한다)

✔️ Dev

• 최종 개발 버전 브랜치
• 새로운 개발이 시작되었을때, Dev 브랜치에서 각 기능별로 Feature 브랜치들을 파서 개발을 시작한다.
• Feature브랜치에서 개발이 완료되면 이곳으로 merge 한다 (개발이 완료되면 모이는 곳)
• (추후 : 실제 출시용 배포 전 내부 테스트를 위한 배포를 Dev 브랜치에서 자동화 하고자 한다)

✔️ Feature

• 개발 중인 각 기능들을 각각의 feature 브랜치로 만들어 개발
  예를 들어 ‘사진 업로드 기능’ 이 추가되었을 경우, ‘가게 등록 사진 업로드’ 와 ‘후기 등록 사진 업로드’ 이렇게 크게 2가지 기능으로 나뉠 수 있고 각각 Feature/image_resgister 와 Feature/image_review 이렇게 브랜치를 나눠 각각 개발할 수 있다
  (개발자가 여러명인 경우, 각자 맡은 기능 개발을 브랜치로 따로 만들어 개발하면 관리가 쉽다)

✔️ Hotfix

• 내부 테스트 과정에서, 혹은 배포 후 발생하는 오류 / 버그 / 피드백을 빠르게 처리하기 위한 브랜치이다

✔️ Release

• 배포를 위한 브랜치이다. main 에서 처리해도 되지만 이렇게 버전별 릴리즈 브랜치를 만들어 dev에서 모아진 최종 개발 결과물을 배포한다. Ex) release/release-1.0.0
• 릴리즈용이기 때문에 해당 릴리즈가 끝나면 해당 브랜치는 삭제된다
• 이렇게 하게 되면 CI/CD 구축이 힘들수도 있지 않을까 싶다
  • CI/CD 구축이라는 것이 특정 브랜치에 배포하고자 하는 결과물이 merge 되면 자동으로 배포가 되는 자동화를 구축하는 것인데, 이렇게 매번 다른 브랜치를 생성해 사용하게 되면 구축이 어렵지 않을까?

---

 

과거의 내가 Git을 사용하던 방식

이것도 사실 매번 냅다 main만 사용하다가 좀 없어보여서

릴리즈 버전별로 브랜치 만들어 개발하고 배포할때마다 main 에 merge 하려고 시도했던 흔적…ㅎㅎ

 

 

현재 (Git Flow 적용!)

내가 그동안 뭘 한건지 모르겠지만,,,,,, 새마음 새뜻으로 시작하기 위해 현재 브랜치들을 정리해주었다….

1. 1.0.0 브랜치 제거
2. 1.1.0 브랜치 → dev 로 변경
   1. 가장 최신 코드들이 반영되어 있는 브랜치이므로 이걸 dev로 변경해주었다.
3. dev 를 main 으로 merge
   1. 현재 dev의 코드로 aab 파일을 만들어 프로덕션 배포한 상태이기 때문에 dev 내용을 main 으로 merge 시켜 상태를 맞춰 주었다

나의 경우, release 브랜치는 따로 운영하지 않고, main 브랜치를 release 브랜치처럼 사용하려고 한다.

그리고 어비로 official Repository를 fork 해서 upstream 방식으로 운영하고 있는데

fork 한 내 저장소를 → origin 이라고 부르고

official Repository를 → upstream 이라고 부르겠다.

추후에 origin의 main에 배포하면 내부테스트용 앱이 배포되고, upstream의 main에 배포하면 실제 출시용 앱이 배포되도록 CI/CD를 구축해보는 것도 나의 목표이다. (바뀔 수도 있음)

 

 

💡 HotFix 만들어 보기

지금 앱을 출시하기 위해 프로덕션에 올려 14일간 테스트중인데, 급하게 수정할 사항이 생겼다

• 안드로이드 API 수준 올리기(target SDK 를 34 = API 수준 14) (구글 요청)
• ‘가게 등록 - 가게 검색’ 기능에서 발생하는 버그 수정

앱을 배포했는데 발생하는 문제이기 때문에 hotfix를 실습하기 딱 좋다고 생각했다.

 

1. main 브랜치에서 hotfix 만들어주기 & 작업하기

 

   1-1.  hotfix는 main 브랜치에서 처리하는 것으로 정했기 때문에 여기서 브랜치를 만들어준다

 

   1-2.  local 에서 먼저 브랜치를 만들어 주고, 이걸 원격저장소로 push 해줬다

 

 

2. 작업 완료된 hotfix 브랜치를 main 과 dev로 merge 하기 위해 PR 올리기

 

   2-1.  나는 hotfix의 내용이 빠르게 배포 버전에 반영될 수 있도록 하는 것이 중요하다고 생각했다.

           그래서 아래 처럼 main에 PR을 진행했다.

 

   2-2.  그리고 dev 브랜치 또한 버그가 수정된 main의 상태와 맞춰줘야 하는데

             원격 저장소에서 dev로 merge 해주거나 상황에 따라 PR을 올려 진행해주었다. 

 

 

3. 로컬에서 브랜치별로 fetch-pull 해줘서 원격의 내용을 반영

이제 원격의 main 과 dev 는 hotfix를 통해 버그를 수정한 내용까지 모두 반영되어 있을 것이다.
a 또는 b의 절차를 걸치게 되면, 원격저장소에서 계속 PR을 올렸기 때문에 로컬에는 버그 수정 사항이 반영 되어 있지 않다.

 

또한 협업 상황에서는 내가 아니더라도 다른 누군가가 hotfixt 작업을 할 수도 있다.

그런 경우 나는 내 로컬의 main 과 dev에서 fetch-pull 수행해줘야 버그 수정 사항을 반영을 내 로컬 저장소에도 반영할 수 있다

git fetch

git checkout dev # 로컬에서 dev 브랜치로 전환
git pull

git checkout main # 로컬에서 main 브랜치로 전환
git pull

 

 

git flow 수립 첫 도전 & hotfix 만들어보기 끝~~

 

+) 데보션에 올라온 글 중에 Git Flow를 야구에 비유해 쉽고 재미있게 설명하는 글이 있어서 공유해본다! 

https://devocean.sk.com//blog/techBoardDetail.do?ID=166708

야구로 쉽게 이해해 보는 Git Flow 전략 이야기

 

 

 

[참고자료]

Git 뉴비를 위한 기초 사용법 - 버전 관리

[git] 효율적인 협업을 위한 Git-Flow 이해하기 (사용하는 branch 와 repository 구성)

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

[협업] 협업을 위한 Git Flow 설정하기

(upstream)

[Git] fork한 repository 동기화부터 pull request (PR)를 보내기까지

(merge 방식)

Github Merge 방식 이해하기