Git Flow & MR & Code Review 효율적 사용 _ 기술블로그 보는!

 오늘은 Git Branch & Commit & MR 등에 대해 다뤄보려합니다! 

 사실 최근 Spring 프로젝트를 계획하면서 이 부분에 대해 많이 고민하게 되어 이 주제를 선택하게 되었습니다

 여러 프로젝트를 진행하면서 이 부분을 신경쓰려고 노력했지만 생각대로 잘 되지 않았던 부분들이 있었던 거 같아 한번 쯤 짚고 넘어가야 할거 같아 이렇게 글을 남겨요 😃

 

 여러분들도 git 을 사용하면서 엉망이 되어 버린 Git branch Tree를 보셨거나... 충돌나서..제대로 병합하지 못했던 경험..커밋 메세지 막 날려봤던 경험이 있으신가요..? 

 

 저도 초반에는 깃이 엉망진창이었던 경험이 있는데 프로젝트 하면서 이 부분들을 고려해야 한다는 점들을 배우면서 이 부분들을 신경쓰기 시작했어요! 그랬더니 확실히!!!!!! 협업 효율이 엄청나게 증가하더라구요.. 아직 부족한 부분들이 많아서 이 부분에 대해 같이 공부하면 좋을 거 같아 정리를 해보려 합니다. Let's Start!!✈️✈️✈️

 

오늘 정리할 글은 우아한 형제들의 기술 블로그 내용 + 제 경험을 기반으로 정리해 볼 예정이에요!:) 

-  https://techblog.woowahan.com/2553/

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

- https://techblog.woowahan.com/7152/

공통시스템개발팀 코드 리뷰 문화 개선 이야기 | 우아한형제들 기술블로그

---

 Git Flow란?!

 깃플로우는 깃에서 제공하는 '강력한 ' 브랜치 기능을 활용한 변경 이력 관리 전략을 말합니다. 소스코드를 관리하고 출시하기 위해 브랜치 관리 전략을 의미합니다. 프로젝트 팀 내에서 협의 하에 브랜치 생성, 병합, 삭제 등 관련 전략들을 세워나가는 것이 매우 중요합니다.

 가장 기본전략이라 할 수 있는 git flow 는 다음과 같은 규칙을 따릅니다!

[ 우아한 형제들에서 말하는 git flow 필요 예시 ]
- 이번 버전에 포함될 작업들과 이번 버전은 아니지만 언젠가 배포될 작업들이 함께 이뤄지는 개발 프로세스에서 git flow는 매우 효율적인 작업을 가능하게 한다! 이번 버전에 포함될 작업과 다음에 배포될 작업들을 병렬로 작업하기 위해서, 병렬로 처리하던 작업들이 완료가 되면 가까운 배포 주기에 포함시키기 위해서 git flow의 브랜치 관리 전략을 사용합니다. git flow를 통해 병렬 처리되던 작업들을 다른 작업들에 큰 영향을 미치지 않고 잘 반영할 수 있습니다 👍

---

Git Repository 구성  

출처 : 우아한 형제들 기술블로그

 

git flow 전략을 이해하기 앞서 git repository 구성에 대해 알아야합니다. ( 이 부분을 제대로 이해하지 못해 git을 쓰기 힘들어하는 친구들이 종종 있더라구요..)

 

 깃을 클론하거나 생성해서 본인의 컴퓨터에서 작업중인 깃 Repo 가 위 사진의 빨간 상자인 ' Local Repository' 입니다! Local Repository에서 작업한 내용을 Remote Repository에 Push를 하게 됩니다. 여기서 깃헙에 존재하는 레포를 Remote Repository라고 볼 수 있습니다. 위 그림의 파란 상자는 원래 github에 있는 프로젝트 repo ( 모두가 공유 ) 를 , 초록 상자는 파란 상자 레포로 부터 fork 해 온 레포라고 생각하면 됩니다. 따라서 Local Repo로 부터 push를 통해 fork하여 생성한 remote repo에 변경 사항을 반영하고 이후 작업에 이상이 없다면 최상단의 Upstream Remote Repo로 Pull Request를 보내게 됩니다. 이후 코드리뷰를 거친 후 최종 merge 되게 됩니다! 다시 새로운 작업을 할 때는 Local Repository에서 Upstream Repository를 Pull하여 작업을 이어갑니다. 

 

이렇게 Repository를 구조화함으로써 여러 변경 사항들을 안전하게 관리할 수 있고 공유 레포를 직접적으로 변경하지 않고 여러 사람들이 다양한 시도? 들을 해볼 수 있다는 장점이 있습니다 👍

---

