팀 스터디를 위한 GitHub 코드리뷰 요청 가이드

팀 스터디를 위해 코드리뷰 요청 가이드 문서를 빠르게 작성해서 공유합니다. 참고하시고 잘못된 내용은 피드백 부탁드립니다. 짧은 시간안에 작성한 문서라서 내용이 매끄럽지 못하고 오타가 있을 수 있습니다.

이 글을 읽기 전에..

팀 스터디를 위한 GitHub 운영 가이드이며, 회사에서 사용하는 방법이 아닙니다. 회사에서는 일반적인 Git Flow 정책에 맞게 개발합니다.

이 글은, Next-Step 의 코드리뷰 가이드를 참고하였습니다. 해당 가이드가 매우 훌륭합니다만, 소스트리에 대한 가이드를 작성하고자 글을 작성하였습니다.

이 글은 PR 을 전혀 보내지 못하고 있어서 완전 헤매고 있는 Git 완전 초보를 위한 가이드 입니다.  

각자 PC 에 소스트리를 설치

설치 방법 생략

처음 환경 구성

스터디 저장소에 자신의 아이디로 브랜치가 있는지 확인한다. 내이름의 아이디가 없다면 스터디 방장에게 브랜치 생성해달라고 요청한다. 스터디 방장은 빈 브랜치를 대충 만들어줄 것이다. 스터디 저장소 주소는 아래와 같다.

https://github.com/spring-basic-study/openapi

이 글에서 스터디 공용 저장소를 upstream 이라는 단어와 혼용해서 사용하겠다. upstream 이라고 표현하면 스터디 공용 저장소를 뜻한다는 것을 이해하길 바란다.

해당 저장소에서 포크를 한다.

포크가 되면, 자신의 github 에 저장소가 새로 생성된 것을 확인할 수 있다. 또한, 본인아이디의 빈브랜치도 함께 확인할 수 있다. 이 글에서 아이디브랜치는 sieunkim 으로 하였다.

포크가 잘 되면 아래와 같은 상황이 되는데, 발로 그린 그림을 참고하길 바란다.

왼쪽은 스터디 공용 저장소이며 upstream 이라고 부르겠다. 오른쪽은 각자 본인의 깃헙 계정이며 origin 또는 원격 저장소라고 부르겠다.

이제, origin 깃헙에 생성된 원격저장소를 로컬저장소로 클론 하는 작업이 필요하다. 스터디 공용 저장소가 아니라, 자신의 원격 저장소를 클론하는 것이다. 클론하는 주소는 https://github.com/자신의id/openapi 이런 주소로 되어있다. 엉뚱한 저장소를 클론하지 말자. git 꼬인다.

소스트리에서 내 깃헙에 포크된 저장소를 클론해서 로컬 저장소로 가져온다.

자, 그리고 소스트리에 좌측을 보면 원격 origin 에 내아이디 브랜치가 있는 것을 확인할 수 있는데,

내아이디 브랜치를 체크아웃을 해봅니다.

체크아웃이 되면, 굵은 글씨로 표시된다.

체크아웃이 된 상황은 아래와 같다.

새로 만들어진 깃 브랜치는 아무 파일도 없는 빈 브랜치이다.  

지금까지는 내 로컬 저장소의 sieunkim 브랜치와 원격 저장소(각자 깃헙계정) origin/sieunkim 브랜치 둘다 같은 포인트에 있는 것을 확인할 수 있다.(나중에 달라지지만..) 참고로 여기서 origin 은 내 깃헙 저장소이다. 스터디 공용 저장소가 아니라는 것을 인지하도록 하자.

중요한 사실은 이때 반드시 내 아이디 브랜치를 체크아웃해야 하며, 마스터 브랜치에서 시작하면 안된다. 각자의 아이디 브랜치(이 글에서는 sieunkim)를 체크아웃을 하고, 해당 브랜치 기준으로 step01 브랜치를 생성하고 step01을 체크아웃한다. 자신의 아이디 브랜치에서 바로 개발을 시작하면 안되는 것이다. 아래와 같이 해야 한다.

위 그림과 같이 step01 이라는 신규 브랜치를 생성 및 체크아웃을 한다.

생성하면, step01 에 대한 브랜치가 생성이 되었다. 현재브랜치:sieunkim 이고 새 브랜치는 step01 이라는 것을 확인할 수 있다. 잘 생성이 되면 아래와 같이 좌측에 step01 이 굵은 글씨로 된다. 체크아웃이 된다는 의미다.

