최근에 작은 프로젝트에 코드를 기여하고 있다. 현재 블로그에서 사용하고 있는 테마에 새로운 기능이나 자잘한 오류를 수정해서 코드를 기여하고 있는 중이다. 현재 사용하고 있는 테마는 매우 깔끔하면서 담백해서 아주 마음에 들고 있다. 추후에는 태그 기반 모음이나 카테고리 별 글 보기 등 다양한 코드를 작성하고 기여할 예정이다. 과거 2014년도에 iOS 개발할 때도 github에 올라와 있는 코드를 사용하고 있었는데, 아주 작은 문제가 발생해서 이를 수정하고 코드를 기여한게 github에서의 첫 오픈소스 활동의 시작이라고 볼 수 있다(물론 과거 커뮤니티 활동을 했을 때 zip 포맷으로 코드를 공유하긴 했었다). 물론, 당시 일이 바쁘다는 핑계로(물론 실제로 바빴다..) 더 많이 기여는 할 수 없었지만, 최근에는 시간 관리를 하는 방법도 나름 터득도 하고 마음도 당시보다 성장하여 개인적인 여유를 만들고 있다.

좀 더 오픈소스 활동을 하여 내가 오픈소스 커뮤니티에서 받았던 혜택을 조금이나마 갚아보려고 하고 있다. 좀 더 적극적으로 다가서려고 하는데 마침 마음에 드는 프로젝트가 진행되고 있어서 조금씩 기여를 하고 있는 터였다. 기본적으로 github는 다음과 같은 과정으로 소스코드를 기여할 수 있다.

1. 마음에 드는 프로젝트가 있다? fork 하여 자신의 계정으로 저장소를 복사한다
2. 로컬 호스트에 fork한 저장소를 clone 한다
3. 새로운 branch를 만든다
4. 소스코드를 수정하고 commit 후 push 한다
5. 새로운 branch에 대해서 merge를 원하는 원 프로젝트의 branch에 pull request를 보낸다
6. 원 프로젝트 maintainer가 마음에 들면, 바로 pull requets를 받아들이고 merge 해준다
7. 그렇지 않을 경우, 코멘트를 통해서 수정사항을 말해준다
8. 수정사항을 반영하고 commit 후 push 한다
9. 7~8의 과정을 반복한다
10. 최종적으로 코멘트 -> commit 리스트 -> 코멘트 -> commit 리스트 … 가 반복되는걸 볼 수 있다

위와 같은 과정에서 10번째 과정이 모두 마무리가 되면 바로 merge를 하는가 maintainer 마다 다르다. 오픈소스 프로젝트는 누구나 모두 참여할 수 있다. 따라서, 새로운 사람이 소스코드 히스토리를 본다면, 아주 깔끔하고 명확하게 남아있어야 한다. 위 과정의 문제점은 9번째 과정으로 인한 commit 리스트이다. 다음과 같은 commit 리스트가 있다고 해보자.

• 3f5b89ac 정말 완료
• 90d783cf 오탈자 수정
• f813cfdd 새로운 기능 1에서 A 문제 수정
• 19dfa198 새로운 기능 1 추가 완료

‘새로운 기능 1’을 추가하기 위한 commit 리스트가 위와 같이 남아 있다면, 새롭게 참여하는 사람들은 매우 혼란스러울 것이다. 또한, 프로젝트를 관리위한 maintainer도 추후 혼란스워할 수 있는 가능성이 높다. 따라서, 기능 하나는 하나의 commit으로 관리하여 히스토리에 남도록 하는 것이 현재 오픈소스 프로젝트의 관리 트렌드라고 볼 수 있다.

다시 1~10단계의 스텝을 확인해보자. maintainer가 직접 모든 commit 리스트를 하나로 묶어서 merge 할 수 있지만, 기여자에게 직접 부탁할수도 있다. 이 때 당황하지 않고 git의 rebase 기능을 통해서 각 commit을 squash 할 수 있는 기능을 제공하고 있다.

rebase 기능은 매우 신중하게 사용해야 한다. 이미 push 되어 있는 commit을 rebase 통해서 수정하게 된다면, 다른 개발자들의 프로젝트 코드 히스토리가 망가질 수 있다(예, 5개의 commit을 1개의 commit으로 합쳐서 push). 위에서 예제를 든 것은 내 자신 혼자 자신의 저장소에서 자신이 만든 브랜치에 혼자서 개발하고 있기 때문에 가능한 일이다.

이미 pull request를 통해서 branch에 대해서 push된 commit 들이 있으므로 rebase를 통해서 여러 개의 commit을 하나의 commit으로 합쳐서 push 하려면 오류가 나서 push가 되지 않을 것이다. 이는 다음과 같이 강제적(force)으로 push 하면 된다.

$ git push -f origin feature-1

그러면 pull request에서 다음과 같이 보이던 것이,

• 댓글 1
• 댓글 2
• 19dfa198 새로운 기능 1 추가 완료
• 댓글 3
• f813cfdd 새로운 기능 1에서 A 문제 수정
• 댓글 4
• 댓글 5
• 3f5b89ac 정말 완료
• 90d783cf 오탈자 수정

아래와 같이, commit 목록이 맨 마지막으로 들어가 있는 것을 확인할 수 있다.

• 댓글 1
• 댓글 2
• 댓글 3
• 댓글 4
• 댓글 5
• 1d451c01 새로운 기능 1 추가

이제 maintainer는 매우 뿌듯하게 pull request에 대한 branch를 merge하고 pull request을 닫을 것이다. 그리고, 새로운 코드는 해당 프로젝트의 mainline에서 동작하게 될 것이다.

내가 아주 오픈소스에 대해서 크게 기여한 바는 없지만, 기본적으로 오픈소스의 시작은 pull request와 소통이라고 생각한다. 만약, 오픈소스 활동에 관심이 많다면, Contributor Convenant(기여자 행동 강령 규약)을 한번 읽어보는 것도 도움이 될 것이라고 생각한다. 나도 꾸준히 오픈소스에 기여해서 더 좋은 코드와 프로젝트 만들기에 동참해야지..