Git-flow 전략 살펴보기

 git flow의 branch에는 5가지 종류가 있습니다. 최종 반영 및 항상 유지되는 메인 브랜치와 디벨롭 브랜치들 그리고 일정 기간 동안에만 유지되는 보조 브랜치들이 존재합니다. 각 브랜치는 아래와 같이 사용됩니다. 

 

• master : 제품으로 출시될 수 있는 브랜치
• develop : 다음 출시 버전을 개발하는 브랜치
• feature. : 기능을 개발하는 브랜치
• release. : 이번 출시 버전을 준비하는 브랜치
• hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

 

출처 : 우아한 형제들 기술블로그

먼저, master와 develop 브랜치 부터 살펴볼게요. develop 브랜치는 master브랜치 부터 시작된 브랜치로 상시로 버그를 수정한 커밋들이 추가되는 브랜치입니다. 새로운 기능 추가 작업이 있는 경우 develop브랜치에서 여러 feature 브랜치들을 생성해서 작업하게 됩니다. feature 브랜치들은 항상 develop 브랜치로 부터 출발하고 작업이 완료되면 다시 develop 브랜치와 merge 되는 브랜치입니다. 이번 버전으로 배포할 작업들이 모두 develop 브랜치로 합쳐졌다면 release 브랜치가 생성됩니다. 테스트 및 QA ( quality assurance) 를 진행하면서 발생 / 수정한 버그, 이슈들을 관리하는 브랜치가 release 브랜치 입니다. QA까지 완료되어 최종 배포 준비가 끝났다면 release 브랜치를 master와 develop 브랜치에 merge 합니다. 최종 출시는 master브랜치에서 되며 다음 버전의 기능 작업들은 develop 브랜치에서 새롭게 시작하는 feature 브랜치에서 시작하겠죠?! 

 

프로젝트를 진행하면서 master브랜치와 develop 브랜치 그리고 feature 브랜치까지는 다뤄본적은 있었어요.. 배포도 진행해본 경험이 있지만 release 브랜치를 만들어서 관리를 제대로 해보지는 못한 것 같네요..ㅠ  이 글을 정리하면서 이 외 브랜치인 hotfix, release브랜치들, Commit과 Pull Request도 체계적으로 다뤄보고 깃 브랜치 트리도 관리해봐야겠다는 생각이 들었습니다! 그리고 이전에 사용하던 브랜치들의 이름이 정말 잘 만든 이름인지, 브랜치의 생성 위치가 정말 맞는 위치였는지 고민해보게 되었어요 :) 

---

우아한 형제들의 git flow 살펴보기

1. 티켓 처리!

 우아한 형제들 기술블로그를 참고해서..우아한 형제들이 어떻게 git flow 를 관리하고 있는지 간단하게 요약해보려합니다. 

먼저 우아한 형제들은 다음과 같이 git repo와 브랜치를 두고 있다고 합니다. 

• Repositories 
  • Upstream ( Upstream Repository )
  • Origin ( Origin Repository )
• Branches 
  • feature-user ( 사용자 관련 기능을 구현하는 브랜치 )
  • bfm-100_login_layout ( 사용자 관련 기능 중 레이아웃 작업 브랜치)

 

 ' 하나의 티켓은 되도록 하나의 커밋 '으로 해결한다 ' 기능을 구현하기 전에 여러 개의 티켓으로 작업을 먼저 나누어 처리합니다. 

위 예시로 '로그인 레이아웃 생성' 이라는 티켓이 있고 이 티켓을 처리한다고 가정하면 git flow는 다음과 같습니다. 

 

1. upstream/featue-user 브랜치로부터  작업 브랜치인  bfm-100_login_layout 브랜치를 생성합니다. ( git fetch, git checkout ) 
2. 작업 브랜치에서 소스코드를 수정합니다. 
3. 작업 브랜치에서 변경 사항을 커밋합니다. 
4. 만약 커밋이 불필요하게 여러개 나누어져 있다면 squash ( 커밋 합치기 ) 를 진행합니다. 
5. 작업 브랜치를 upstream/feature-user에 rebase합니다. 
6. 작업 브랜치를 origin에 push 합니다. 
7. Github 페이지에서 bfm-100_login_layout 브랜치를 feature-user 브랜치에 merge는 Pull Request를 보냅니다. 
8. 같은 feature를 개발하는 동료들에게 리뷰 승인을 받고 자신의 Pull Requestfmf merge합니다. 

 

 

2. develop 변경사항 feature 로 가져오기 ( 필수는 아니에요! )

 브랜치 수명은 되도록 짧게 가지는 것이 좋지만 feature 브랜치에서 기능을 완료하는데 해야할 작업이 오~래 걸리는 경우, develop 브랜치에 변경 내용들을 가져와야 할 때가 생길 수 있습니다. 

 

