개요

소스코드로 협업을 할 떄 항상 원본 코드의 무결성이 유지되는 것은 필수적이다. 원본 코드라 함은 실제로 서비스에 반영되는 최신의 코드를 의미한다. 무결성을 유지하는 데는 다양한 방법이 있다. Git flow 를 주도적으로 사용한다면 주로 용도별로 브랜치를 나누어 적정 시기별로 Merge 를 할 것이고, Github flow 를 사용한다면, 마스터 브랜치의 무결성만 보장된다면 브랜치를 나누어 Merge 를 하던 Pull Request 를 하던 관계가 없다. (Github 은 Pull Request 를 권장한다.) 이번 포스팅에서는 후자를 주로 살펴볼 것이다.

오픈소스 기여의 시작, Fork

주로 Github 기반의 오픈소스에 기여할 때는 무결성이 너무나도 중요하기 때문에 일단 자신의 레포지토리에 포크를 한 뒤, 커밋을 하고, 커밋된 내용을 가다듬은 다음 풀 리퀘스트를 날리는 방식이 일반적이다.

fork 방법
예시로 필자가 지금 참여하고 있는 프로젝트인 GitShare 프로젝트의 레포지토리를 참조하였다. 깃허브의 레포지토리 상단 우측에 보면 Fork 버튼이 있는데, 이걸 클릭하면 자신의 계정과 (혹시 소속되어 있는 Organization 이 있다면) 자신의 그룹이 뜬다. 자신의 계정으로 Fork 하도록 하자

fork 모달창
내 계정의 이미지를 누르게 되면 아래와 같이 Forking 로딩창이 뜬다.

forking 중

Fork 하면 내 계정으로 레포지토리가 똑같이 하나 생성된 것을 볼 수 있을 것이다. 여기서부터는 일반적으로 github 에 올리는 방식과 같다. 일단 내 로컬로 clone 하도록 하자.

git clone "<레포지토리 주소>"

그리고 나서 origin 을 확인해보면 내 레포지토리의 주소를 가리키고 있을 것이다. 하지만 우리는 하나 더 추가적으로 등록 해주어야 한다. 내 레포지토리와 관계 없이 원본 코드는 항상 업데이트되고 있을 것이고, 그것을 반영하기 위해서는 원본 저장소의 변경이 있을 때마다 그곳으로부터 소스를 pull 해와야 한다. 따라서 우리는 원격 저장소를 하나 더 등록하겠다. 일반적으로 upstream 이라는 네이밍을 사용하는 듯 하나 이름은 자유다.

git remote set-url upstream "<원본 레포지토리 주소>"

자 이제 초기작업은 끝났다. 이제 남은 것은 소스를 변경하고, commit 한 뒤 풀 리퀘스트를 날리는 것이다.

compare 버튼 클릭


커밋 후 origin 에 push 를 하면 이런 알림이 보일 것이다. 여기서 compare 는 원본 코드와 변경된 코드를 비교해 주겠다는 것이다. 터미널로 할수도 있으나 깃헙에서는 이렇게 간편한 gui 를 제공한다.


compare 화면
Compare 를 하게 되면 위와 같은 그림이 뜬다. 변경된 diff 를 비교해 머지에 이상이 없으면 정상적으로 able to merge 가 뜰 것이고, 그대로 머지하면 conflict 가 날 것 같은 코드에는 disable 이 뜬다. 만약 이상이 있으면 겹치는 코드를 정상적으로 변경해 준 뒤, pull request 버튼을 클릭하면 된다. 소스 기여자들이 요청된 pull request 가 합당하다고 판단된다면 pull request 를 받아주고, 아니라면 reject 할 것이다.

마지막으로, 풀 리퀘스트는 보는 사람으로 하여금 파악하기 쉽도록 깔끔하게 만들어야 한다. 여러 개의 관심사를 동일한 풀 리퀘스트에 놓는 것은 지양해야 하며, 하나의 이슈에 관한 커밋 덩어리만을 rebase 등을 활용해 이력 정리하여 올리는 것이 권장된다.