자신의  id 브랜치 및 step01 브랜치 모두 아무파일도 없는 빈 브랜치이다. 이제, step01 에 작업을 시작해보자. 빈폴더에 프로젝트를 시작하면, 아래와 같이 커밋하지 않은 변경사항에 파일이 추가된 것을 볼 수 있다,

파일을 스테이지에 올리자.

스테이지에 올라간 상황은 아직 커밋은 하지 않은 상황이며, 아래와 같이 커밋을 해줘야 한다.

커밋을 했다고 해서 origin(내 깃헙 계정) 저장소에 올라가지는 않는다. 푸쉬를 해서 올려보려야 한다.

깃헙에 접속해서 원격 저장소에 잘 푸쉬 되었는지 확인해보자. 잘 되었다면 아래와 같이 브랜치를 선택해보면 내가 올린 파일을 볼 수 있다.

지금상황을 그림으로 표현하면 아래와 같다.

한번 더 해보자. 파일을 하나 변경해서 다시 푸쉬를 해보자. 파일을 변경하면 아래와 같이 변경된 파일을 확인할 수 있다. 아이콘이 다르다. 아까는 신규등록 파일이었고, 지금은 변경이다.

동일하게 스테이지에 올리고, 커밋을 하면

두번째 커밋이라는 커밋 로그를 확인할 수 있다.

이제 푸쉬를 해볼까? 두번째 커밋을 정상적으로 원격 저장소에 푸쉬가 될 것이다.

이런 방법으로 STEP01 에 대한 요구사항을 열심히 개발하면 된다.

개발이 종료되고 코드리뷰 요청을 하자.

푸쉬를 하면 노란색으로 표시된 영역이 보이며 우측 Compare & pull request 버튼을 클릭해도 된다. 아니면 왼쪽에 있는 New pull request 버튼을 클릭해도 된다. (노란색 영역 알림은 곧 사라짐)

이때 중요한 점은, 스터디 저장소에 내 이름의 브랜치에 pull request 를 요청해야 한다. master 에 요청하면 안된다.

spring-basic-study/openapi : 내id브랜치    <---  내깃헙/openapi : step01

PR(Pull Request) 보내는 상황은 아래와 같다.

스터디 저장소에 가서 보면 각자 보낸 요청을 확인할 수 있다. (다른 사람이 올린것도 구경할 수 있다.)

자!! 여기까지 완료했다면 일단 너무 감사하다. PR 요청은 잘 되었다.

코드리뷰 수정사항을 반영한다.

이제 코드리뷰 요청을 보냈으니 잠시 커피한잔 마시고 놀다 오면 된다. 스터디 방장 과 리뷰어들은 아마 바쁘다는 핑계로 한참동안 리뷰를 안해주고 있을 것이다. 마음 편하게 기다리면 된다. 한참뒤에 메일에 무언가 왔다. 코드리뷰를 했고 코드 수정을 하라는 메일이다.

view it on GitHub 을 클릭하면 바로 깃헙에서 볼수 있다. 깃헙에 가서 보면 짠.. 뭔가 수정하라는 요청이다.

수정사항을 열심히 수정해서 다시 스테이지 올리고, 커밋, 푸쉬까지 해보자 .

이번에는 커밋할때 푸쉬도 같이 해보자. 아래 바뀐내용 즉시 푸쉬 버튼을 클릭하면 된다. origin에 푸쉬요청만 하면 된다. PR을 다시 보낼 필요는 없다.

스터디 저장소에 보면, 내가 푸쉬한 커밋을 확인해볼 수 있는데, 수정사항에 대한 내용을 리뷰어가 확인 후 잘 처리되었다면 머지를 하게 될 것이다.

축하한다. STEP01 에 대한 과제를 모두 수행하였다. 내 원격 저장소에 있는 step01 브랜치가, 스터디 공용 저장소인 내아이디 브랜치에 정상적으로 머지가 되었다.

머지가 되었다면 아래와 같은 상황이다.

일단, STEP01 을 먼저 완료한 후 다음을 읽어주세요.
STEP02 진행에 대한 내용은 STEP01 머지가 잘 된 이후에 읽어보는게 좋을 듯 합니다. 왜냐면 너무 복잡해서...ㅠㅠ

