[GroupProject_AOW]#2. GitHub Policy

 

#1. 브랜치 구조 - main, develop, feature

 

1. main - Final Product

main 브랜치는 배포 용 최종 코드가 관리되는 브랜치입니다. 임의의 코드를 push 하는 것이 불가능하고, 적절한 프로세스를 거쳐 최대한 깔끔하고, 완성된 코드만 push 하도록 합니다.

 

2. develop - Factory

develop 브랜치는 실질적으로 개발이 진행되는 브랜치입니다. 각 Issue로부터 파생된 작업물들이 PR을 통해  reveiwer들로부터 Approval(승인)을 받으면 develop 브랜치로 최종 merge 됩니다.

 

3. feature - Unit Task

feature 브랜치는 발행된 Issue와 연계하여 develop 브랜치로부터 파생되는 브랜치입니다. 쉽게 말해, 각 팀원이 할당받은 작업을 진행하는 장소입니다. 

 

---

 

#2. Issue

 

1. 개념

GitHub의 Issue는 리포지토리에서 작업 계획, 토론 및 추적을 위해 만들 수 있는 항목입니다. GitHub Issue는 간단한 활용법, 피드백 제공 기능, 공동 작업 기능, 손쉬운 통신이 특징입니다. 

 

2. Labels - enhancement, bug, question...etc

Label은 이슈나 풀 리퀘스트에 태그를 붙여 분류하는 기능입니다. 사용자는 이슈나 풀 리퀘스트의 성격을 나타내는 레이블을 생성하고 할당할 수 있습니다. 예를 들어, "bug", "feature request", "documentation" 등과 같은 레이블을 사용할 수 있습니다. 이를 통해 사용자는 프로젝트의 이슈나 풀 리퀘스트를 쉽게 분류하고, 필터링하여 관리할 수 있습니다. GitHub는 기본적으로 몇 가지 레이블을 제공하지만, 사용자가 필요에 따라 새로운 레이블을 추가하거나 기존 레이블을 수정할 수 있습니다.

 

3. Milestone

Milestones는 프로젝트의 일정을 계획하고 추적하는 데 도움이 되는 마일스톤입니다. 이는 프로젝트의 진행 상황을 파악하고 작업이 제시간에 완료될 수 있도록 하는 데 도움이 됩니다. 예를 들어, "1.0 릴리스", "2.0 릴리스" 등의 마일스톤을 사용할 수 있습니다.

 

---

 

#3. Issue 활용

 

1. 생성 방법

 

1. New Issue

리파지토리 상단의 "Issues" 카테고리를 선택하고, 오른쪽 상단의 "New Issue"를 선택합니다.

 

2. Template 선택

Template 목록에서 발행하고자 하는 Issue 주제에 맞는 Template을 선택합니다. (추가 예정)

 

3. 제목 설정 및 본문 작성

 

2. GitHub Project를 통해 Issue와 연계하여 feature 브랜치 생성

 

1. 새로운 Issue 생성 및 분담

먼저, 새롭게 발행된 Issue는 GitHub Project의 'Backlog' 칼럼에 자동으로 업로드됩니다. 따라서, 미팅을 통해 작업할 내용들을 추려 각각의 Issue로 발행하고, 시작 준비가 완료된 Issue들을 관리자가 'Ready' 칼럼으로 옮겨줍니다. 그리고, 각 팀원은 작업 시작 전 자신이 할당받은 Issue를 'Ready' 칼럼에서 'InProgress' 칼럼으로 옮겨 작업을 시작합니다.

 

2. feature 브랜치 생성 및 로컬 작업을 위한 세팅

Issue 창을 열어서 'feature' 브랜치를 생성해 줍니다. 오른쪽 "Development" 박스에서 'Create Branch'를 클릭하면, 해당 Issue와 연계된 'feature' 브랜치를 생성할 수 있습니다. 아래에서 자세한 깃헙 정책에 대한 설명이 있으므로, 자세한 설정 방법(base branch 설정 방법 및 feature 브랜치 명명 규칙)은 아래에서 설명하겠습니다. 

 

3. 로컬 환경 세팅

 

1. git clone "[리포지토리_url_주소]" : 당연하게도, 먼저 리포지토리 clone을 해야 합니다.
2. git fetch origin
3. git checkout [feature_브랜치_이름]
4. 작업 시작.

 

---

 

#4. GitHub 정책

 

1. Issue 제목 명명 규칙

 

1. Feat : 새로운 기능 구현 및 추가 관련 이슈
2. Fix : 기존 코드의 수정 및 변경
3. Test : 특정 기능 혹은 시스템의 테스트 진행
4. Asset : 비 개발자 전용 브랜치로 프로젝트 관련 애셋을 올려주기 위함 - LFS 관련 내용 필독!
5. * 위 키워드와 함께 제목 작성, 예시) Feat : ~~ 기능 추가

 

2. feature 브랜치 관련규칙

할당받은 Issue를 통해 새로운 feature 브랜치 생성 작업에서, feature 브랜치의 이름은 "<이슈_키워드>-<이슈_제목><이슈_번호>"로 설정합니다. 예시) feature-CharacterLocomotion#5. 임의로 'feature' 브랜치라고 설정한 것 뿐이지, feature, fix, test ...etc 특정 이슈와 연계하여 생성되는 브랜치라고 생각하면 됩니다!

