[Git] Git 브랜치 전략 : Git-Flow에 대하여

* 회사에서 용의한 코드리뷰 및 배포 관리를 위해서 기존의 Git 브랜치 전략을 변경하겠다는 이슈가 있었습니다.
깃 브랜치 전략에 대한 내용은 어느 회사든 관심을 갖는 이슈인 것 같다는 생각...

이전에 타 회사 면접 볼 때에도 타 기업에서 인턴 할 때에는 어떻게 브랜치 관리를 했는지에 대한 질문을 받았었던걸 보면 말이죠!

개발을 하며 느낀점은 아직 초초초 주니어인 저에게 개발은 언어에 대한 어려움 보다 규칙을 정하고(혹은 정해져 있는) 틀에 맞춰 깔끔하게 프로그래밍 하는게 정말 어려운 것 같아요. 지난 주 코드도 다시보면 비합리적인 요소가 발견되네요...

 

 

📌Git Flow 란?

Git으로 개발할 때 표준처럼 사용되는 방법론

Git Flow 전략

• master - 제품 출시 브랜치
• develop - 다음 출시 버전 개발 브랜치
• feature - 기능 개발 브랜치
• release - 이번 출시 버전 준비 브랜치
• hotfix - 출시 버전 버그 수정 브랜치

- Merge 기준

feature => develope=> release (QA 테스트) => master (출시) => (버그해결) => hotfix

 

다른 회사에서는 어떻게 사용 중일까요?

우아한 형제들 *17년 글을 참고한 내용으로 21년인 현재와 다를 것으로 예상합니다

- Git flow 사용 이유

변경된 개발 프로세스에 의해 (우선순위에 따라 나열된 작업 중 우선순위가 높은 작업부터 하나씩 선택하여 작업을 나눔)

- Git-flow 사용 방법

• Repositories
  
  • upstream
  • orign
• Branches
  • reature-user
  • bfm-100_login_layout

1. upstream/feature-user 브랜치에서 작업 브랜치(bfm-100_login_layout)를 생성합니다.
   (feature-user)]$ git fetch upstream
   (feature-user)]$ git checkout -b bfm-100_login_layout –track upstream/feature-user
2. 작업 브랜치에서 소스코드를 수정합니다. (뚝딱뚝딱 :hammer:)
3. 작업 브랜치에서 변경사항을 커밋합니다. (보통은 vi editor에서 커밋 메세지를 작성 함)
   (bfm-100_login_layout)]$ git commit -m "BFM-100 로그인 화면 레이아웃 생성"
4. 만약 커밋이 불필요하게 어려 개로 나뉘어져 있다면 squash를 합니다. (커밋 2개를 합쳐야 한다면)
   (bfm-100_login_layout)]$ git rebase -i HEAD~2
5. 작업 브랜치를 upstream/feature-user에 rebase합니다.
   (bfm-100_login_layout)]$ git pull –rebase upstream feature-user
6. 작업 브랜치를 origin에 push합니다.
   (bfm-100_login_layout)]$ git push origin bfm-100_login_layout
7. Github에서 bfm-100_login_layout 브랜치를 feature-user에 merge하는 Pull Request를 생성합니다.
8. 같은 feature를 개발하는 동료에게 리뷰 승인을 받은 후 자신의 Pull Request를 merge합니다. 만약 혼자 feature를 개발한다면 1~2명의 동료에게 리뷰 승인을 받은 후 Pull Request를 merge합니다.

4,5 번의 과정은 커밋 그래프를 단순하게 가져가기 위함

 

🤔사견

이전 기업에서 인턴 근무할 때는 JIRA Works와 GitBucket 연동해서 이슈 create closed로 브랜치 관리해서 이슈 별 브랜치 관리, 코드 리뷰가 좀 더 용이했던 기억이 있습니다.

 지금 팀에서는 따로 브랜치 생성 전 해당 브랜치에 대한 이슈 생성을 하지 않고 있는데, 물론 작업 속도는 더 빠를 수 있지만 이후 수십개가 쌓인 브랜치에 대한 관리가 너무 어렵지 않나? 하는 의문이 들곤한달까요?

 

 우아한형제들의 커밋 전략을 보니 (비록 17년도의 방식이지만..) 커밋에 대한 squash 전략이 매우 마음에 들네요.

개인적으로 1일 최소 1커밋에 대한 버릇이 있다보니 커밋 그래프가 너무 쓸데없이 내용이 많아 지는 것 같아서요!

 그리고 아직 코드 리뷰해보면 사소한 것도 고칠게 많이 보이기 때문에 더더욱...

 

Git-flow에 대해서 대충 듣기만 했지 "왜 진작 제대로 읽어볼 생각을 하지 않았을까?" 하는 생각이 드네요. 그랬다면 이전에 프로젝트할 때 조금 더 구조화된 브랜치 정책을 가져갈 수 있었을 텐데...라고 반성하게 되네요.

역시 개발 방법론에 대한 공부는 끊임이 하자는 다짐을 한번 더 해봅니다.

 

 

 

---

📎참고

ATLASSIAN Bitbucket

우아한형제들 기술 블로그