[그때 알았더라면] 깃은 무엇일까? 오픈 소스는 어떻게 활용할까?

네 어쩌다보니 그때 알았더라면~ 시리즈가 돼버린 깃 얘기입니다.

제가 뭘 안다고 글까지 쓰나 싶지만 주변에 공부하시는 분들 보면 요 정도도 잘 모르시는 분들이 계셔서 올립니다.

개인적으로 하는 얘기인데, 깃을 모르고 개발 공부를 n개월 했다면 지금까지 한쪽 팔로 하는 싸움을 해오신 거라 말하고 싶으네요... 

깃의 개념에 대해 구글링을 해보니 이것저것 되는 대로 떠들어대는 글이 너무 많더라구요.

"분산형"이 핵심 개념인 깃에 대해서 설명하는데 중앙형 버전 관리로 해석되는 그림만 올라오고... 인터넷에는 정보가 많지만 그걸 다 믿고 사시면 안됩니다. 개발자는 잘 모르겠을때 뭐를 본다? 네 공식문서 보셔야죠! 위 이미지도 깃 홈페이지에서 가져온 것입니다! 누르면 깃 홈페이지로 갑니다.

깃의 장점에 대해 말하는 사람들 중에 다수는 버전 관리 자체에 대해서만 말을 합니다. 저도 그것이 아주 중요하다고는 생각합니다. 사실 버전관리+가볍고빠름 = 깃이라 해도 틀린 말까지는 아니니까요.. 근데 위 이미지처럼 메인스트림에서 특정 기점에서 가지치기하듯 분기했다가, 다른 분기를 만나거나, 아니면 아예 새로운 길을 갈 수도 있는 것이 깃의 최고 장점입니다. 저 이미지보다 깃을 잘 설명하는 것을 말하자면 음...

계통수가 아닐까..???

일종의 중심이 되는 줄기가 있고, 참여자들은 언제든지 필요에 의해 또는 어떠한 이슈에 의해 메인 가지에서 분기해서 자신의 특성을 강화하거나 오류를 수정한다-는 점에서 비슷하다고 생각했다. 좀 웃긴 사실은 이 사진을 내가 창조론 주장하는 사람 블로그에서 가져왔다는 것ㅋㅋㅋㅋㅋㅋ 끼하학!!!

깃을 한마디로 설명한 공식 홈페이지 이미지! 역시 멋져요

위에서 버전관리와 깃의 차이점을 제대로 설명하는 글이 드물다고 얘기했는데, 나도 그럴 수 있을 것 같지는 않다. 깃은 굉장해엄청나-기 때문에 내가 다 설명할 수 없다. 근데 아예 아이콘이 가지 모양인 깃을 설명하는데 브랜치(가지)를 빼고 얘기하는 건 좀...

갈라질지어다!!!

이런 식으로 로컬 분기들을 허용하고, 또 권장하는 것이 깃의 최대 장점이다. 또 이렇게 분기된 것들 중 원하는 내용만 체리픽할 수 있고, 각 코드 변화의 책임 소지도 확실하다. 또 다시 합쳐질 때 혹은 분기된 것이 죽은 가지가 될 때, 단 몇 초만을 소요한다. 

깃이 없이도 버전관리가 물론 가능하다. 그런데 이를테면 여러 사람이 모인 프로젝트에서 플라스크 프레임워크를 이용해서 웹을 구성한다고 가정하면, 우리는 static 폴더, templates 폴더와 app.py 파일 그리고 폴더 내의 내용물들을 가지고 역할을 나눌 때에, 파일 하나에 두 사람 이상이 투입될 수 없다. 각자의 컴퓨터에서 필요한 내용을 수정하고 그 코드들을 정기적인 모임에서 모았을 때 그 모든 코드들이 자연스럽게 시계 톱니바퀴처럼 잘 작동하는 것은 마법같은 일이 될 것이다. 또 우리는 사이트에 실험적인 기능을 추가하고자 할 때, 모은 코드 조각들을 어떻게 잘 끼워맞춘 다음에 다시 분업을 하고, 실험을 해야 할 것이다. 물론 그 나눈 파일 조각들도 하나하나 다 백업을 해둬야 할테고, 장기적으로는 용량을 감당할 수 없을 것이다. 실험적인 기능 구현에 실패하면, 백업해둔 코드들 중에 특정시점에 저장한 파일을 선택을 해야할 것이다. 개발이 어드벤쳐 게임이라면, 우리는 "체크포인트"가 필요하다. 그것이 버전 관리이고, 깃이다.