1. feature-user 브랜치에 upstream/develop 브랜치를 merge 합니다. 
2. upstream/develop 브랜치에 변경사항이 merge 된 feature-user를 upstream에 push 합니다. 

 

3. 완료된 기능을 이번 출시 버전에 포함 시키기

 feature-usere 브랜치에서 작업하던 기능이 완료되면 출시 버전에 포함시키기 위해 develop 브랜치에 merge 합니다. 

 

1. develop 브랜치에 upstream/feature-user 브랜치를 merge 합니다. 
2. upstream/feature-user 기능이 merge된 develop 브랜치를 upstream에 push 합니다. 

 

4. QA 시작하기 & QA 중 버그 수정하기

 버전에 포함될 기능들이 다 들어왔다면 QA를 진행합니다. QA를 위한 release 브랜치를 생성하고 upstream에 push 하여 release 브랜치를 공유합니다. 이후 버그들이 발생하면 1. 티켓처리하기 방식과 같이 버그 티켓 처리 과정을 수행합니다. 

 

* QA 중 버그 수정 *

1.  release 브랜치에서 버그 티켓 브랜치 생성
2.  버그 수정
3.  작업 브랜치에 버그 수정 사항 커밋
4.  작업 브랜치를 origin에 push
5.  github에서 버그 티켓 브랜치를 release브랜치에 merge 하는 Pull Request 생성
6.  팀원들에게 승인 후 Pull Request 병합! 

 

5. 앱 출시

 버그 수정이 완료되었다면 출시를 위해 release브랜치를 master 와 develop 브랜치에 merge하고 최종적으로 master 브랜치에서 버전 태그를 달아주니다. 

 

1.  release 브랜치를 최신 상태로 갱신 후 develop 브랜치에 merge합니다. 
2.  develop 브랜치를 upstream 에 push 
3. release 브랜치를 Master 브랜치에 merge 합니다. 
4. 버전 태그를 추가합니다. ( git tag )
5. master 브랜치와 태그를 upstream에 push 합니다. 

---

Git commit & MR  규칙 for Code Review

 지금부터는 git commit 메세지 남기는 법 , Pull Request 생성 하는 법, 코드 리뷰 방법에 대해 간단히 이야기해보려 합니다. 

먼저, git commit message 다루는 법부터 정리해볼게요!

 

Git commit Message

깃 커밋에도 컨벤션이 있습니다. 깃 커밋 메세지의 구조는 다음과 같이 제목, 본문, 꼬리말 세가지 파트로 나누어져 있고 각 파트는 빈줄을 두어 구분합니다. 

type : subject 

body 

fopter

 

커밋 type에는 다음과 같은 종류들이 있고 타입은 태그와 제목으로 구성되고 영어로 쓰되 첫 문자는 대문자로 합니다. 

 

* 태그 : 제목 형태 * ( 제목은 최대 50글자가 넘지 않도록 하고 마침표와 특수 기호는 사용하지 않아요 / 개조식 구문으로! ) 

feat : 새로운 기능 추가
fix : 버그 수정
docs : 문서 수정
style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
refactor : 코드 리팩터링
test : 테스트 코드, 리팩터링 테스트 코드 추가
chore : 빌드 업무 수정, 패키지 매니저 수정

 

body의 경우에는 한 줄당 72자 내로 작성하고 상세히 작성하는 것이 원칙입니다. 

