GitHub Workflow

버전 관리 체계(Version Control System)^[각주:1]를 사용하는 것이 어떤 장점을 가질 수 있는 지 그리고 여러가지 도구 중에서 깃(Git)이 어떤 특징과 장점을 가지는 지 살펴봤다. 이번에는 실제 깃을 어떻게 사용하면 좋을 지에 대한 이야기를 하려고 한다. 깃헙 또는 깃허브(GitHub)이라고 부르는 서비스가 있는데, 전 세계의 개발자들이 공동 작업을 위해 자주 사용하고 있다. 깃헙은 소스코드 버전을 관리하는 깃과 협업 문서 도구인 위키(Wiki), 사용자 접근제어 등을 제공하는 프로젝트 통합관리 도구로써 유명하다. 그러면 깃헙을 이용해서 어떻게 공동작업을 진행하는 지 그 절차에 대해 살펴보기로 한다.
 
깃헙을 이용할 때 크게 두 가지 방법이 있다. 마스터 브랜치(Master Branch)^[각주:2]에서 새로운 브랜치를 만들고 작업한 다음 마스터 브랜치로 병합을 요청하는 방법이 있다. 다른 한 편으로는 저장소 분리 복사(Fork Repository)를 통해서 저장소를 전부 복사한 다음, 그 안에서 브랜치를 만들고 작업하다가 원래 저장소의 마스터 브랜치로 병합을 요청하는 방법이 있다.

 

만약, 원래 저장소에 대한 접근 및 편집 권한이 있고 저장소에 직접 변경 내용을 반영하고 싶다면 클론(Clone)을 활용할 수 있다. 클론은 여러 분의 로컬 저장소에 원본의 내용을 가져오는 작업이며, 작업한 결과물은 같은 저장소 안에서 관리된다. 여러 분이 저장소에 편집 권한이 없고, 몇 가지 내용만 변경해서 독립적으로 사용하려고 한다면 포크(Fork)를 하는 것이 좋다. 브랜치(Branch)와 커밋(Commit)을 포함한 저장소의 모든 내용을 새로운 저장소에 편집 가능한 복사본을 만들기 때문이다. 여러 분은 포크한 저장소를 클론 해서 별도의 프로젝트를 운영할 수 있다.

 

두 가지 방법에서 가장 차이가 다는 부분은 마스터 브랜치를 누구의 소유로 둘 것인지를 결정하는 것이다. 기존 저장소에 있는 마스터 브랜치를 기준으로 할 것인지, 아니면 복사해 온 저장소의 마스터 브랜치를 기준으로 할 것인지 결정하는 것인데, 이 선택은 매우 중요하다. 전 세계의 수 많은 개발자들이 함께 하는 오픈 프로젝트의 경우 다양한 사람들을 상대해야 한다. 그래서 각 개발자들이 변경한 내용이 원래 저장소에 반영될 때 조심스러울 수밖에 없고, 그래서 서로의 의존성과 영향력을 최소화 하기 위해서 저장소 복사 및 분리를 염두해 두어야 한다.

 

그래서 깃헙에서는 소스코드의 병합을 풀 리퀘스트(Pull Request)^[각주:3]라고 부른다. 그것은 분리된 그리고 복사된 저장소로부터 원래의 저장소로 되가져가달라는 요청을 보내는 것이기 때문이다. 이름의 의미를 알았다면, 코드 리뷰를 어떠한 방식으로 해야할 지 쉽게 떠올려 볼 수 있다. 풀 리퀘스트는 '내가 당신의 뛰어난 코드를 가져가서 이렇게 개선해 보았다. 잘 동작하고 좋았기 때문에 당신들도 적용했으면 좋겠다'라고 권고하는 것이다. 따라서 영업을 하는 것과 비슷한 행동일 수 있다. 그래서 풀 리퀘스트를 보낼 때, 코드가 있으니 (알아서) 잘 검토해보고, 틀린 것이 있는 지 (알아서) 잘 찾아내보라는 마음으로 하는 것이 아니라, 어떻게 해서라도 이 변경이 반영될 수 있도록 (친절하게) 설명하고 설득하는 자세로 해야한다. 풀 리퀘스트를 상급자에게 숙제 검사 받는 것처럼 생각하는 많은 개발자들을 봤었고, 안타까운 마음에 그 의미를 되짚어 보았다.

GitHub Page

GitHub Workflow

---

 

1. Version Control System [본문으로]
2. Master/Slave 용어에 대한 우려의 목소리가 있어서 새롭게 저장소를 생성하면 메인(Main) 브랜치로 생성된다. [본문으로]
3. About Pull Requests [본문으로]