깃허브로 협업하기

Tony·2021년 7월 26일

github

목록 보기

7/23

개인마다 혹은 팀마다 깃허브로 협업하는 방식은 다르겠지만
제가 하는 방식을 정리해보겠습니다.

깃허브에 코드 올리기

0. 팀에 합류

깃허브 collaborator로 초대를 받으면 메일로 수락
또는 collaborator를 받지 못 했지만 기여하고 싶은 경우,
fork를 떠서 자신의 레포로 가져간 후 수정 후 원조 repository로 pull request를 보낼 수 도 있습니다.

아래는 collaborator로 조인한 상황이라고 가정 후 작성하겠습니다.

1. 원격 레포지토리에서 프로젝트 다운 받기

자신이 사용하는 editor에서 프로젝트를 다운 받을 곳에
git clone (원격 레포)

git clone https://github.com/TaehwanGo/inflearn-clone-back.git

2. 프로젝트 실행

npm ci

로 필요한 패키지들을 설치

npm i vs npm ci

npm run start

앱 실행

이 명령어는 다를 수 있습니다.
- package.json 파일 참고 해서 실행합니다.

3. 작업할 내용 등록 하기(github의 issue)

(진행 중인 project가 있다는 가정 하에)

새로운 이슈 등록하기

이슈는 한번에 작업(pull-request 1회에 해당하는 작은 양)할 내용을 등록합니다.
이슈로 task관리를 하고 task(pull-request)는 다른 독립적인 하나의 작은 작업 단위로 관리 할 수 있도록 합니다.

해당 프로젝트를 선택하면 자동으로 프로젝트와 이슈가 연결이 됩니다.

4. 작업 후 pull request 보내기

4-1. 브랜치 생성

git checkout -b 브랜치이름

브랜치 이름은 작업할 내용과 관련있게 지으면 좋겠습니다.
ex) git checkout -b login/api

작업이 끝나고 코드를 반영할 준비가 되었다면

git add .

현재 까지 작업 한 내용을 git에 저장합니다.

git commit -m "작업내용"

로컬(본인 컴퓨터) git에 현재까지 작업한 내용을 저장합니다.

commit message에 작업내용은 아래 링크를 참고해서 작성합니다.
https://beomseok95.tistory.com/328

master(또는 main) branch에는 아래와 같은 룰이 설정되어 있어 바로 push를 하지 못 합니다.
(branch rule은 팀마다 다를 수 있습니다.)

master branch로 merge 되기 전에 1명 이상의 리뷰가 필요합니다.

git repo 주인도 예외는 아닙니다.

git push origin 브랜치이름

원격 레포지토리에 push를 합니다.
이때 원격 레포에 새로운 브랜치가 생성됩니다.

4-1. 코드리뷰

github로 와서 pull request를 요청합니다.
이때 리뷰어를 선택 할 수 있습니다.

코드리뷰는 계약서에 사인한다고 생각하신다는 마음으로 한줄 한줄 꼼꼼히 리뷰를 합니다.
pull request(코드리뷰)를 요청받았다면 가장 최우선순위라고 생각해주시면 좋겠습니다.
코드리뷰에 코멘트를 남길 땐 '칭찬' | '질문' | '의견' 중 하나를 남긴다고 생각하시면 됩니다.
이해가 안되면 질문을 하시면되고 코드에 대해 다른 의견이 있으면 의견을 자유롭게 남기셔도 되고 다 좋아서 남길 코멘트가 없으면 칭찬이라도 남기면 좋을 것 같습니다.

수정해야될 부분이 있으면 수정될 때까지 pull request요청 받은 것을 approve 않고 지연할 수도 있습니다.

리뷰어가 코드리뷰를 하고 approve가 되면
PR(pull request)를 요청한 사람이 직접 merge를 하는데 Squash and merge로 합니다.

Squash and merge를 하는 이유는 나중에 서버를 하게 되면 운영서버에 올리기 전에 특정 기능을 미리 만들어 놓을 수 있는데 이 것을 develop branch에서 관리한다고 가정을 해봅시다.
운영서버에 올리기 전에 필요한 기능(코드)을 cherry pick을 통해서 원하는 PR만 가져와야합니다.
이 것은 개발자가 수동으로 직접 하나하나 commit(pr)단위로 cherry pick을 하게 되는데 이때 squash merge를 하지 않았다면 어디서 부터 어디까지가 해당 기능에 대한 코드인지 구분하기 어렵고 수동으로 옮겨야하는 merge개수도 많아지기 때문에 squash merge를 하고 있습니다.

merge를 하면 작업한 내용이 master(또는 main) 브랜치에 반영됩니다.
merge후 본인의 feature branch는 원격(깃허브)에선 직접 삭제를 합니다.