깃헙? 깃랩? 거기는 뭐하는 곳이냐?

말 그대로 깃을 원격 서버에 저장할 수 있게 해놓은 서비스이다. 아래 그림을 보시다시피 그 위상의 차이는 깃헙이 압도적으로 높고, 깃랩은 깃허브 사용자 중 일부가 대안적으로 사용하는 것 같다. 깃허브는 2007년 쯤 플랫폼으로 나타나 2008년에 나타난 회사인데, 2010년부터는 Github.Inc. 라는 이름으로 자리잡고, 2018년에 마이크로소프트가 인수한 아주 큰 기업이다. 수익이 연간 2억 달러는 나온다고...ㅎ저 귀여운? 캐릭터는 자세히 보면 왼쪽에 꼬리처럼 생긴 것이 꼬리가 아니고 문어발이다. 고양이+문어라는 해괴한 조합으로 만들어진 옥토캣이라는 캐릭터라곻ㅎ (이상한 팬아트 페이지도 있다.) 깃랩은 잘 모르니까 패쓰

오오 깃랩 아이콘 귀엽네요!!

어림도없지 옥토캣이 더 귀엽고 괴랄함

우선적으로 알아야 할 개념들 정리

1. 터미널: 명령어 쓰는 검은 창(커맨드 라인 인터페이스)! 맥북을 사용 중인 분들은 기본적으로 깃을 사용 가능하다.
2. 깃 배시(Git Bourne Again Shell): Windows 사용자들은 Unix 계열의 운영체제가 아닌 Windows에서 Unix 계열의 커맨드라인툴을 쓰기 위해 다양한 대안을 사용하는데, 이 중 하나. 일단 깔아둬... (옵션은 거의 디폴트값대로 하면 되는 것 같다. 실험적인 기능들이 있는데 다소 위험하다.)
3. 브랜치: 물론 브랜치가 '깃에만' 있는 것은 아니다. 하지만 깃은 diff를 모두 기록하는 것이 아니라 스냅샷을 기록하기 때문에 훨씬 더 빠르고, 그래서 깃의 브랜치는 언제나 적극권장된다.
4. 스테이징(스테이싱, 스태싱): 커밋 이전에, 변경된 파일들 중 변경사항을 반영할 파일들을 인덱스 영역에 등록하는 것(파이참에서는 잘 만날 일 없는 단어)
5. 커밋: 인덱스 영역의 변경 사항들(staged change)을 확정해 로컬 저장소에 저장하는 것. 
6. 푸시(미세요): 확정된(커밋된) 변경사항을 원격 저장소 (깃허브, 깃랩, 비트버켓 등)에 등록하는 것
7. 페치(Fetch): 원격 저장소에 등록된 변경 사항 중 일부 혹은 전부를 로컬 저장소로 가져오는 것(반영하는 것)
8. 헤드: 작업 중인 브랜치의 가장 끝(앞) 부분! 헤드 이하의 커밋들을 확정된 것으로 취급하며, 일반적으로 저장소 내에서 가장 목적에 가까운 상태.
9. 풀(당기세요): 주어진 매개변수로 fetch를 실행하고 git merge를 호출 하여 검색된 분기 헤드를 현재 분기에 병합.
10. 풀 리퀘스트: 가져와서 일부 변경한 내 저장소의 변경 내용을 타인(함께 협업을 하는 동료나, 아니면 정말 남남인 개발자)에게 (메인테이너에게) 반영하도록 요청하는 것. PR이라고 줄여서 부르며, 이때 메인테이너는 그것을 반영할지 무시할지 결정해서 일부 혹은 요청 내역 전부를 프로젝트에 반영한다. 
11. 컨트리뷰션: 오픈소스 프로젝트에 참여하고 기여하는 모든 활동. 자신이 발견한 버그를 이슈화시키는 것, Readme 등의 문서를 수정해주는 것(오타 수정조차도), 다양한 언어로 문서를 번역해 주는 것(외국의 프로젝트를 모국인들이 읽기 편하도록 수정해주는 경우가 많음... 정말 감사합니다....), 새로운 기능을 추가하는 것, 일부 복잡하게 쓰여진 코드를 리팩토링하는 것,  베타 프로젝트의 테스터가 되어 주는 것 등 다양한 행동을 모두 포함한다. 보통 풀 리퀘스트로 이어지며, 대부분의 경우 비영리적인 목적으로 자기계발이나 정말 잘됐으면 하는 바람으로 정중하게 요청하는 것이 문화.
12. 머지: 메인테이너가 내용을 확인하고, 전체 프로젝트에 반영해도 괜찮을지 판단해 병합(Merge)하는 것.
13. 리포지토리(저장소, 리포): 코드나 문서를 비롯한 모든 리소스를 저장하는 곳, 일반적으로 프로젝트 단위로 초기화(init)한다. 
14. 포크: 오픈 소스로 원격 리포지토리에 공개된 프로젝트를 내 원격 저장소로 (그!대!로!) 복제하는 것.
15. 클론: 원격 저장소에 있는 프로젝트를 그!대!로 복제해 내 로컬 저장소로 가져오는 것.
16. 이슈: 프로젝트에서 새롭게 추가된 요구사항, 기능 제안, 질문, 혹은 새롭게 발견된 버그들을 원격 저장소에 등록하여, 분업이 겹쳐지지 않도록 하고 다양한 토론을 끌어냄.
17. .gitignore: Node.js 환경에서 node_modules나 파이썬 개발 환경의 venv내 lib 폴더처럼 리포지토리에 저장할 이유도 그럴 만한 여유도 없는 파일들, 혹은 프로그램 유저 데이터나 중요한 키 파일 등 외부에 공개할 수 없는 파일들 같이 다양한 파일과 폴더를 git이 tracking 하지 않고 무시하도록 하는 특수한 파일, 리액트 등의 패키지에서는 기본 설정에 들어있다.

