01. Git 관리 전략

1) git flow, github flow, gitlab flow 의 개념

1. Git Flow

(사진 출처: https://www.youtube.com/watch?v=w2r0oLFtXAw)

git flow 는 총 5 종류의 브랜치를 활용한다.

주의할 점은 master, develop 은 각 브랜치가 영구적으로 존재하지만, hotfix, release, feature 브랜치의 경우 필요할 때마다 브랜치를 만들고, 머지가 되면 삭제된다.

전체적인 merge 순서는 다음과 같다. (merge 할 때는 항상 —-no-ff 옵션을 붙안다.)

feature → develop → release → master

1. master 브랜치 (main 브랜치)
   소비자가 사용하는 제품이 존재하는 (배포될 코드가 있는) 브랜치이다.
   release 브랜치로부터 pull request 받는다.

   • 부모 브랜치: -
   • 자손 브랜치 (분기해서 생성되는 브랜치): hotfix, develop
   • PR받는 브랜치 (pull request 받는 브랜치): release
   • PR나가는 브랜치 (pull request 보내는 브랜치): -

2. hotfix 브랜치
   배포된 서비스에 대한 긴급 버그 수정을 진행하는 브랜치이다.
   hotfix 브랜치는 만들 때 hotfix-* (hotfix-1) 과 같은 형태로 이름을 지정해서 만든다.
   수정이 완료되면, develop 과 master 브랜치 각각에 pr 을 날린다.

   • 부모 브랜치: master
   • 자손 브랜치: -
   • PR받는 브랜치: -
   • PR나가는 브랜치: develop, master

3. release 브랜치
   배포 전에 제품을 테스트 (QA, 품질검사) 하는 브랜치이다.
   release 브랜치는 만들 때 release-* (release-1) 과 같은 형태로 이름을 지정해서 만든다.
   테스트가 정상적으로 완료되면, develop 과 master 브랜치 각각에 pr 을 날립니다. pr merge 가 완료되면, 브랜치를 삭제한다.

   • 부모 브랜치: develop
   • 자손 브랜치: -
   • PR받는 브랜치: -
   • PR나가는 브랜치: develop, master

4. develop 브랜치
   개발 단계의 코드가 있는 (개발의 중심) 브랜치이다.
   개발 자체는 feature 브랜치에서 진행하고, 기능 하나 구현이 완료되면 develop 브랜치로 pr 을 날린다.
   이러한 과정을 반복하면서 특정 단계까지 개발이 완료되면, develop 브랜치를 베이스로 해서 테스트를 위한 release 브랜치를 새롭게 만든다.

   • 부모 브랜치: master
   • 자손 브랜치: feature, release
   • PR받는 브랜치: feature
   • PR나가는 브랜치: -

5. feature 브랜치
   특정한 기능 (단위 기능) 을 구현하는 브랜치이다.
   feature 브랜치는 만들 때 feature/* (feature/기능명) 과 같은 형태로 이름을 지정해서 만든다.
   기능 구현이 완료되면, develop 브랜치로 pr 을 날립니다. merge 되면 브랜치는 삭제된다.

   • 부모 브랜치: develop
   • 자손 브랜치: -
   • PR받는 브랜치: -
   • PR나가는 브랜치: develop

Git Flow 는 다음과 같은 경우에 유용하다.

• 큰 규모의 팀
• 퀄리티 보장이 중요한 프로덕트
• release 된 프로덕트에 대한 관리 사이클이 긴 경우

2. Github Flow

(사진 출처: https://www.youtube.com/watch?v=w2r0oLFtXAw)

Github Flow 는 딱 2가지 종류의 브랜치만 사용한다.
Git Flow 는 큰 규모의 팀 + 안정성이 매우 중요한 서비스에서 사용하면 좋지만, 작은 규모의 팀 + 빠른 개발과 업데이트가 중요한 서비스에서는 오히려 비효율적으로 작용한다.

그렇기 때문에 Github Flow 는 단 2개의 브랜치만을 사용하며, 배포용 브랜치인 master, 각 단위 기능 구현을 위한 브랜치인 feature 로 구성된다. feature 브랜치는 merge 후에 삭제된다.

1. master 브랜치 (main 브랜치)
   소비자가 사용하는 제품이 존재하는 (배포될 코드가 있는) 브랜치이다.
   (해당 브랜치는 push 를 받으면 자동으로 실제 서비스로 배포되도록 설정되어있있다.)
   feature 브랜치에서 단위 기능 구현이 완료될 때마다 pull request 를 받는다. (여기서 해당 브랜치를 merge 하기 전에 테스트를 진행한다.)

   • 부모 브랜치: -
   • 자손 브랜치 (분기해서 생성되는 브랜치): feature
   • PR받는 브랜치 (pull request 받는 브랜치): feature
   • PR나가는 브랜치 (pull request 보내는 브랜치): -

2. feature 브랜치
   특정한 기능 (단위 기능) 을 구현하는 브랜치이다.
   feature 브랜치는 만들 때 git flow 보다 더 구체적으로, 명확하게 작업명을 작성해서 만든다.
   (단순히 feature/* 가 아니라 버그 해결인지, 기능 추가인지 등을 명확히 명시한다.)
   기능 구현이 완료되면, master 브랜치로 pr 을 날린다.
   merge 되면 브랜치는 삭제된다.

   • 부모 브랜치: master
   • 자손 브랜치 (분기해서 생성되는 브랜치): -
   • PR받는 브랜치 (pull request 받는 브랜치): -
   • PR나가는 브랜치 (pull request 보내는 브랜치): master

Github Flow 는 다음과 같은 경우에 유용하다.

• 작은 규모의 팀
• release 된 프로덕트에 대한 관리 사이클이 짧은 경우 (업데이트 주기가 짧은 경우)
• 빠른 배포와 관리가 필요한 경우

3. Gitlab Flow

(사진 출처: https://www.youtube.com/watch?v=w2r0oLFtXAw)

Gitlab Flow 는 4종류의 브랜치를 사용한다.
github flow 는 테스트를 위한 브랜치가 없고, 배포용 브랜치가 따로 없기 때문에 큰 규모의 서비스에는 적합하지 않다. 그래서 github flow 의 단순함과 git flow 의 체계적인 관리를 합쳐서 절충적으로 git 을 활용하는 방식이 바로 gitlab flow 이다.
pre-production 브랜치가 테스트를 담당하고, master 브랜치가 개발용 브랜치로 역할한다.
feature 브랜치는 다른 flow 와 마찬가지로 merge 되면 삭제됩니다.

1. production 브랜치
   소비자가 사용하는 제품이 존재하는 (배포될 코드가 있는) 브랜치이다.
   pre-production 브랜치로부터 pull request 받는다.

   • 부모 브랜치: master
   • 자손 브랜치 (분기해서 생성되는 브랜치): -
   • PR받는 브랜치 (pull request 받는 브랜치): pre-production
   • PR나가는 브랜치 (pull request 보내는 브랜치): -

2. pre-production 브랜치
   배포 전에 제품을 테스트 (QA, 품질검사) 하는 브랜치이다.
   테스트가 정상적으로 완료되면, production 과 master 에 각각 pr 을 날린다.

   • 부모 브랜치: master
   • 자손 브랜치: -
   • PR받는 브랜치: master
   • PR나가는 브랜치: production, master

3. master 브랜치 (main 브랜치)
   개발 단계의 코드가 있는 (개발의 중심) 브랜치이다.
   개발 자체는 feature 브랜치에서 진행하고, 기능 하나 구현이 완료되면 master 브랜치가 pr 을 받는다.
   이러한 과정을 반복하면서 특정 단계까지 개발이 완료되면, pre-production 으로 pr 을 날린다.

   • 부모 브랜치: -
   • 자손 브랜치: feature
   • PR받는 브랜치: feature, pre-production
   • PR나가는 브랜치: pre-production

4. feature 브랜치
   특정한 기능 (단위 기능) 을 구현하는 브랜치이다.
   브랜치명은 github flow 처럼 자세하게 작성한다.
   기능 구현이 완료되면, master 브랜치로 pr 을 날린다.
   merge 되면 브랜치는 삭제된다.

   • 부모 브랜치: master
   • 자손 브랜치: -
   • PR받는 브랜치: -
   • PR나가는 브랜치: master

Gitlab Flow 는 다음과 같은 경우에 유용하다.

• 중간 규모의 팀
• 퀄리티 보장이 중요한 프로덕트
• 빠른 배포와 관리가 필요한 경우

2) git commit convention 정하기

커밋 메세지: 현재 commit 이 무엇과 관련한 개발에 해당하고, 어떤 변경 사항이 있는지 등을 작성하는 것

7가지 메세지 규칙

보통 총 7가지 메세지 규칙을 지킨다. (출처: https://cbea.ms/git-commit/)

1. 제목과 본문은 한 줄을 띄워서 작성한다.
2. 제목은 영문 기준 50자 이내로 작성한다.
3. 제목 첫글자는 무조건 대문자로 작성한다.
4. 제목 끝에 마침표(.)는 찍지 않는다.
5. 제목은 개조식 (영어라면 명령문) 으로 작성한다. (Update code, Fix bug 등으로만 작성, 만약에 한글로 작성한다면 ‘abc 함수 수정’ 과 같은 식으로)
6. 본문은 영문 기준 72자마다 줄바꿈을 한다.
7. 본문은 무엇을, 왜 에 맞춰서 작성한다.

커밋 타입

타입	설명
Feat	새로운 기능을 추가할 경우
Fix	버그를 고친 경우
Env	개발 환경 관련 설정
Design	CSS 등 사용자 UI 디자인 변경
!BREAKING CHANGE	커다란 API 변경의 경우
!HOTFIX	급하게 치명적인 버그를 고쳐야하는 경우
Style	코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Refactor	프로덕션 코드 리팩토링
Comment	필요한 주석 추가 및 변경
Docs	문서를 수정한 경우
Test	테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X)
Chore	빌드 태스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X)
Rename	파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Remove	파일을 삭제하는 작업만 수행한 경우

본문

1. 한 줄 당 72자 이내
2. 아무리 길어도 괜찮으니, 최대한 상세히 작성
3. 무엇을, 왜 변경했는지 작성 (코드 자체를 상세히 적는 것은 지양)

꼬리말

Close: #123

Github 상의 이슈를 닫는 것과 관련해서, 커밋 메세지를 통해서도 이슈를 닫을 수 있다.

1. 꼬리말은 어디까지나 선택 사항
2. “유형: 이슈번호” 형식으로 작성
3. 유형은 “Close, Fix, Resolve” 등을 활용
   (보통 Close 는 일반 개발 이슈를 닫을 때,
   Fix 는 버그 이슈를 닫을 때,
   Resolve 는 문의나 요청사항에 대한 이슈를 닫을 때 사용)

🎈이슈를 닫는 메세지는 본문에 작성하고도 한다.

3) issue, pull request template

issue 나 pull request 를 작성할 때 일일이 목차를 직접 작성하게 되면 시간이 오래 걸리기 때문에, 이미 목차가 있는 template 을 활용해서 작성하면 훨씬 더 시간을 단축할 수 있다.
팀원들 간에 양식을 지키지 않고 issue 나 pr 을 작성하게 되는 경우도 방지할 수 있다.

우선 git 으로 관리되는 폴더 내부에, .github 폴더를 만든다.
이제 해당 폴더 내에 issue_template.md, pull_request_template.md 파일을 만든다.

pull_request_template.md 예시

## 작업 개요 (이슈 번호)


## 작업 내용 (변경 사항)


## 스크린샷


## 테스트 결과


## 리뷰 요청 사항

issue_template.md 예시

## 목적


## 세부 내용

4) branch protection 을 통해 branch 보호하기

branch protection은 배포에 연결되어 있는 브랜치 등의 함부로 변경되면 안되는 브랜치에 바로 push할 수 없도록 보호해주는 기능이다.

1. 레포지토리 상단에 settings 클릭
2. 왼쪽 메뉴에서 Branches 클릭
3. add rule 클릭

여기에 보호할 브랜치를 입력한다.
여기에 pattern이라고 되어 있는데 예를 들어featur*라고 작성하면,
feature라는 접두어를 가진 모든 브랜치가 보호된다.

브랜치 보호 해석

1. merge 이전에 pull request 가 필요 (pull request 를 통해서만 해당 브랜치로 merge 가능)
2. 테스트 결과 (status check) 이상이 없을 시에만 merge 가능
3. 코드 리뷰에 달린 conversation 이 모두 해결 (resolve) 된 경우에만 merge 가능
4. 커밋이 sign 되어있어야함 (gpg key 를 가지고 commit 한 경우만 허용)
5. 분기되지 않고 선형 이력을 가져야 함 (merge commit 자체가 불가능 → 즉, 하나의 이력으로 정리된 경우만 허용)
6. 배포가 성공한 경우에만 merge 가능 (특정 브랜치를 deploy 용으로 환경을 만들어놓은 경우에만 의미가 있음)
7. 그 누구도 위 보호 옵션을 우회 (bypass) 할 수 없음 (심지어 github repo 관리자도)