스터디 github 가이드
서론
스터디를 하는 이유?
(너무 길어서 내용을 접어두었으니, 읽어보실분은 펼쳐 보세요)
저는 스터디를 매년 2~3번씩 꾸준히 정기적으로 참여하는 편입니다.
12개월중 6~9개월정도는 되도록 스터디에 참여를 하고, 나머지는 휴식시간을 가지는데요.
곰곰히 생각해보면 스터디보다는 스스로 공부하는것이 훨씬 효율이 나겠지만(관리, 진도 등의 이유로)
저같은경우 보통 스터디를 하게 되면 같이 하는 공부 속에서 혼자 공부를 하게됩니다.
그냥 쉽게 말해 혼자 공부하게되면 대충 하다가 말게되는 게으름때문에..
오히려 취업준비할때까지는 쳐다도 안봤는데.. 2017년에 일을 시작한 이후부터는 여유가 생겼는지 매년 빼지않고 꼬박꼬박 참여하는 편 입니다.
그런데 연차가 이제 조금씩 쌓이면서 주니어 티를 벗어나는 수준이 오니, 상대적으로 경력자분들끼리 모여서 하는 스터디는 인맥을 통해서 하는게 아니면 조금 구하기가 힘들어져서, 초보 스터디에 참여를 하게 되는데요 ㅠㅠ
그런곳에 매번 참여할때마다 '아 이번에는 가만히 따라만 가야지', '나서지 말아야지..' 라고 마음을 먹지만, 항상 종장에는 리드를 하게 되더라구요 ㅠㅠ
물론 스터디 진행을 리드하는거지, 기술, 공부 자체를 리드하지는 않는 편입니다.
어쨋든.. 스터디를 운영하다보면 구성원의 범주가 정말로 다양합니다.
학생, 취준생, 비전공 취준생, IT 관련 종사자(기획자, 디자이너 등), 다른 포지션의 개발자 등등..
만약에 iOS 앱 개발 프로젝트 스터디를 진행한다고 하면, iOS 개발에 관심있는 다양한 카테고리의 인원들과 함께하는 경우가 많습니다.
당연히 수준도 천차만별이고, git의 사용을 어려워 하는 분들도 종종 계십니다.
개인적으로 github을 사용할줄 아냐 모르냐로 역량을 판단하지는 않습니다. (그러고 싶지도 않고..)
중요하다고 생각하는 우선순위를 정해보면..
첫번째로 참여 의욕
- 개발자는 자기 프로젝트 바쁘대서 잠수타고~ 학생은 시험있다고 잠수타고~ 취준생은 취업했다고 잠수타고~ ㅠ.ㅠ
- 그리고 스터디 문의를 할 때마다 항상 참여자중 현업 개발자는 몇분이냐고 물어보시는데, 왜 물어보시는지 이해는 되지만.. 상당히 실례라고 생각합니다 ㅠ
두번째로 친화력
- 스터디를 10번정도 하면, 3~4번정도는 단톡방에 아무런 얘기가 없을때가 많습니다.. 공부를 하는거지 월급받고 일을 하는게 아닙니다. 처음 공부하는것이기 때문에 부끄러워할 필요가 전혀 없습니다. 얼마든지 물어보시고, 공유해주세요!
마지막으로 코딩 능력
- 공부하는 부분으로 서로 소통하는데 문제만 없으면 괜찮다고 생각합니다.
- 부족하다고 생각해서, 스터디를 마치고 나니 머릿속에 들어온게 없어서.. <- 이건 본인의, 그리고 스터디원 개인의 문제지 스터디원 전체에게 영향이 가는건 아니니까요^^;;
- 스터디라고 하지만, 공부는 결국 본인이 하는거라서요
말 정리가 항상 부족해서 서론이 상당히 길었네요.
이제부터 작성할 내용도, 제가 이번에 스터디를 진행하면서 스터디원들을 위해 작성한 가이드라인인데요.
PR로 서로 리뷰하며 코드를 공유하는 방식인데..
일단 스터디장이 Repo를 만들었다는 가정 하에 설명 합니다.
스터디는 하나의 Repository에서 스터디원들의 이름을 딴 Branch를 사용하여 코드를 관리할 예정입니다.
이런 방식으로 사용하는 이유는 몇가지가 있습니다만, PR을 활용하여 서로에 대한 코드를 리뷰해주는것이 가장 큰 목적입니다.
하지만, 이런방식으로만 관리를 하게 된다면.. 개인의 github Repositories에는 저장이 되지 않습니다.
PR?
(이 부분도 그다지 필요한 부분은 아닌것 같아 접어둡니다)
PR은 Pull - Request의 줄임말로, github을 비롯한 많은 git Platform에서 사용중인 Merge 및 Code Review 방식입니다.
대략적으로 github의 Repository의 구성이 이렇다고 치면..
수정할 내용이 생겨서 기여자가 수정을 하게 될 때, 리뷰를 받고, 리뷰에 대해 승인을 받게 되면 그때 코드가 합쳐지는 방식입니다. (요청 - 승인 없이 기여자 독단적으로 Repository의 코드를 수정한다면, 관리가 힘들게 되겠죠?)
따라서 이때 Pull - Request라는 방식으로 수정된 코드를 확인하고, 병합하는 과정을 거치는데요.
기여자가 수정할 코드를 PR 요청을 통해 요청을 한다면,
관리자는 해당 코드를 해당 Repository(기여자가 Fork하거나, 아니면 요청할때 임시로 생성된 저장소)를 Pull하여 확인합니다.
확인하는 과정이 일종의 Code Review가 되는것이죠.
진행 사이클
코드에 대한 기록은 다음과 같이 진행합니다.
0. (중요) 모든 작업은 Fork를 한 Repository에서 자신의 Branch에서만 작업을 합니다.
1. 원본 저장소를 내 저장소로 Fork 합니다.
2. 코드를 작성 및 수정합니다.
3. 코드가 정리되었다면, PR을 요청합니다.
4. PR에 대한 승인 및 병합작업은 원본 Repository의 Owner(스터디장)이 진행합니다.