OpenUp 오픈소스 컨트리뷰션 아카데미 멘티 선발 완료 후, 발대식 전에 진행하는 2일 간의 사전 Git 교육 정리하기
2018년부터 OpenUp이라고 하는 정보통신진흥원 (NIPA) 소속으로 오픈소스 관련 대회나 행사를 주관하는 기관의 행사에 많은 관심을 갖고 있었고, 2019년에 대학교 동아리에서 친구들과 “공개 SW 개발자 대회”로 참여를 시작해서 2020, 2021년에 프론티어 개발자라는 항목으로 개발을 하고 싶었으나 번번히 탈락해서 이 기관에서 주관하는 행사에 참여하는 것이 쉽지 않았다.
프론티어 개발자 탈락 이후에 행사가 더 열리는 것은 잘 알고 있었고 (공개 SW 개발자 대회, 오픈소스 컨트리뷰션) 둘 중 어느 것을 지원할까 큰 고민을 하다가 올해에는 컨트리뷰션으로 지원하게 되었다.
오픈소스 컨트리뷰션에서 이번에 열린 프로젝트가 25개 정도 있는데, 나는 이번에 OpenStack으로 지원하게 되었다.
프론티어 개발자를 지원할 때도 OpenStack으로 지원하기도 했고, 파이썬이 아직까지는 익숙한데다가 취업을 위해 알고리즘도 전부 파이썬으로 풀고 있다보니 파이썬으로 코드가 구성된 OpenStack 특성상 언어에 대한 장벽 없이 빨리 배울 수 있을 것 같았다.
아직 프로젝트 시작 전이긴 하지만, OpenUp에서는 참여자들의 원활한 오픈 소스 프로젝트 진행을 위해 사전에 Git 과 github 사용법에 대해 교육을 해주게 되었다.
우선 교육이 끝나고나서 하는 말이지만, Git을 이렇게까지 다양하게 활용할 수 있는 것인지 처음 알았다.
새삼 리눅스 토발즈라는 사람이 얼마나 대단한 사람인지 다시 한 번 알게 해주는 게 Git의 위력이었다.
우선 내가 늘 반복적으로 해왔던 단순한 작업들을 생각해보자.
저장소를 만들면 저장소를 초기화하고, 거기에 커밋한 내용을 푸시할 것이다.
그 후, 마스터 브랜치에 직접 푸시한 게 아니라면, 보통 브랜치를 사용했을 때 PR을 생성해서 병합하는 전략을 사용했고, 내가 풀었던 알고리즘이나 작업했던 프로젝트를 봐 줄 사람이 없으니 보통은 내가 어떤 의미로 코드를 작업했는지를 남기기 위해 코드 리뷰를 작성했다.
그런데 당연하겠지만 이 전략은 정말 git & github을 1% 밖에 활용하지 않은 것이고, 프로젝트의 전반적인 요약 정보를 확인하는 것도 가능했다.
위의 명령어들을 잘 보면 로그를 짧게 만들어서 보되, 개발자별 커밋 횟수나 활발하게 개발하고 있는 개발자를 볼 수 있다.
프로젝트 오너가 프로젝트를 관리하는 것과 별개로 메인 개발자가 누구인지 알 수 있기 때문에 실제로 프로젝트에 대해 궁금한 사항이 있으면 이러한 메인 개발자에게 문의를 하는 것도 가능하다.
그리고 오픈 소스 프로젝트가 상당히 오래 유지되고 사용하다 보면 (예를 들어, Node.js같은) 커밋 수만 2만 개가 넘어가는 경우도 있다.
이 커밋에는 PR Merge 같은 것도 포함되어 있어서 (즉, 의미없는 커밋) 이러한 merge 활동을 필터링하고 원하는 커밋만 보는 것도 가능하다.
예를 들면, git log — oneline — no-merges (여기 길이가 긴 대쉬는 2번 입력한 값이다)를 사용하면 merge가 된 PR을 모두 지운 값을 보여주는 형태다.
그런데 이렇게 git에 대한 다양한 명령어를 배우는 것도 신기했는데, 이 수업이 무엇보다 유익했던 것은 Rebase에 대해 제대로 배울 기회가 있었기 때문이다.
오픈 소스 프로젝트를 참여하게 되면, Rebase를 사용하는 것은 사실상 거의 필수이고, 이걸 모르면 안된다고 했다.
전에 친구와 스터디를 하면서 git rebase에 대해 배울 수 있었고, 간략하게 개념은 알고 있었는데 이게 간략하게 개념만 안다고 사용할 수 있는 게 아니었다.
위처럼 나도 공식 오픈 소스 프로젝트를 fork해서 작업하고 있고, 다른 누군가도 fork해서 작업하는 상황 중에 다른 개발자가 작업한 코드가 PR된 것을 merge된 상황이다.
이 경우, 내가 작업한 결과물과 상관 없이 아래처럼
rebase를 사용해서 내가 작업한 코드를 제외하고 기존 프로젝트 레포의 코드를 최신으로 업데이트 해야하는 상황이 발생한다.
이 때 rebase가 필요한 첫번째 상황이고, 쉽게 이해를 하자면 기존의 base를 다시 정의하겠다고 생각하면 편하다.
두번째로 기존에 커밋한 기록을 쪼개거나 커밋을 합쳐야 되는 상황이다.
그냥 rebase를 사용하는 방법만 배워도 신기한데, 커밋 히스토리를 보고, 하나의 커밋에 여러 기능이 구현된 채로 추가 되거나 하나의 기능을 너무 잘개 쪼개서 추가한 경우 해당 시점의 커밋으로 돌아가 커밋을 정리하는 게 가능하다.
솔직히 커밋을 완전히 삭제하는 게 아니라면 특정 시점으로 돌아가 커밋을 수정하는 게 가능한가 싶었다.
왜냐하면 과거 시점의 커밋을 수정하면 미래 시점의 커밋들 모두에 영향을 줄수 있기 때문이다.
그런데 그게 가능하고, 아래와 같이 실습을 해 볼 수 있었다.
rebase를 사용하면, rebase에 interactive라는 기능이 있는 것을 알 수 있다.
이걸 사용하면 특정 시점의 커밋이 pick이라고 되어 있는데 edit으로 변경하면 해당 시점으로 돌아가 커밋을 수정하는 게 가능하다.
이 때, 합치기 위해서 특정 커밋들은 소거해줘야하는데, git reset — soft head~1 이라고 하면 위쪽부터 삭제해야할 커밋들을 없앨 수 있다.
다만, 삭제하면 합칠 파일까지 모두 삭제되는 게 아니냐고 물을 수 있다. “soft” 옵션을 사용하면 커밋만 삭제되고 작업한 파일은 삭제되지 않는다. 파일까지 모두 삭제하려면 hard 옵션을 사용해주면 된다.
8시간의 수업 동안 사실 배운 내용의 50% 정도가 rebase에 대한 내용이라 왜 rebase를 사용하고, 커밋 관리는 어떻게 하는 등의 내용들을 볼 수 있었다.
또한 제일 인상깊었던 것은 내가 그 동안 git & github을 너무 못쓰고 있었다는 점… 코드리뷰를 어떻게 남기는 것인지에 대해 수업 들으면서 창피했다.
코드 리뷰를 남길 수 있는 개발자는 정말 대단한 개발자다.
리뷰어는 프로젝트 전체 설계를 이해할 수 있으면서 관리할 수 있는 사람이다.
내가 이슈를 남기는 방법과 커밋 메세지를 남기는 것도 너무 잘못되어서, 오늘 수업 들은 내용을 바탕으로 의식적으로 고쳐 나갈 생각이다.
강사남이 얘기하길 현업에서 오픈소스 프로젝트를 맡아서 해보거나 기타 공익적인 목적의 오픈 소스프로젝트를 참여해 본 사람이 아니라면 개발을 상당히 오래해왔던 사람도 git으로 협업하는 과정은 깊게 잘 모를 수 있다고 한다.
결국 git을 잘 다루는 방법은 영화 `엣지오브투모로우`를 생각해보면, 계속 처음부터 다시 시작하다가 달인이 되듯, 잘 안되거나 에러 때문에 커밋이 꼬이면 다시 처음부터 시작하는 것을 연습해야한다…고 한다.
8시간 동안 진짜 귀한 git 교육법을 배워서 다행이다…
Ryan