오늘 수업에서는 소스트리를 사용했는데, 이 프로그램은 비트버켓에서 만든건지 디폴트로 비트버켓 아이디를 지원하는데, 깃랩과 깃헙의 아이디(혹은 토큰) 모두 등록 가능해, 동시에 여러 저장소에 업로드할 수도 있다.

컨트리뷰션과 관련된 개발자 문화의 딱 좋은 예.

백문이불여일견이라고 오픈소스 프로젝트에 기여하고 싶다면 초보자에게도 열려있는 오픈소스 프로젝트가 너무도 많다. 사소한 오타나 오역 지적, 딱딱한 번역 어투의 교정부터 시작해서, 요리법 소개 서비스에 요리법을 제보하는 등의 모든 행위가 컨트리뷰션(기여)이라고 할 수 있다. 당신도 할 수 있다!! 나도 할 수 있다!!!

오픈소스 문화에 대해서 들은 말이 있다.

"당신이 온종일 애써서 만든 템플릿은 물론 당신의 실력 향상에 도움이 됐겠지만, 이미 비슷한 것들이 수 없이 많다. 매 프로젝트마다 기본적인 템플릿을 갖추는데에 시간을 쏟는 것은 낭비이다. 평소에 다양한 오픈소스 프로젝트에 기여하고 팔로우업하다보면 폭발적인 성장을 할 수 있을 것이다." 

만약 이 글이 이런 얘기를 당신에게 해준 첫번째 글이라면(일단 하트 하나 눌러주면 저에게 아무 도움은 안되지만 기분이 좋습니다. 구독도 마찬가지입니다.) 여러모로 정신없는 글을 끝까지 읽어주셔서 감사합니다. 최대한 쉽게 설명하는 데에만 온 집중을 쏟아서 공식적인 내용과 다른 부분이 있을 수 있다는 점 말씀 드립니다.

 

아직도 코딩 안배웠어? 5만원 깎아줄께 형아만 믿어