할당 받은 Issue를 통해 새로운 feature 브랜치 생성 시 base branch(상위 브랜치)는 꼭 'develop' 브랜치로 설정해야 합니다. main으로 설정할 경우, 지속적으로 업데이트되는 develop 브랜치의 최신 내용을 가져오지 못하기 때문입니다.

 

3. commit 규칙

git commit -m "<이슈_키워드> : <이슈_제목>

개요 및 간단한 부가 설명

resolves <이슈_번호>	
ref <이슈_번호>	
related to <이슈_번호>"

commit 작성 규칙입니다. 먼저, 이슈 키워드(Feat, Fix, Refactor... etc)와 함께 이슈 제목을 commit의 제목으로 작성해 줍니다. 그리고 한 줄을 비워주고 작업 내용에 대한 간단한 소개와 부가 설명을 작성해줍니다. 마지막으로, 해당 작업과 직접적으로 연계된 Issue(feature 브랜치가 생성된 장소)번호를 작성하고, 나머지 ref 혹은 related to는 선택적으로 작성해줍니다. *commit 작성 시 닫는 큰 따옴표를 안 쓰고 Enter 키를 누르면 개행하여 작성할 수 있습니다.

 

4. PR 규칙

0. PR 템플릿 선택

1. PR 제목

<이슈_키워드> : <이슈_제목>, 관련 이슈 : <이슈_번호>

2. 연관된 이슈, resolves는 필수! 그 외 항목은 선택(없을 경우, - 하이픈 꼭 입력)

resolves <이슈_번호>, ref <이슈_번호>, related to <이슈_번호>
eg) resolves #5, ref -, related to -

3. 작업 내용 작성

4. 리뷰 요구사항 : 리뷰어들에게 참고할만한 내용 작성

 

5. 코드 리뷰 규칙

 

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

 

1. 클린 코드와 코드 일관성 : 코딩 컨밴션을 근거로 클린 코드 및 코드 일관성 유지
2. 개선점에 대한 충분한 이유 설명 : 리뷰가 주관적이거나 추상적이면 리뷰이기 혼란을 느낌
3. 정답이 아닌 옵션 제시 : 정답을 제안하기보다, 여러 옵션 안 들을 제시합니다.
4. 숙제가 아닌 학습 : 리뷰 작업을 '숙제'가 아니라 또 다른 '학습' 과정으로 생각
5. 억 리뷰 지양 : 억지로 리뷰할 필요 없고, 피드백할 게 없다면 칭찬해 주기!

 

---

 

#5. 가이드라인

 

1. GitHub를 통해 작업 시작하기

 

1. git clone

제일 먼저, 원격 리포지토리의 url 주소를 통해 clone을 해줍니다. 자신이 작업하고자 하는 위치에서 cmd 창을 열고, git clone "리포지토리_url_주소" 입력해주면 됩니다.

 

2. GitHub Project

 

1. 개발 회의를 통해 한 주 개발 계획을 수립하고, 관리자가 기능/수정/변경 사항 별 이슈를 발행합니다.
2. GitHub Organization의 Project를 통해 각자 자신이 할당받은 Issue 확인합니다.
3. 할당 받은 Issue가 'Ready' 칼럼에 올라오면, 'In-Progress' 칼럼으로 옮겨줍니다.

 

3. feature 브랜치 생성

 

1. Issue를 열고, Development 카테고리에서 Create Branch 클릭
2. base를 'develop' 브랜치로 설정하고, feature 브랜치의 이름을 작성해 줍니다.(위 feature 브랜치 명명 규칙 참고)
3. 모두 완료하면, local 작업 환경 세팅을 위한 커맨드가 나옵니다. 그대로, local에서 커맨드 입력 해줍니다.

 

2. 작업 push 하기

 

1. git add, git commit -m "", git push -> 삼위일체

 

• 모든 작업을 완료하면, git add + git commit -m "[커밋_내용]" + git push 삼위일체 커맨드 입력
• 이때, 주의할 점으로 commit 작성 규칙 준수 및 동명의 원격 브랜치 외 다른 브랜치에 push 하지 않기!

 

2. PR 작성

 

1. 위 작업을 완료하면, 원격 저장소 페이지에 브랜치 명과 함께 "Compare & pull request" 버튼이 나옵니다.
2. "Compare & pull request"를 누르고, 관리자가 미리 올려놓은 PR 템플릿을 선택합니다.
3. 역시나 base는 "develop" 브랜치 compare는 자신이 작업했던 feature 브랜치를 선택합니다.
4. PR을 작성합니다. 화면 오른쪽에 있는 assignee, label, milestone, project 등의 항목을 꼼꼼히 체크해주세요.

 

3. Conflict 발생 대처

참고 링크 : https://www.youtube.com/watch?v=tkkbYCajCjM&t=962s

앞서 설명한 대로, git add + git commit + git push 커맨드 입력 후 PR을 작성했지만, 'Conflict'가 발생했다는 안내문이 나올 수 있습니다. 당황하지 말고, GitHub 웹페이지에서 추천하는 "command line"을 클릭해 가이드라인을 수행해 봅니다. 그래도 안된다면, 관리자에게 빠르게 컨택해 줍니다. 위 영상을 참고하면 좋을 것 같습니다!

 

---