# 1. 👨‍👨‍👦‍👦 Github로 협업 프로젝트 관리하기

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

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

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

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

* `Issue`, `Pull requests`, `Kanban borad` 모두 이용해 프로젝트 관리하기.
* `Wiki`에 개발일지 기록하기.
* [개발 타임라인](https://docs.google.com/spreadsheets/d/1wWLF3vMi655IZUV0sBrItizn24Pd0nGPDffO9lTlEqY/edit#gid=136791574) 작성하기.
* 모든 커밋 및 문서는 영어로 작성하기.&#x20;

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

## 1. 협업 플로우

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

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

이 프로세스는 모두 깃허브의 [칸반 보드](https://github.com/FiveEat42/yebalja.com/projects/1)에서 관리한다.

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

각 단계에서 실제로 어떤 작업을 해야하는 지는 [3. 풀리퀘스트(pull request) 방법](https://velog.io/@hidaehyunlee/Github%EB%A1%9C-%ED%98%91%EC%97%85%ED%95%98%EA%B8%B0#3-%ED%92%80-%EB%A6%AC%ED%80%98%EC%8A%A4%ED%8A%B8pull-request-%EB%B0%A9%EB%B2%95)에 정리해보았다.

## 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` : 그냥 코멘트만 달아줌.&#x20;
* `Request changes` : 코드에서 버그를 발견하면 다시 수정해달라고 요청할 수 있음.
* `Approve` : 이 코드가 merge 되는 것에 동의함.

### 5) Merge PR

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

👍

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

## 4. 코드리뷰 방법

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

    ![](https://github.com/hidaehyunlee/Fork-my-brain/tree/4f7d19f4487fe8d450e22a9b6451bbed865ce125/images/1a89cd3f-f362-404f-a8ac-5938c1600b60-KakaoTalk_Photo_2020-08-25-11-34-22.png)
*   코멘트를 적은 뒤 `approve` 한다.

    ![](https://github.com/hidaehyunlee/Fork-my-brain/tree/4f7d19f4487fe8d450e22a9b6451bbed865ce125/images/bb97682a-7dc8-4d5a-bb61-10aa27b88e11-KakaoTalk_Photo_2020-08-25-11-43-10.png)

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

## 5. 참고 사례

* [이슈 작성](https://github.com/42-JMJ/iOS-App-Project/issues?q=is%3Aissue+is%3Aclosed)
* [칸반 보드](https://github.com/42-JMJ/iOS-App-Project/projects/2)
* [위키](https://github.com/42-JMJ/iOS-App-Project/wiki)
