1. 👨‍👨‍👦‍👦 Github로 협업 프로젝트 관리하기

title: "👨‍👨‍👦‍👦 Github로 협업 프로젝트 관리하기 " description: ""이슈(Issue) 등록 ➡ 풀리퀘스트(Pull request) 요청 ➡ 코드리뷰(Code review)" Github의 협업 시스템을 통해 프로젝트 관리하기." date: 2020-06-09T17:53:21.352Z

tags: ["git","github","예발자닷컴"]

yebalja.com 프로젝트를 시작하면서, 5명의 팀원들과 협업을 경험해볼 수 있는 좋은 기회가 생겼다. 제대로 된 협업 프로젝트를 경험해보자는데에 의견이 모였고, 그러기 위해 깃허브를 이용한 헙업 플로우를 공부하고 정리할 필요성을 느꼈다.

우리의 작은 목표는 이렇다.

• Issue, Pull requests, Kanban borad 모두 이용해 프로젝트 관리하기.

• Wiki에 개발일지 기록하기.

• 개발 타임라인 작성하기.

• 모든 커밋 및 문서는 영어로 작성하기.

당연히 모두 깃허브를 이용한다. Github 하나만으로도 이슈 관리, 일정 관리, 코드 리뷰, 리포트 작성 등 부족함 없이 프로젝트를 관리할 수 있다.

1. 협업 플로우

전체적인 협업 플로우는 아래의 5단계를 따른다.

`이슈 발행` ➡ `이슈 작업` ➡ `풀리퀘스트` ➡ `코드리뷰` ➡ `이슈 반영(Merge)`

이 프로세스는 모두 깃허브의 칸반 보드에서 관리한다.

Kanban Borad 란?

칸반(Kanban)은 일본말로 카드 , 눈에 보이는 기록 이라는 뜻이다. 칸반 보드는 개인적인 수준에서나 조직적인 수준에서 작업을 관리하기 위해 카드 형식으로 스케줄링하는 도구하고 생각하면 된다.

각 단계에서 실제로 어떤 작업을 해야하는 지는 3. 풀리퀘스트(pull request) 방법에 정리해보았다.

2. Issue 및 branch 전략

내가 작성한 코드가 리뷰없이 master branch로 push 되면 안되기 때문에, branch를 어떤 기준으로 얼마나 만들지 정하는 것이 중요하다.

우리 팀은 branch를 기능별로 파기로 결정했다. 모든 이슈마다 branch를 생성하는 것이 가장 이상적이지만, 브랜치 관리에 익숙해지기 전까지는 새 기능을 구현하는 이슈에만 브랜치를 생성하기로 했다.

Issue의 기준?

프로젝트를 진행함에 있어 의견이 필요한 모든 것이 이슈라고 볼 수 있다. 새로 추가될 기능, 개선점, 버그 등등. 모든 활동에 대해서 이슈를 등록하고 그 이슈를 기반으로 작업을 진행하게 된다.

이슈를 효율적으로 관리하기 위해 성격에 따라 태그를 다는 것이 좋다.

3. 풀 리퀘스트(pull request) 방법

1) branch 생성

내가 담당한 기능을 개발하기 위해 브랜치를 만든다.

git checkout -b [브랜치명]

• -b [브랜치명] : 브랜치를 생성한다.

• checkout [브랜치명] : 해당 브랜치로 이동한다.

• git branch : 존재하는 브랜치 확인.

2) 작업 수행 후 add, commit, push

해당 브랜치 내에서 수정작업을 완료했으면, origin 원격브랜치에 수정사항을 반영한다.

git push -u origin [브랜치명]

• -u 옵션

  -u 옵션을 명시하게 되면 해당 브랜치에서 origin브랜치로의 업스트림 길이 트여서, 그 다음부터는 git push만 입력해도 알아서 origin브랜치로 수정사항이 반영된다.

  참고로, 아래 세 개의 명령어가 모두 같은 기능을 한다.

  1. git push -u origin [브랜치명]
  
  2. git push --set-upstream origin [브랜치명]
  
  3. git push --set-upsteam-to origin [브랜치명]

  무슨 차이점이 있나 했는데, Set upstream의 의미가 명확하지 않아서 디테일하게 알려주려고 set upstream to가 생겼다고 한다. 3번이 권장사항 이지만, 간단하게 1번을 사용하자...

3) 코드리뷰를 위한 PR 생성

origin브랜치에 Push 완료 후 github 저장소 Pull requests 탭에 들어가보면 create pull request 라는 초록 버튼이 활성화 되어있다.

메세지를 작성하고 PR을 생성한다.

• PR 제목은 해결방안 위주로 작성한다.

• 메세지는 영어-수평선-한글 순으로 작성한다.

4) 코드리뷰

코드리뷰를 몇 명에게 받을지 설정할 수 있는데, 우리는 협업 프로젝트 초반이기 때문에 팀원 모두에게 리뷰를 받아야 PR을 완료할 수 있도록 했다.

리뷰어는 PR에 대해 3가지 의사표현을 할 수 있다.

• Comment : 그냥 코멘트만 달아줌.

• Request changes : 코드에서 버그를 발견하면 다시 수정해달라고 요청할 수 있음.

• Approve : 이 코드가 merge 되는 것에 동의함.

5) Merge PR

Approve 리뷰를 받은 코드에 대해 PR 작성자가 직접 merge 한다.

👍

끗 ! 현실은 4.코드리뷰 <-> 2.이슈 작업 의 무한반복이겠지만, 그것 마저도 내가 배우고 성장한 기록이 될 것이기 때문에 기쁜 마음으로 프로젝트를 시작해본다.

4. 코드리뷰 방법

• 리뷰를 요청받은 풀리퀘스트에 들어가서 Add your review을 클릭한다.

  
• 코멘트를 적은 뒤 approve 한다.

  

  • 만약 코드에 수정이 필요하다면 Comment만 달거나, Request change를 요청할 수 있다. 이 경우에는 Merge 승인이 되지 않는다.

5. 참고 사례

• 이슈 작성
• 칸반 보드
• 위키