Git은 개발자의 기본 소양이다.

일단 난 개인적으로 개발을 배우기 시작하면서부터 Git을 version control system의 default로 배웠다. 처음에는 도대체 이걸 왜 배울까? 왜 개발자들은 더 user friendly한 tool을 개발하지 않고, 이렇게 복잡하고 직관적이지 않은 tool을 사용할까? 불평했지만, 쓰다보니 그 이유가 이해되기 시작했고, 이제는 Git과 Github 없이는 어떻게 다른 개발자들과 협업을 해야할지 딱히 떠오르지 않는다.

왜 쓰지?

Git은 기본적으로 version control system이라고 하는데, 말 그대로 어떤 프로젝트를 작업하다보면 버젼1, 버젼2, 버젼2-2, 버젼2-2-2-2-2...이런식으로 다양한 버젼이 만들어질 수 있는데, 이러한 버젼들을 관리하고 통합할 수 있는 시스템이 바로 Git이다.

개발을 공부하다보면, 그리고 타 개발자들과 협업을 하다보면 Git은 단순한 version control system을 넘어서, 개발업무의 특성이 비춰진 반사 이미지라는 생각이 든다. 큰 덩어리의 업무를 잘게 나눠 해당 파트를 담당하는 담당자를 지정해주고 궁극적으로는 잘게 나눠진 segment들을 다시 병합하는 과정. 개발도 그렇고 Git도 그러하다.

오늘의 글은 필자가 개발 초심자로서 Git에 대해서 공부할 때 이해가 어려웠던 부분들을 일반인도 알아 들을 수 있게끔 알기 쉽게 설명하는데 초점을 둘 것이다. 따라서 depth가 있는 내용은 다음에 또 한번 별도의 블로깅을 통해 학습해보자.

1. 큰 그림 그리기

내가 어떤 어렵고 복잡한 개념을 학습하기에 앞서 가장 먼저 하는 일은 해당 개념을 형상화 할 수 있는 큰 그림 혹은 비슷한 실루엣을 실상에서 찾아보는 것이다. 그래서 아래의 이미지를 가져와봤다.

아래와 같은 미술 작품을 그린다고 생각해보자. 혼자 그린다면 중앙부터 시작을 할수도 있을 것이고 좌,우,상,하 마음에 드는 코너를 선택해서 그냥 그려나가기 시작해도 문제가 없을 것이다. 그런데 만약 다른 미술가 5명, 10명, 20명과 같이 작업을 해야한다면 어떻게 해야할까? 맞다. 전체그림을 가상으로 분리해 각자에게 권한과 완성의 책임을 위임하면 될 것이다.

Git 또한 비슷한 개념이다. 전체의 그림을 Master 혹은 Master branch 라고 생각해보자. 당장에 그리지도 않았으니 대략적인 구상만 존재할 뿐 실체는 없을것이다. 그래도 우리는 그런 구상을 Master branch라 칭하고 해당 요소가 최종적인 결과물이 될 것이라고 약속하는 것이다.

그 다음은 당연히 이 구상을 여러 조각내서 각 담당자를 지정하고 정해진 기간내 책임지고 완성해라고 위임해야한다. 이것을 우리는 sub branch 라고 할수있겠다. 아래의 이미지 처럼 각 섹션에 ①branch, ②branch 라고 번호를 매겨 책임자가 해당 branch(섹션)를 담당하는 것이다.

일단 위 이미지를 머리속에 가지고 시작할 수 있다면 앞으로 학습할 개념이 그렇게 어렵게 다가오진 않을 것이다.

2. Terms(용어정리)

Git을 학습하면서 가장 먼저 막혔던 부분이 Git 사용시 빈번하게 등장하는 용어(terminology)였던것 같다. 그래서 일단 아래에서 빈번히 사용되는 용어를 정리하고 다음 단계로 넘어가자. 이해를 돕기위해 큰그림 그리기에서 사용한 예술작품을 중심으로 계속해서 예를 들겠다.

