제가 사랑하는 패키지 librosa에 제가 했던 PR을 예로 들죠.
WHY?
1. 오픈소스 소프트웨어 발전에 기여하므로 기분이 좋다
2. Git을 중심으로 여럿이서 개발하는 작업 흐름을 배운다 (유닛테스트, 문서화,..)
3. 여럿이서 개발할때 지켜야할 룰을 배운다. (코딩 컨벤션)
4. 학계, 업계의 사람들과 소통하며 인맥을 쌓는다.
5. 해당 버전의 소프트웨어가 인용되면 인용수가 올라간다. (개이득)
WHY NOT?
1. 어떻게 하는지 모른다.
2. 안해도 아무도 뭐라고 안함.
3. 귀찮다. 바쁘다.
4. 영어로 소통해야하므로 부담스럽다.
Pull Request?
줄여서 PR이라고 하죠. Pull해달라고 요청하는건데요, 다시말하면 내가 이런저런걸 고쳤으니 이걸 받아들여달라고 요청하는겁니다.
절차
정해진 방법이 있는건 아니지만 아래 과정을 참고하시죠.
- Issue 보드에서 새로운 기능이나 버그에 대해 논의하고 패키지 주인장과 공감대를 형성한다.
- 깃헙에서 해당 패키지를 Fork하고 그걸 clone한다.
- Fork한 패키지에서 Branch를 하나 만든다
- Branch에서 버그를 고치든지, 새로운 기능을 추가하든지하고 이걸 Push한다.
(주의사항: 각 PR은 1가지 내용만 담고있어야합니다. 예를들어 버그 2개를 한번에 고치는 PR은 가급적 피하고 나눠서 해야합니다. 그래야 패키지 관리하는 입장에서 편리합니다.)
- Push한 내용을 PR한다
- 한번에 받아들여질수도 있지만 주인장이 원하는 요구사항이 있으면 이를 따른다. (예: 문서화 추가, 예제 추가, 테스트코드 수정 등..)
- 최종적으로 PR이 Merge된다. 끝!
예제
제 PR을 보시면 처음에 #647로 논의를 하고, 이에따라 첫번째 PR을 날렸습니다. 그런데 여기에는 유닛테스트가 잘 되어있지 않아서 이에대해 논의했고, 기존 코드와의 일관성을 위해 API에 대해서도 논의했네요. 테스트 방법과 코드 세부사항을 좀 더 논의했고 최종적으로 Merge가 되었습니다.
다소 귀찮지만 하다보면 굉장히 뿌듯하고 재미있습니다. 배우는것도 많구요. 특히 학교에서만 있으면 협업하며 개발하는 방법을 경험하기 어려우니 꼭 한번쯤 해보시길 권합니다.
No comments:
Post a Comment