GitHub에서는 organization을 사용해 협업을 진행할 수 있다.
1. Organization 생성하기
Your organizations에 들어간 뒤, New organization을 눌러서 새로운 organization을 생성한다.
학업용 프로젝트를 위한 organization은 무료이다. 따라서 맨 좌측 Create a free organization을 눌러준다.
Organization name에는 해당 조직의 이름, Contact email에는 조직과 관련해 소통할 수 있는 이메일을 작성한다. 비지니스용 계정이면 A busiinness or institution, 그 외에는 My personal account를 선택하면 된다.
2. 팀원 초대하기
Organization을 만든 뒤, People 창에 들어가서 Invite member를 누르면 다른 유저를 초대할 수 있다. 해당 유저의 깃허브 아이디나 이메일을 작성하면 초대 이메일이 발송된다.
또한 이메일을 발송하기 전, 초대하고자 하는 유저의 권한을 부여할 수 있다. 크게 Member와 Owner가 있다.
3. 레포지토리 생성하기
Repositories 창에 들어가서, New repository를 눌러 새로운 repository 생성한다.
해당 Repository name, Description, public/private를 결정하고 Create repository를 눌러준다.
해당 화면은 Github와 IntellJ를 연동시킨 뒤, 초기 commit을 한 상태이다.
참고블로그 : https://velog.io/@zerokick/IntelliJ-IntelliJ-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-GitHub-%EC%97%B0%EB%8F%99%ED%95%98%EA%B8%B0
4. 레포지토리에 팀원 초대하기
Settings에 들어간 뒤, Collaborators and teams를 누른다.
Add people을 누른 뒤, 해당 유저의 이름이나 이메일을 적는다. 그러면 유저의 역할을 지정할 수 있다.
Read :단순 읽기, 토론 참여 가능
Triage : 쓰기 권한은 없지만 이슈와 Pull Requests에 참여 가능
Write : Project에 소스 코드를 Push 하는 등 쓰기 권한 보유
Maintain : 민감한 Action등에 권한은 없지만 해당 Repository를 전반적으로 관리 가능
Admin : 모든 권한 보유
5. 프로젝트 생성하기
(프로젝트의 전반적인 계획과 진행상황을 팀원들끼리 공유할 수 있는 기능)
Projects창을 선택한 후, New project를 눌러 새로운 project를 생성한다.
Table, Board, Roadmap 등 여러가지 템블릿이 있는데 원하는 양식을 선택하면 된다.
Project named을 적어주고 Create project를 해주면 된다.
+ Add item을 사용해서 수동으로 issue들을 추가할 수도 있지만, Workflows를 사용하여 자동으로 issue들을 관리할 수도 있다.
실제로 issue들이 추가되고, 닫아지는 예시들은 아래에 있다.
6. Isuue & Pr Template 생성하기
Settings를 누른 뒤, 아래로 내려가다보면 Features 창에 Set up templates이 있다. 이것을 이용해, issue template을 지정할 수 있다.
Add template : select을 누르면 Bug, Feature, Custom template을 선택할 수 있다. 해당하는 이슈의 template을 각각 설정할 수 있다.
template을 선택한 후 template name, about, content를 적어주면 된다.그런 다음 Commit changes를 하면 해당 template이 적용된다.
이렇게 이슈를 생성하려고 할 때, 만든 템플릿을 사용하게 되면 저장된 내용들이 자동으로 입력된다.
++
Github를 통한 협업활동에서 Issue는 가장 중요한 역할을 한다.
Issue를 기반으로 프로젝트의 모든 기획과 작업이 이루어진다.
버그, 기능 요청, 개선 사항 등을 추적하고 관리하는 기능뿐만 아니라
issue를 생성하고, 담당자를 지정하고, 토론을 진행할 수 있다.
또한 프로젝트의 진행 상황을 파악하고 업무 조율에 활용할 수 있다.
이슈가 생성되면 Assigness, label, Projects를 선택할 수 있다.
++
Assignesss는 해당 이슈의 담당자를 지정
label은 해당 이슈가 어떤 작업인지를 지정(ex. 새로운 기능 추가, 버그 수정 등)
Projects는 해당 이슈가 무슨 프로젝트인지를 지정
Pr 템플릿은 code에 .github 파일에 직접 추가해야한다. 위의 사진의 예시처럼 pull_reques_template.md라는 파일을 추가하고 원하는 양식을 적어준다.
++
Pr과 Issue를 연결하여 Pr이 닫히면 자동으로 issue도 닫히는 키워드들도 있다.
(close, closes,closed,fix,fixes,fixed,resolve,resolves,resolved)
예를 들어 close #1이면 1번 issue도 자동으로 닫힌다.
Issue 템플릿과 마찬가지로, Pr을 열게되면 저장된 내용이 자동으로 입력된다. Pr에 대한 내용을 적고, Create pull request를 해주면 된다.
Pr을 생성하면 Reviewers, Assigness,Labels,Projects를 설정할 수 있다. 지정한 Reviewers들이 리뷰를 남겨주고, 해당 리뷰에 대한 피드백을 한 뒤 최종 Merge를 할 수 있게 된다.
+++++
커밋 컨벤션 메세지이란?
개발 과정에서 소스 코드를 수정하며 많은 커밋을 하게 된다. 이때 해당 커밋을 작성한 개발자 뿐만 아니라 협업하고 있는 다른 개발자들이 이해할 수 있도록 커밋에 대한 메세지를 남겨야 한다. 이러한 메세지를 커밋 메세지라고 부른다. 또한 이 커밋 메세지를 작정하고 등록하는 방법을 바로 커밋 메세지 컨벤션이라고 한다.
커밋 컨벤션 메세지 구조 : 유다시티 스타일
유다시티 스타일의 커밋 메세지는 크게 제목, 본문, 꼬리말 세가지 파트로 구분된다.
type : subject (제목), body : (본문), footer : (꼬리말)
- type : 어떤 의도로 커밋했는지를 명시
feat : 새로운 기능 추가
fix : 버그 수정
docs : 문서 수정
style : 들여쓰기, 세미 콜론등을 변경하였을때
refactor : 코드 리팩토링을 했을 때
test : test 코드의 작성 및 수정이 이루어졌을 때
chore : 외부 라이브러리 임포트 등의 작업을 완료했을 때
- Subject : (타입 : 제목) 형식으로 사용된다.
Ex.
Feat : 게시글 Crud 생성
- Body : 최대한 상세히 무엇을 왜 변경했는지 설명한다.
Ex.
Feat : 게시글 Crud 생성
게시글 작성 Service 변경
- Fotter : 꼬리말은 선택사항이고, (이슈 트래커 유형 : #이슈번호) 형식으로 사용된다.
Fixes : issue 수정중( 아직 해결 안됨 )
Resolves : issue 해결 완료
Ref : 참고할 issue 존재 시
Related to : 해당 커밋에 관련된 이슈 번호( 아직 해결 안됨 )
Ex.
Feat : 게시글 Crud 생성
게시글 작성 Service 변경
Resolves : #1
커밋 컨벤션 메세지가 중요한 이유
커밋 컨벤션 메세지를 사용하지 않은 경우
커밋한 당사자도 각 커밋이 무엇을 의미하는지 파악하기 힘들정도로 가독성이 매우 떨어진다. 또한 협업을 함께하는 팀원이 진행상황을 확인 하기 위해 커밋 기록을 볼 때 이해할 수 없게 된다.
커밋 컨벤션 메세지를 사용한 경우
각 커밋의 목적을 한눈에 쉽게 이해할 수 있게 된다. 이렇게 협업 전에 커밋 컨벤션을 정하고 프로젝트를 진행하면 팀원 간의 코드 리뷰뿐만 아니라, 자신의 진행상황을 파악하는데 도움이 된다는 것을 알 수 있다.