footer의 경우에는 필수는 아니며 보통 "유형 : # 이슈번호" 형식으로 많이 사용합니다. ( ex . Fixes : # 30 )

이슈 트래거 유형

1. Fixes : 이슈 수정 중 ( 미완 )
2. Resolves : 이슈를 해결했을 때 사용

3. Ref : 참고할 이슈가 있을 때

4. Related to : 해당 커밋에 관련된 이슈 번호 

 

그럼 커밋 메세지의 최종 형식을 봐볼까요 ?

Feat: "회원 가입 기능 구현"

SMS, 이메일 중복확인 API 개발

Resolves: #123
Ref: #456
Related to: #48, #45

 

Merge Request & Pull Request  

 코드리뷰가 늦은 이유는 바로! Merge Request가 일관적으로 ! 직관적으로 ! 잘 작성되지 못한 것들이 많아서이다. 우아한 형제들에서 알려준 MR 템플릿은 다음과 같다.

# 해결하려는 문제가 무엇인가요?
*

# 어떻게 해결했나요?
*

## Attachment
* 이번 MR 의 Front 동작을 이해를 돕는 GIF 파일 첨부!
* 리뷰어의 이해를 돕기 위한 모듈/클래스 설계에 대한 Diagram 포함!

* 실제 작성 예시 *

# 해결하려는 문제가 무엇인가요?
* TS2305: Module '"react-router"' has no exported member 'useHistory'. 에러를 내면서 빌드가 깨집니다.
   다른 모듈에 의해 react-router 버전이 5 -> 6으로 올라간 게 문제입니다.

# 어떻게 해결했나요?
* 사용하는 react-router의 버전을 package.json에 명시합니다.

 

 코드 리뷰 규칙 문서를 만드는 것도 도움이 된다고 합니다. MR을 다는 것 뿐 아니라 코멘트 방식, 범위 등이 달라서 코드리뷰가 어려운 경우가 발생하는 경우가 있으므로 체계화 된 문서를 만드는 것도 좋습니다. 

 또 다른 방법으로는 D-n 라벨을 자동화하는 것 ( 날짜 확인 ), 알림 발송 등 다양한 방법이 있는 거 같습니다 : ) => 좀 더 상세한 내용은 우아한 형제들 기술 블로그를 참조!  ( https://techblog.woowahan.com/7152/  )

 

추가적으로 카카오에서도 코드 리뷰 가이드를 제공해주고 있네요! 이것도 함께 참고해보면 좋을 거 같습니다~!

- https://tech.kakao.com/2022/03/17/2022-newkrew-onboarding-codereview/

효과적인 코드리뷰를 위한 리뷰어의 자세

 

---

git Issue 

 깃 이슈는 프로젝트의 작업, 개선 사항 및 버그를 추적하는 좋은 방법 중 하나입니다. 프로젝트 기획, 새롭게 추가될 기능, 버그와 수정사항 모든 것들을 이슈에 포함시킬 수 있습니다. 모든 활동 내역에 대해서 이슈를 등록하고 등록된 이슈를 기반으로 협업을 이어갑니다!

 

 git hub에서는 issue 관리를 위한 템플릿을 제공하고 있으며 여기서 이슈 등록, 수정, 삭제 등이 가능합니다. 생성 방법은 아래 블로그를 참고! 

- https://hyeonic.tistory.com/181

[git, github] git issue 생성 및 작성 방법 (1)

---

기타 git 관리 Tools 

 github와 연동해서 git flow 를 관리하기 좋은 툴들을 정리해보려합니다. 아래 툴 정보들을 남겨볼게요!

• 소스트리 ( Git GUI ) : https://ux.stories.pe.kr/181  
• 깃 크라켄 ( Git GUI ) : https://kindle14.tistory.com/50
• 지라 ( 프로젝트 관리, 추적 ) : https://blog.jandi.com/ko/2022/03/31/how-to-jira-like-a-pro/
• bitbucket ( git code 관리 )  : https://www.atlassian.com/ko/software/bitbucket

Bitbucket | Git solution for teams using Jira

일 잘하는 팀의 실전 ‘지라(Jira)’ 활용법 - 업무용 협업툴 JANDI 블로그

[Git / GUI] 깃크라켄(GitKraken) 설치 및 사용하기

Git GUI 소스트리(SourceTree) 설치방법과 사용방법

 

---

 

 이번 글을 작성하면서 git의 다양한 기능들을 좀 더 제대로! 알고써야 겠다는 생각이 정말 많이 들었어요!

학부에서 진행하는 프로젝트 보다 훨씬 큰 프로젝트들을 실무에서 많이 마주칠텐데.. 이런 부분에 대해 무지하다면 정말..( 상상하기도 싫은..ㅎ) 그래서 앞으로의 프로젝트에 있어 많이 신경 써야 겠다는 다짐과 함께 팀원들과 관련 내용을 바로 공유..중 입니다! 

 

뿐만 아니라..그동안 마구잡이로 날렸던 커밋메세지... 많이 반성해야겠다.....라는...생각이...ㅎ

되도록 맞춰쓰려고 노력은 했었으나..가끔은 어떤 타입의 메세지인지 제대로 구분하지 못하고 올린 커밋들이 있었다는..( 반성합니다 )

커밋 메세지 뿐 아니라 앞으로는 이슈 관리도 도전해보고 싶습니다!!!

 

 다음 번 글로는 스프링 단위테스트, 통합테스트 등 TDD 의 중요성에 대해 다뤄보려 해요! 많이 부족한 글이지만..쓰다보면 점차 늘겠죠?!

 TDD도 개발에 있어 '매우' 중요한 부분인데 우리가 어려워하는 파트라 한번 정리해 보면 좋을 듯해 다음 번 글로 남겨보려합니다! 부족하지만 다음 글도 기대해주세요~! 🙋🏻‍♀️

---