팀원 초대부터 코드 리뷰까지 깃허브 협업편

팀원이 생겼다고 바로 같이 작업을 하면 안 된다. 규칙 없이 진행하면 팀원이 실수로 메인 코드를 덮을 수도 있다. 그러면 그동안 쌓은 코드가 한 번에 날아간다. 팀으로 깃허브를 쓸때에는 혼자 쓸 때랑은 완전히 다르게 세팅해야 한다. 이 글 순서대로만 하면 팀원 초대부터 코드 합치는 것까지 한 번에 끝낼 수가 있다.

팀 협업 전체 흐름

팀원 초대 → 브랜치 보호 설정 → 이슈 분배 → 프로젝트 → 팀원 클론 → 브랜치 작업 → push → PR 요청 → 코드 리뷰 → 머지 → git pull

템 세팅하기

팀원 초대

깃허브에서는 코드를 저장하는 공간을 레포(Repo)라고 한다.

레포 초대자

1. 레포 세팅 > Collaborator (함께 작업할 사람을 관리하는 곳)
2. 이메일 인증 확인
3. 사람 초대
4. 깃허브 닉네임 입력 후 레포에 추가 선택

레포 팀원

1. 팀원은 깃허브에서 이메일 수신
2. 초대 승인 클릭
3. 레포에 팀원으로 추가 완료

브랜치 보호 규칙

팀원을 초대 했는데 메인에 바로 푸시하는 권한을 주면 그것 또한 리스크일 수 있다. 의도하지 않고 실수로 올리는 경우가 생길 수 있는데 미연에 방지 하는 게 좋다. 그래서 메인을 잠궈두는 것이다. 이게 브랜치 보호 규칙이다.

메인 잠금을 하면

• 메인에 직접 push 불가
• 반드시 브랜치를 만들고 PR을 요청
• 팀장이 승인을 해야 메인에 머지가 가능

1. 세팅 > 브랜치 > Add classic branch protection rule
2. 브랜치 보호 규칙 영어로 이름 설정
3. Require a pull request before merging (main에 직접 push 불가. 반드시 PR 통해야 함.)
4. Require approvals (승인 횟수)

이슈 분배하기

혼자 할때는 이슈는 메모장 정도로 사용했다. 그런데 팀이 생기면 이슈에 담당자가 붙는다. 그리고 해당 이슈가 어떤 내용인지 라벨을 달 수 있다. 담당자와 라벨을 같이 설정해둬야 필터를 걸어서 빠르게 확인할 수 있다. 바로 확인할 수 있도록 분류해주는 것이다. 이슈 많아지면 필터링할 때 편하다. 기본적으로 있는 라벨이 있고 따로 커스텀해서 추가를 할 수도 있다.

1. 이슈 만들기
2. assignees – 이슈 담당자 지정
3. Labels – 이슈 종류 선택
4. 이슈 타이틀 작성 후 생성

프로젝트 만들기

이슈가 많아지면 이슈 칸에서 전체 내용을 한 번에 확인하기가 어렵다. 그럴 경우 따로 프로젝트를 만든다. 전체 이슈를 한 눈에 파악할 수가 있다.

1. 프로젝트 생성
2. 프로젝트 이름 설정
3. Add item from repo
4. 생성한 이슈 선택

프로젝트 확인하기

프로젝트를 만들고 View로 가서 Board를 선택한다. 그렇게 해야 한눈에 보여서 전체 상황 파악이 쉽기 때문이다. 기본 구성은 다음과 같다.

• to do – 해야할 일
• in progress – 하고 있는 일
• done – 완료된 일

이슈를 프로젝트에 연결해두면 전체 진행 상황을 한눈에 볼 수 있다. 프로젝트는 이슈를 모은 게시판이라고 보면 되겠다. 이슈를 확인했다면 팀원은 이제 작업을 하면 된다. 브랜치를 만든다. 보통은 어떤 작업인지 바로 알기 위해서 이슈에 있는 용어를 브랜치에 포함시켜서 만들면 확인하기가 쉽다.

예를 들어 상품 상세페이지 이슈 수정이면 product-pg-issue 이런 식으로 하면 된다. 어떻게 해야한다 정해진 건 없지만 직관적인 이름으로 만들기를 추천한다.

팀원 작업 시작하기

메인 복제하기

팀원이 초대를 승인하면 깃허브에서 레포를 볼 수 있다. 그런데 팀원 컴퓨터에는 아직 아무것도 없다. 메인 코드를 팀원 컴퓨터로 가져와야 작업을 시작할 수 있다. 이게 복제(클론)이다. 한 번만 하면 되고 이후에는 Pull로 당겨서 최신 코드로 받기만 하면 된다.

1. 깃허브에서 레포 URL 복사하기
2. git clone 레포URL
3. cd 폴더명

브랜치 만들고 작업하기

메인 복제가 완료됐다면 바로 메인에서 작업하면 안 된다. 브랜치를 먼저 만들고 그 안에서 작업을 해야한다.

1. git switch -c 브랜치이름 (예: lms-course)
2. 작업 실행하기

PUSH 후 PR하기

작업이 완료 되었다면 깃허브로 푸시를 해야한다. 코드를 선택하고 메세지를 넣고 푸시한다.

1. git add . (코드 선택)
2. git commit -m “강의 소개 수정” (작업 명시)
3. git push origin 브랜치이름 (예: lms-course)

팀원 깃허브에 노란 배너 PR이 있는 것을 확인할 수 있다. Compare & Pull request를 눌러서 PR 요청을 한다. 오른쪽에 리뷰어가 자동으로 추천된다. 해당 리뷰어를 원할 경우 request 눌러서 PR을 요청한다. 그리고 설명란에 자신이 해당하는 이슈를 적어두면 나중에 메인으로 머지했을때 자동으로 이슈가 닫힌다.

1. Compare & Pull request 생성
2. 리뷰어 선택
3. PR 소개에 이슈 추가 closes #번호 (권장)
4. PR 생성

코드 리뷰

팀장은 PR 요청이 오면 상단에 알림으로 알 수 있다. 그렇기에 팀원은 리뷰어를 지정해주는 게 좋다. 어떤 코드가 변한지 팀장은 확인한다. 그리고 그에 맞는 리뷰를 한다. Approve가 나야 머지가 된다. 브랜치 보호 규칙을 설정해뒀기 때문에 승인이 있어야 머지가 된다.

1. PR 요청 확인
2. File changed에서 코드 변경 부분 확인
3. 의견 제출
4. 이상 없으면 Merge

• Approve – 이상 없다, 머지 가능
• Request changes – 이 부분 고쳐달라는 반려
• Comment – 승인도 반려도 아닌 의견만 남기기

최신 코드 받기

머지가 완료됐다고 내 컴퓨터 코드가 자동으로 바뀌지 않는다. 직접 당겨와야 한다. 메인으로 이동해서 최신 코드를 받은 다음에 작업했던 브랜치는 삭제하면 한 사이클이 완료된다.

1. git switch main
2. git pull origin main
3. git branch -d 브랜치이름 (예: lms-course)