과학기술정보통신부에서 주최하고 정보통신산업진흥원에서 주관하는
2020 오픈소스 컨트리뷰톤의 멘티로 선정되었다.
내가 지원한 프로젝트는 우분투 한국어 번역,
아직 한국어 번역이 되지 않은 패키지들에 대한 한국어 번역을 진행하는 프로젝트다.
오픈소스 프로젝트에 기여해보고 싶었지만 아직 코딩으로 기여할 자신이 없었는데
이번 기회에 오픈소스 생태계에 대해서도 배워보고 개발 외적인 기여부터 시작해보고자 한다.
무엇보다, 한 사람의 우분투 사용자로서 우분투 프로젝트에 기여한다는 것은 뜻깊은 일이다.
본격적인 활동을 시작하기에 앞서,
최종 참가자로 선정된 멘티들을 대상으로 운영되는 오픈소스 기본 교육 프로그램이 진행되었다.
협업에서 Git을 잘 사용하기 위한 실습 프로그램이었다.
크게 두 개의 트랙으로 나누어 13시부터 16시까지는 기본 교육,
18시부터 21시까지는 심화 교육이 진행되었다.
시국이 시국인지라 오프라인으로 다 같이 모여서 진행하지 못하고
선착순 25명만 오프라인 참여, 나머지는 온라인으로 신청을 받았는데
나는 온라인으로 참여하였다.
Track 1: Git/Github 기본 실습
13시부터 16시까지 기본 실습 시간에는 git을 처음 접하는 이들을 대상으로
fork, clone부터 기본 명령어 사용법을 다루었다.
실습은 CLI로 goormIDE를 통해 이루어졌는데,
GUI로 할 수 있는 건 다 CLI로 가능하지만 역은 성립하지 않기에
GUI로 버튼에 의존하여 이해했다고 착각하지 않도록 CLI로 training하는 게 좋다는
강사님의 입장이 담긴 선택이었다고 한다.
그리고 goormIDE는 웹 상에서 컨테이너를 통해 빠른 설정이 가능하다는 장점이 있다.
단순히 git 사용법만을 가르치기 보다는 오픈소스 프로젝트 관점에서 설명해주셨다.
왜 그냥 clone을 하는 게 아니라 fork-clone을 하는지 알 수 있었고,
그리고 프로젝트의 소스코드 수정 내역을 확인하는 다양한 방법에 대해서도 배웠다.
오픈소스 프로젝트 원본 저장소에 수정 내역을 바로 반영하는 게 아니라
fork를 통해 자신의 저장소에 저장함으로써
다양한 기여자들의 작업이 충돌 없이 관리될 수 있다.
그리고 local 저장소에만 가지고 있는 게 아니라
자신의 remote 저장소에 파일을 관리함으로써
자신의 소스코드를 원활하게 관리하는 동시에
다른 개발자들로 하여금 나의 개발 상황을 알 수 있도록 할 수 있다.
단순히 git log에는 다양한 옵션이 있다, 라는 식으로 넘어가는 것이 아니라
commit ID를 바탕으로 특정 commit에 대한 상세 정보 보기,
git show [commit ID]특정 파일에 대한 수정 내역 보기,
git log -- [file-name]특정 기간 동안의 수정 내역 보기
git log --after=[start-date] --before=[end-date]등의 유용한 명령을 직접 실행해보는 시간을 가졌다.
그리고 브랜치를 왜 사용하는지,
브랜치 이름은 어떻게 설정해야 하는지 배웠다.
브랜치는 어떤 작업을 하기 위한 독립적인 workspace이기에
그 작업이 무엇인지 드러나는 이름을 설정하는 것이 좋다.
이 부분에 대해서는 학교 전공 수업에서 팀장이
기능 구현 시 feature/alarm feature/stopwatch 와 같은 브랜치명을 사용하고
버그 수정 시 bugfix/date-overflow 와 같은 브랜치명을 사용하도록
요구하던 것이 생각난다는 것은 여담.
commit 메시지에 대해서는 '명령어처럼 쓰는 게 암묵적인 룰'으로 알고 있었는데
그렇게 하지 않고 added missing non-linearity와 같이
'내가 이런 수정 작업을 했다'는 식의 과거형으로 적어도 무방하다는 걸 새삼 알게 되었다.
remote 저장소는 git 저장소를 주로 backup용으로만 쓰거나
전공 수업 팀 프로젝트의 소규모 프로젝트용으로만 사용하여
origin만 두고 사용해왔는데
오픈소스 프로젝트를 진행할 때에는 보통 fork한 원본 저장소를
upstream이라는 이름의 remote 저장소로 두고 사용한다고 한다.
local 저장소의 수정 내역을 origin 저장소에 PUSH 하고
upstream 저장소로 PULL REQUEST 하는 방식이다.
이 때 다른 개발자의 수정 내역이 먼저 반영되어 있는 경우에는
REBASE를 통해 base를 최신 commit으로 이동해야 한다.
REBASE는 평소 팀 프로젝트 수행 시 사용할 일 없는 명령어였는데
이번 기회에 좀 더 자세히 알아보고 실습해볼 수 있었다.
Track 2: 오픈소스 협업을 위한 Git/Github 고급 실습
고급 실습은 혼자 작업할 땐 만나보기 어려운, 협업 상의 실습을 수행했다.
기본 실습에서 간단히 소개했던 REBASE부터 시작하여
오픈소스 프로젝트에서 만나볼 수 있는 리뷰에 대한 이야기를 듣고 실습을 하는 시간이었다.
예를 들어,
이 commit은 너무 크니 둘로 나눠주시고요,
이 commit은 메시지를 수정해주시고요,
이 commit은 필요 없으니 지워주세요.
라던가?
이전 commit들 사이에 새 commit을 추가하고자 한다면
git rebase -i --root를 통해 원하는 commit을 선택하여 pick을 edit으로 수정함으로써 rewind를 하고
그 상태로 원하는 commit을 작성한 후
git rebase --continue를 통해 rewind했던 commit들을 다시 쌓아줄 수 있다는 것을 배웠다.
그리고 이전 commit들 중 일부를 하나로 합치고 싶다면
git rebase -i --root를 통해 합치고자 하는 연속된 commit 중 최신 commit을 선택하여
pick을 edit으로 수정함으로써 rewind를 하고
git reset --soft HEAD~1를 통해 HEAD부터 1개 떨어진 곳까지 최신 commit 내용을 제거한다.
이 때, --hard 옵션을 주면 수정 내역 및 commit 정보가 제거되는 반면
--soft 옵션은 수정 내역은 남겨둔 채 commit 정보만 제거한다.
이렇게 해서 우리가 합치고자 하는 commit 내용이
수정 내역은 다 남아있지만 commit은 사라진 상태가 되었다.
여기서 현재 commit되지 않은 수정 내역을 commit하고
git rebase --continue를 통해 rewind했던 commit들을 다시 쌓음으로써
중간에 reset한 commit을 합쳐 새 commit으로 만들 수 있음을 배웠다.
이 때, 과거의 commit 메시지를 수정하고 싶다면
git commit --amend명령어를 사용해야 한다.
이를 응용하면 특정 위치의 commit으로 이동하여
그 중 부분적으로만 add하고 commit 후 나머지를 add하고 commit함으로써
commit을 나누는 것도 가능하다.
REBASE를 취소하고 싶다면
git rebase --continue을 하기 전까지는
git rebase --abort를 통해 REBASE를 취소할 수 있다.
특정 소스 파일에 대하여
git blame [file-name]를 통해 라인별로 누가 언제 어떤 commit으로 수정했는지 확인할 수 있다는 점은
이번 실습에서 처음 알게 되었다.
Sonarqube에서 소스 파일을 열어보아도 라인별로 이 정보가 뜨는데
그것이 내부적으로 git blame을 사용한 거였겠구나, 하는 걸 새삼 인지했다.
git blame을 통해 어떤 코드 블록이 수정된 시점을 확인하고
그 commit ID를 이용하여 git show로 commit 정보를 확인할 수 있다.
github organization 계정으로 저장소를 생성하여 팀 협업을 해보는 실습은
온라인 참가자들은 참여하기 어려운 상황이었는데
organization 계정 생성 및 저장소 생성을 맡아서 해주신
@Violet-Bora-Lee 님 덕분에 우리도 함께 실습을 진행할 수 있었다.
오프라인은 3~4명 단위로 실습하는데 온라인으로는 다수의 인원이 실습하여
순서가 꼬이는 등 더 복잡한 상황이 발생했지만 어떻게든 실습을 수행할 수 있었다.
사실 작년에 OSS개발자포럼의 git-starter에서 해보았던 실습과 유사한 실습이었는데
// 그 땐 단순 merge, 이번엔 rebase
오프라인으로 실습을 할 수 있었다면 좀 더 원활한 실습이 가능했을 것 같다.
팀장이 rebase 하는 것도 옆에서 구경하며... 아무튼.
버그를 수정했을 때 commit 메시지를 작성하는 것에 대해서도 배웠는데
if문에 A라는 조건이 없어서 B라는 문제가 발생했다면
fix B on A 와 같이 무엇을 수정했는지 제목에 작성한 채
내용에 이유와 방법을 적어주는 것이 좋다.
내용은 이유의 비중을 높이고 특정 알고리즘을 사용했을 때 방법도 적어준다.
그리고 제목에 문제 발생 영역을 적어주는 것도 좋은데
예를 들어 file system의 ext4와 관련된 부분이라면
fs ext4: fix B on A라는 식이다.
그리고 본문에는 Before/After를 적어주는 것도 직관적인 이해에 도움을 준다.
추가적으로 연관성 있을 수 있는 commit ID를 적어주는 것도 협업에 도움이 된다.
이미 열려 있는 issue에 대한 것이라면
Fixes #n과 같이 그 issue 번호를 적어줄 수도 있다.
시간 관계 상 빠르게 지나갈 수 밖에 없던 부분도 있고
온라인으로 참여하게 되어 실습과 관련된 아쉬운 부분도 있었지만
그 동안 잘 알지 못했던 git 고급 기술을 알 수 있는 시간이었다.
공식 문서를 보고 공부하다가도 "이게 왜 필요하지?"하며 넘겼던 부분을
왜 필요하고 어떤 식으로 활용될 수 있는지 사례와 실습 중심으로 배울 수 있었다.
이를 바탕으로 다다음주 발대식 이후 본격적으로 시작될 컨트리뷰톤 활동이 기대된다.
그리고 이런 활동을 너무 고학년 때 알게 된 점이 아쉬운데
우리 후배님들은 좀 더 저학년 때부터 이런 활동에 참여하며 많이 배워갔으면 좋겠다.
사실 그래서 내가 신청하면서도 주최측마냥 동아리에 많이 홍보했는데
실제로 신청한 친구들은 극소수인 것 같다.
아무튼 학교에서는 배우지 못한 영역에 대해 배우면서 실천해볼 수 있다는 점에서
정말 뜻깊은 활동이 될 것 같다.
나를 멘티로 선정해주신 우분투한국커뮤니티 운영진 분들께 다시 한 번 감사드리며
컨트리뷰톤 기간동안 열심히 활동할 것을 다짐한다.