directory: 디렉토리는 프로젝트가 저장된 장소(폴더)를 의미한다. 여러 미술가가 각자가 담당한 섹션을 작업하고 안전하게 보관할 수 있는 창고나 보관공간이 필요할 것이다. 이를 directory라고 보면 쉽게 이해할 수 있다.

cd: change directory를 줄인 것으로 말 그대로 보관소를 A에서 B로 변경할 때 사용하는 명령어다.

repository: 처음 학습할때 가장 모호하게 다가오는 단어이기도 한데 사실 그냥 project 그 자체라고 보면 된다. project를 곧 repository에 저장하는 것이기 때문이다. 영어단어의 뜻도 "저장소" 그 자체다.

github: 많은 사람들이 학습 초반에 git과 github를 구분하지 못하는데, github은 git을 호스팅하는 호스팅 서비스라고 보면된다.

3. Git commands(명령어)

이번 포스팅에서 우리에게 필요한 명령어는 몇개 되지 않는다. 빠르게 학습하고 넘어가자.

clone: Github에서 repository를 생성하고 나면 해당 repository address(주소)를 local repository로 클로닝 해야한다. 쉽게 말해서 remote repository(github에 생성한 repository)와 local repository(내 컴퓨터에 생성한 directory)를 "연결"해주는 작업이라고 한다.
실제명령어: git clone http://blahblahblah

add: 해당 디렉토리에서 작업을 하고 나면 내용이 당연히 변해 있을 것이다. 위 그림에서 볼 수 있듯 일단 자신이 작업한 내용을 master와 병합(merge)하기 전에 가장 처음 해야하는 단계라고 할 수 있다. add를 하게되면 해당 변경사항이 staging되게 된다. 본인이 지금까지 그린 섹션을 임시보관소로 옮기는 개념이라고 생각하자.
실제명령어: git add .

commit: staging한 본인의 작업물을 local repository로 옮기는 명령어다. 이전 단계인 add를 통해 임시보관소로 이동시켰다면, commit을 통해 물류허브로 옮겼다고 생각하자. 물류허브에서는 이제 해당 제품을 실어서 해당 예술품을 보관/관리하는 Product manager에 전달하기만 하면 된다.
실제명령어: git commit -m "Add: A섹션을 색칠함"

push: 이제 고지에 도달했다. push를 하고나면 본인이 작업한 분량(branch)가 product manager한테 전달되고 심사를 통해 원본과 병합(merge)되게 된다.

4. 그러고 나서는?

사실 위에서 거짓말을 했다. push를 한다고 끝나는건 아니다. push를 하는것이 product manager에서 본인이 작업한 작업물을 전달하는 과정이었다면, 이제 product manager에게 해당 작업물이 현관문 앞에 도착했다는 사실을 알려줘야 할 것이다. 그리고 자신이 작업한 작업물에 대해서도 어떤 의도로 어디를 작업하고 바뀌었는지 친절하게 설명해준다면 좀 더 점수를 딸수있지 않을까?

이 작업을 pull request라고 한다. 위 이미지에서 5번에 해당하는 작업이다. 이제 진짜 product manager가 본인이 작업한 작업물을 보고 평가해서 통과하게 되면 project 전체에 반영해 주는 것이다!

안다. 여기까지 읽고나면 "뭘 이렇게 복잡하게 만들어 놨지?" 라고 생각하고 있을 거란걸. 요즘같이 주문 하루만에 제품이 현관앞에 도착하는 시대에 이게 도대체 무슨 쌍팔년도 배송 process인가 라고 생각할 수도 있다. 하지만 잊지마라. 우리는 매우 귀중한 미술품을 다루고 있다. 5000원 짜리 인스턴트 라면을 주문한 것이 아니다.

전달되는 과정은 중간중간 체크되어야 하고 저장되어야 하며 신중하게 최종심사를 거쳐 미술품으로 탄생하는 것이다.

아직도 와닿지 않는 소리로 들린다면 웹사이트 하나를 클로닝 해보면 된다. 사소한 기능 하나를 구현하기위해 얼마나 많은 개발자의 시관과 고민이 들어가는지 경험하고 이해하고 나면 개발자가 하는 일이 미술작품을 만든는 것과 별반 다를게 없다는 것을 느끼게 된다.