[GITHUB 입문] Git과 GitHub의 차이

---

[GITHUB 입문] 깃허브 사용법 -  1

Git과 GitHub의 차이

---

 

이미지를 클릭하면 'GitHub'로 이동합니다

코딩을 하다 보면 꼭 접하게 되는 "Github"이다. 여러 오픈 소스, API, 논문 속 코드의 구현 등 정말 많은 코드들이 생태계를 이루고 있기 때문이다. 그러나 부끄러운 말이지만 나는 GitHub를 거의 사용해본적도 없고 사실 어떻게 사용하는지도 잘 모른다. 가끔 코드를 참조하거나 API를 사용하기 위해 들러본 것이 전부이다.

하지만 항상 생각해왔다. 나도 깃허브를 익혀서 매일 Commit을 빼곡히 채우겠다고.

그리고 그것이 오늘 이 글을 쓰는 동기이다. 미루고 미루던 깃허브를 오늘 익혀보기로 마음먹었기 때문이다. 혹시라도 이 글을 보게 되는 사람이 있다면 어설프지만 꼭 도움이 되면 좋겠다. 

 

깃과 깃허브의 개념

▣깃과 깃허브는 같은 것인가?

결론부터 말하자면 아니다.

깃은 로컬 파일의 변경사항을 기록하고 해당 파일에 대한 여러 사용자 간의 작업을 조율하기 위한 버전 관리 시스템(VCS : Version Control System)이다.

깃허브는 깃을 클라우드 방식으로 구현된 버전 관리 시스템(VSC)이다. 로컬 파일을 깃허브 클라우드에 Push(업로드)하여 서로 다른 위치에 있는 여러 사용자가 작업할 수 있다.

유튜브 노마드 코더 니콜라스의 쉬운 비유에 따르면 깃은 '커피'이고 깃허브는 '커피샵'이다. 사실 

Git과 GitHub

▣깃을 왜 써야하는가?

1. 깃이 없는 프로젝트의 한계점

프로젝트를 진행함에 있어서 '버전 관리'는 필수이다. 

고객에게 의뢰를 받아 프로젝트를 진행해본다고 가정해보자. 소프트웨어 프로젝트는 그 특성상 만드는 과정 뿐만 아니라 운영하는 과정에서까지 생성, 수정, 삭제 등 수많은 변경사항이 발생하게 된다. 그렇기 때문에 1)이전 코드를 다시 복원해야 할수도 있고 2) 실수로 오류가 난 코드를 되돌려야 할수도 3) 코드의 변경사항을 추적하여 어디가 어떻게 바뀌었는지 확인해야 할 상황이 올 수 있다. 만일 중간중간 따로 백업해두지 않았다면 앞선 상황이 굉장히 곤란하게 다가올 것이다.

그러나 백업을 통해 위와 같은 상황을 대비하면 상당한 애로사항이 발생한다. 첫째로 파일 크기가 백업 수에 비례하여 늘어난다. 규모가 큰 프로젝트라면 이를 감당하기는 더욱 어려울 것이다. 둘째로 관리가 꽤나 번거롭다. 정리를 잘 해두었다면 원하는 파일을 찾기는 쉬울지 모르나 변경사항을 일일이 기록하기까지는 쉽지 않을 것이다. 세번째로 파일채로 백업하는 그 특성상 함수 하나를 수정하기 위해 통째로 파일을 바꿔야 할 수도 있다.

위와 같은 문제보다 더욱 심각한 문제도 있다. 바로 '협업'이다.

대규모 프로젝트의 경우 여러명의 개발자가 함께 작업을 하게 된다. 꼭 대규모가 아닌 교내 팀 프로젝트에서도, 공모전에서도 협업은 필수이다. 협업은 프로젝트가 진행되는 메인 폴더를 기준으로 여러 개발자들이 각자의 폴더와 파일을 맡아 진행하게 된다. 소프트웨어 프로젝트는 간단한 테스트를 하려고 해도 모든 파일과 폴더가 전체적으로 구성되어 있어야 가능하다. 여기서 각자의 작업 진행사항을 서로간에 어떻게 공유할 것인가하는 문제가 발생한다.

2. 깃을 곁들인 프로젝트

앞서 언급했듯 깃은 파일에 대한 모든 변경사항을 기록한다. 즉 파일의 '버전 관리'가 아주 용이해진다. 파일의 무엇이, 어디서, 몇 번, 누구에 의해 등 모든 변경 사항이 기록된다. 다음 진행 과정을 통해 이러한 '버전 관리'가 어떻게 이루어지는지 알아보자.
(직접 과정을 따라해보고 싶다면 다음 글을 참고하여 깃 설치를 먼저 수행하자)

[GITHUB 입문] Git 설치하기(2.3.3.1 이상, 상세한 설치법)

[GITHUB 입문] Git 설치하기(2.3.3.1 이상, 상세한 설치법)

$git init

프로젝트를 진행할 특정 폴더를 선택하고 Git을 시작한다면 해당 폴더의 모든 진행 과정이 저장되는 공간(.git)이 생긴다. 

$git add -A

프로젝트 폴더가 설정 되었으니 폴더 안의 모든 파일들을 깃의 대상에 포함시킨다.

$git commit -m "작업수행내용"

마치 카메라로 사진을 찍듯이 현재 시점의 작업 내용을 깃에 저장한다. 즉 프로젝트에 의미있는 분기점, 변화의 순간마다 이 '커밋'을 통해 작업 내용을 보관하는 것이다. 이때 깃은, 일반적인 백업처럼 전체를 보관하는 것이 아닌 이전 버전과의 변경사항만을 기록한다. 즉 .git의 용량은 오로지 얼마나 프로젝트가 수정되었는가에 결정될 뿐 커밋을 많이 한다고 해서 용량이 곱절로 늘어나는 일이 없다.

$git logs

그렇게 보관된 일종의 '분기점' 또는 '기록시점'들은 위 명령어를 통해 확인할 수 있다.

$git  reset --hard 6자리기록번호

만약 특정 시점으로 돌아가야하는 상황이 발생한다면 깃은 수정된 내역들을 복원하고, 새로 만든 파일들은 삭제하는 등 저장했던 그 시점의 상태로 감쪽같이 되돌려준다.

$git branch "branch이름"

또한 실험적인 시도, 새로운 기능을 시험해볼때는 기존 프로젝트와 분리하여 진행할 수도 있다. 나무의 가지치기를 하는 것처럼 주 프로젝트에 영향을 주지 않고 다양한 기능이 구현된 여러 버전을 생성하는 것이 가능하다.

$git merge "branch이름"

만약 가지치기하여 시도해본 버전이 너무나 훌륭하여 메인 프로젝트에 추가하고 싶다면 이 또한 Git을 통해 손쉽게 가능하다. 

그렇다면 '협업'은 어떻게 진행되는가? 앞서 협업에 대한 문제를 언급하면서 각자의 작업 진행사항을 어떻게 취합할 것인가에 대해 문제를 제기했다. 그러나 지금까지 이 글을 따라오며 Git의 기능에 대해 파악했다면 지금부터 무슨 말을 하려고 하는지 감이 잡힐 것이다.그렇다. Git의 프로젝트 폴더가 원격의 공용 공간에 있다면 상기 문제가 해결된다. 원격의 프로젝트 폴더를 Git을 통해 다운 받고, 각자의 작업을 진행한 후 다시 Git을 통해 전송하면 된다. Git은 버전 관리를 훌륭히 소화하기 때문에 협업 과정에서 문제가 생기더라도 그 1)원인을 신속히 파악할 수 있고 2)신속히 해결/복구할 수 있다.