Git, Guthub (3)

Git 관리 전략

---

git flow, github flow, gitlab flow

---

git 에서의 branch 관리 전략

(사진 출처: https://www.youtube.com/watch?v=w2r0oLFtXAw)
git 에서는 총 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 브랜치

   배포 전에 제품을 테스트하는 브랜치입니다.

   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 된 프로덕트에 대한 관리 사이클이 긴 경우

---

git hub 에서의 branch 관리 전략

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

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 된 프로덕트에 대한 관리 사이클이 짧은 경우 (업데이트 주기가 짧은 경우)
• 빠른 배포와 관리가 필요한 경우

---

git lab 에서의 branch 관리 전략

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 는 다음과 같은 경우에 유용합니다.

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

---

git commit convention

커밋 메세지를 잘 작성하면, 우리는 단순히 커밋 이력만 보고서도 현재까지 어떤 개발이 진행되었고, 어떤 커밋에서 문제가 발생했는지 등을 확인할 수 있게 됩니다. 특히나 규모가 큰 개발일수록 이 커밋 메세지는 더욱 중요해집니다.

보통 다음과 같은 규칙을 따르지만, 회사나 프로젝트마다 각각의 규칙을 정하기 때문에 아래와 같이 꼭 할 필요는 없다.
커밋 메시지 7가지 규칙
1. 제목과 본문은 한 줄을 띄워서 작성한다.
2. 제목은 영문 기준 50자 이내로 작성한다.
3. 제목 첫글자는 무조건 대문자로 작성한다.
4. 제목 끝에 마침표(.)는 찍지 않는다.
5. 제목은 개조식 (영어라면 명령문) 으로 작성한다. (Update code, Fix bug 등으로만 작성, 만약에 한글로 작성한다면 ‘abc 함수 수정’ 과 같은 식으로)
6. 본문은 영문 기준 72자마다 줄바꿈을 한다.
7. 본문은 무엇을, 왜 에 맞춰서 작성한다.
(출처: https://cbea.ms/git-commit/)

커밋 제목 규칙
제목은 간단하게 해당 커밋의 목적을 요약해서 작성합니다.
1. 50자 이내
2. 시작할 때는 대문자로 시작 (보통 Fix, Add, Change 등의 명령어로 시작)
3. 마칠 때 마침표 등의 특수문자 없이 작성,
4. 개조식으로 작성
5. “타입: 내용” 의 형식으로 작성

그리고 단순히 제목의 내용만 적는 것이 아니라, 앞에 Feat: 이라는 단어가 붙어있는데요, 이는 해당 커밋의 타입을 명시하는 부분입니다.

타입은 여러가지를 지정할 수 있는데요, 보통 프로젝트에 맞춰서 아래와 같은 타입을 사용합니다.

• Feat : 새로운 기능 추가
• Fix : 버그 수정
• Env : 개발 환경 관련 설정
• Style : 코드 스타일 수정 (세미 콜론, 인덴트 등의 스타일적인 부분만)
• Refactor : 코드 리팩토링 (더 효율적인 코드로 변경 등)
• Design : CSS 등 디자인 추가/수정
• Comment : 주석 추가/수정
• Docs : 내부 문서 추가/수정
• Test : 테스트 추가/수정
• Chore : 빌드 관련 코드 수정
• Rename : 파일 및 폴더명 수정
• Remove : 파일 삭제

제목으로 어떤 타입을 사용할지는, 개발을 시작하기에 앞서서 팀에서 미리 합의를 한 후에 진행을 하는 것이 좋습니다.

본문 은 다음과 같이 작성합니다.

로그인 기능 구현을 위해 로그인 요청을 보내는 axios 함수 작성

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

꼬리말은 다음과 같이 작성합니다.

Close: #123

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

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

💡 이슈를 닫는 메세지는 꼭 꼬리말이 아니라 본문에 작성하기도 합니다.

위는 어디까지나 예시이고, 커밋 메세지를 어떻게 작성할지회사나 팀원간의 소통을 통해서 정하는 것이 좋습니다.