두번째 과제, STEP 02 를 시작한다.

STEP01 을 잘 마무리하였고, 이제 두번째 과제를 진행해야 한다. 이때 조금 복잡한 상황이 발생한다.

복습을 하면 PR 요청은

스터디 공용 저장소 : 내ID브랜치    < --- 내 원격저장소(깃헙) : STEP01

로 머지 요청이 되었다. 즉, 변경된 소스파일은 스터디 공용저장소에 내 ID 브랜치와 내 원격 저장소의 STEP01 에만 반영이 되었다. 내 원격 저장소의 내ID 브랜치에는 아직 수정사항이 머지가 되지 않았다.

현재 상황은 STEP02 브랜치를 어느 브랜치 기준으로 생성해야할지 애매한 상황이다.

소스트리에서 저장소를 확인해보자.

현재는 내 원격 저장소만 설정이 되어있을 것이다.

스터디 공용 저장소를 추가해보자. 이름은 upstream 으로 정하였다.

요렇게 하면 로컬 저장소에 원격 저장소와, 스터디 공용 저장소가 모두 추가된 것을 확인할 수 있다.

upstream 에서 가져오기를 하자.

upstream에서 가져오기를 선택하면 스터디공용 저장소(upstream) 에 내가 보낸 PR 이 머지가 되었던 로그를 확인할 수 있구나...

upsteam/sieunkim 이 각자가 PR을 보내서 머지가 된 브랜치이다. 하지만 origin/sieunkim 브랜치 즉, 원격 저장소(내 깃헙 계정의) 브랜치는 어떤 상황일까?? 한참 밑에 존재한다.

내 로컬 저장소의 sieunkim 브랜치 와 원격 저장소의 origin/sieunkim 둘다 밑에서 존재한다. upstream/sieunkim 만 신규파일로 잘 머지가 되어있는 상황이다.

일단 목표는 아래와 같다.

내 로컬의 내ID브랜치(sieunkim 브랜치)와 원격 저장소(각자 깃헙계정) origin/sieunkim 브랜치를 스터디 저장소인 upstream/sieunkim 브랜치와 동기화를 시켜주고, 그 다음에 동기화 된 sieunkim 브랜치에서 step02 신규 브랜치를 생성해서 작업을 계속 진행하는 것이다.

일단 sieunkim 브랜치를 체크아웃하자.

그리고, upstream/id 를 재배치해보자. 리베이스라고 부른다.

뭔진 모르겠지만 확인을 누른다. 아래와 같은 상황을 만드는 것이다.

리베이스를 해서 일단 upstream/아이디브랜치 와 로컬/아이디브랜치 두개는 일단 동기화가 되었다.

(사실 내 로컬의 step01 브랜치와 같은 파일일 것이다. 각자 혼자서 개발하는 중이라서 별도의 충돌사항이 없는 상황일 것이다.)

어쩃든, 내 로컬 sieunkim 브랜치를 origin에 푸쉬하기 전까지는, 아직 원격 저장소에는 아직 old 버전으로 되어있다.

푸쉬를 하게 되면, 내 원격 저장소에도 최신 파일이 업데이트가 될 것이다.  

그리고 가장 중요한 것은 sieunkim(내로컬저장소) , upstream/sieunkim(스터디 저장소), origin/sieunkim(내 원격 저장소 = 각자 깃헙 계정의 저장소) 같은 포인트를 찍고 있다.

이렇게 된다.

이제 step02 에 대한 브랜치를 따고 체크아웃을 한다. 개인 ID 브랜치에서 브랜치를 따야 한다.

step01 브랜치는 이제 못쓴다.

step02 브랜치가 정상적으로 생성 및 체크아웃 되었다면 아래와 같을 것이다.

두번째 과제를 진행해보자. 위에서 설명한 방법대로 커밋, 푸쉬까지 하게 되면 아래와 같이 원격 저장소에 푸쉬가 된 것을 확인할 수 있다.

동일한 방법으로 머지리퀘스트 요청을 보내면 된다.

글 마무리

필자가 GitHub 에 익숙하지 않은 상황이라서, 해당 방법이 정답인지 확신이 없다. Next-Step 또는 비슷한 방법으로 코드리뷰 경험이 있는 개발자가 있다면 이 글을 보고 좋은 의견을 남겨주길 바란다.