이 시리즈를 포스팅하게 된 계기는 한달전부터 Ubuntu 를 사용을 시작한 것이다.

vim과 터미널 명령어들을 배우면서 슬슬 GUI보다 CUI에 익숙해지고 있어서 git도 이제 GUI 프로그램을 사용하지 않고 명령어를 외어서 사용하려는 중이다. 하지만 git에 입문하는 처음이라면 꼭 GUI 프로그램을 사용해라.하는 것을 추천한다.

대체 누가 git 입문 책에서 CUI로 알려주는지. git은 꼭 GUI로 시작해라.

처음에는 branch라는 개념이 직관적으로 다가오지 않으며, 여러 branch가 꼬이기 시작하면 머리도 같이 꼬일 수 있다. 

또한 아무리 CUI가 입력하기엔 편해도 visualize 하는 면에 있어서는 GUI를 이길 수 없다. 나는 CUI에 익숙해져도 GUI git을 지우지는 않을거라고 확신한다.

GUI로 git을 사용할 수 있게 해주는 프로그램은 그렇게 많지 않다. 

처음에는 GitHub에서 자체제작한 GitHub Desktop을 사용했는데 깔끔한 그래픽의 군더더기 없는 디자인이라 마음에 들었지만 git의 모든 기능을 구현하지 않은 것 같고, 전반적으로 UI가 휑한 느낌을 주었다.

단순한 기능들만 사용한다면 추천하기는 한다. 

이후로 본격적으로 git을 사용하게 만든 장본인은 Sourcetree이다. GitHub Desktop과는 다르게 다양한 기능들을 구현을 해두었고, 구현한 기능들에 비해 디자인도 깔끔하게 만들어서 한동안은 정말 잘 썼으나... 2016년즈음 자꾸 내부 프로그램 문제가 발생해서 설치-재설치, GitHub Desktop으로 갈아탔다 다시 오기를 몇 번.. 아주 지쳐버렸다. 

지금은 그래도 그때보다는 더 안정화 되어있을 것이다. 하지만 돌아갈 생각은 없다. 

시커먼 화면을 좋아해서 그런지 한번 적응하고 나서부터는 바꿀 생각을 전혀 안하고 있다. 

UI는 위의 두 프로그램의 딱 중간정도지만 복잡한 기능들도 다 구현이 되어있고 아직까지 한번도 크래시가 난적이 없다.

의외로 이 프로그램에 대한 소개가 별로 없는 것 같기에 프로그램에 대한 애정을 담아 이후 포스팅부터는 이 프로그램을 기준으로 설명하겠다. 

2017년 이후 거의 3년간 문제없이 쓰고 있는 것은 GitKraken이다. 

마무리

아마 직접 git을 설치하는 일은 없을 것이다. 혹시 리눅스 유저라면 이미 git이 기본으로 깔려있을 것이고, 윈도우 유저라면 바로 GUI 프로그램인 GitKraken을 깔자. 이 프로그램 역시 학생에게 무료로 Pro 버전을 제공한다. 

https://www.gitkraken.com/student-resources

이전 포스트에서 GitHub에 가입을 하고, 이번 포스트에서 GitKraken을 설치했다면 이제 준비는 끝이다. 

다음 포스트부터 바로 실제 git에 구조와 사용법에 대해서 작성하도록 하겠다. 

원래 두 번째 글은 왜 git 이 필요한지에 대해서 작성하려고 했으나 계획을 변경했다. 

첫째, 일단 난 왜 git이 필요한지 안다. 굳이 여기서 간증글을 쓸 시간은 없다.

둘째, 지금 이 글을 보는 사람이 git의 필요성을 모르고 들어왔을 거라고 생각하지 않는다. 

셋째, 행여 git의 필요성을 모르는 사람이 들어왔으면 아마 아직 짠 코드 양이 적어서 그럴 것이라고 추측한다. 
코딩을 더 하다가 오면 생각이 바뀌지 않을까.

그럼 바로 git과 GitHub의 관계부터 짚고 넘어가겠다.

git

git 은 버전관리(version-control) 프로그램이다.

버전 관리 프로그램은 말 그대로 파일의 "버전"을 관리해주는 프로그램이다. 

처음에 이 말을 들었을 때는 "뭔 버전? 워드 2013 뭐 이런 버전인가?" 했는데 다음 짤을 보고 한 번에 이해가 되었다. 

한컴오피스나 Word의 검토 기능을 자주 사용해본 사람이라면 다음 그림도 익숙한 화면일 것이다. 

버전 관리 프로그램의 주된 목적은

1. 첫 번째 사진과 같이 같은 파일을 여러 번 다양한 사람에 의해서 수정을 해야 하는 경우 각각의 파일들을 최신순으로 추적해 주며
2. 두 번째 사진과 같이 각 파일이 이전 버전들과 어떻게 달라졌는지를 비교해주는 것이다. 

git은 이러한 버전 관리 프로그램의 한 종류이다. 

뭐 대충 2000년대 전에 개발되었을 거고 2005년에 개발이 되었고, 개발자는 리눅스의 개발자 Linus Torvalds이며 현재는 일본인 개발자 Junio Hamano에 의해 유지되고 있다. 

버전 관리 프로그램의 종류는 git 외에도 수 십 종이 있으나 현재 적극적으로 사용되고 있는 것은 많지 않고 굳이 하나를 더 알아야겠다면 CVS랑 Subversion 정도. CVS, Subversion, git 모두 오픈소스에 누구나 쉽게 사용할 수 있지만, git은 모든 사용자가 데이터를 가지고 있지만 CVS와 Subversion은 중앙집중형 시스템이라는 점에서 다르다.

기업에 들어가면 자체 버전관리 시스템을 사용하게 될 것이고, 그 외에는 거의 대부분이 git을 사용하고 있다고 생각해도 무방하다. 

하지만 이러한 버전 관리를 포함하는 모든 데이터 관리의 핵심 기능이 하나 빠졌다. 

바로 백업과 공유이다. 

GitHub

GitHub는 git을 더욱 손쉽게 사용할 수 있도록 해주는 온라인 서비스이다.

GitHub는 git이 나온 지 3년 뒤에 론칭했다. git 프로그램이 이렇게 인기 있는 버전 관리 소프트웨어로 성장하도록 만든 중요 동력원 중 하나가 아닐까 하고 생각할 정도로 다양한 기능들을 제공하며 무엇보다 remote repository를 무료로 제공해준다. 

git은 앞서 설명했듯이 중앙집중형인 CVS와 다르기에 모든 데이터가 로컬 컴퓨터에 저장이 된다.(local repository) 때문에 만일 로컬 컴퓨터에 문제가 생기거나 데이터가 있는 폴더를 실수로 홀라당 날려먹으면 버전 관리고 뭐고 끝이 난다. 

git에서는 이러한 문제를 원격 저장소, remote repository라는 것을 사용해서 해결할 수 있는데, 말 그대로 로컬에 있는 데이터를 local이 아닌 다른 컴퓨터 (주로 클라우드 서버)에 저장하여서 데이터를 백업해둘 수 있다. 

하지만 이를 단순히 "백업"이라고 말하기에는 마음이 편하지 않다. 심지어 GitHub의 Help page에 들어가면 "Git is not adequately designed to serve as a backup tool."이라고 언급을 하고 있다. 물론 원격 저장소를 사용하면 로컬에 있는 데이터를 백업해두고, 로컬에 문제가 있을 때 다시 복구할 수 있지만, 다른 사용자와 코드를 공유하거나 완성된 프로그램을 배포하는 등 훨씬 다양한 기능을 수행할 수 있다.

굳이 백업이라는 단어를 써서 원격 저장소를 설명하자면, "소스코드에 특화된 강화된 기능을 가지는 공개용 백업"?

몇 가지 GitHub의 기능을 나열하면 아래와 같다.

• 원격 저장소 기능
• Issues : 버그 신고 혹은 기능 추가 요청. "이 기능 좀 넣어주세요~", "이거 안 되는데요?"
• Pull requests : 다른 사용자가 직접 코드를 수정해서 원격 저장소 오너에게 이 코드를 사용해달라고 제안하는 기능.
• Wiki : 원격 저장소에 있는 프로그램에 대한 위키 페이지 운영 기능.
• Releases : 배포용 프로그램 생성 기능.

이 모든 것을 무료로 제공 가능한 이유는 단순한 텍스트 파일인 소스코드의 크기가 크지 않기 때문이다. 

때문에 GitHub에 올리는 파일의 크기는 아래와 같은 제약을 받는다.

한마디로 소스코드 외에 다른 것들은 가능하면 올리지 말라는 것이다. 

예전에는 사전에 지정한 사람만 들어올 수 있는 비공개 원격 저장소를 무료 계정에서는 5개로 제한했었는데 이 제한은 없어진 모양이다. 월 USD7을 내면 Pro 계정으로 업그레이드가 가능한데 이마저도 학생들에게는 무료로 제공하고 있다. 

아래 링크를 참고할 것.

https://education.github.com/pack

물론 Github가 git을 위한 유일한 원격 저장소 서비스 제공자는 아니다.

GitLab, Bitbucket 등 다양한 업체가 있으나 둘러본 적은 없다.

따라서 앞으로의 글도 GitHub에 초점을 맞춰서 작성할 예정이다. 

잘못된 정보는 댓글로 지적해주시면 정말 감사하겠습니다!

어디까지나 프로그래밍은 취미이다.

라고 스스로에게 계속 되뇌고 있지만 이제는 슬슬 인정할 때가 되지 않았나 싶다. 

내게 있어서 프로그래밍은 이미 생활의 일부라고.

각설하고 연구를 위해서도 그렇고, 진정한 취미 프로젝트를 위해서도 그렇고 버전 관리는 필수다. 

심지어 이제 막 프로그래밍을 배우기 시작하는 사람도 git 사용법을 같이 배워야 한다고 생각한다.

과학에서 연구를 할 때 실험을 배우기 전에 연구노트 작성법에 대해서 알려주듯이 프로그래밍을 하는 사람들도 코딩을 제대로 배우기 전에 git 사용법에 대해서 알아야 한다. 원하든 원하지 않든 한번 짠 프로그램은 가능한 기록을 해두는 것이 좋고, 이 기록을 체계적으로 남기기 위해서는 Github 만한 플랫폼이 없다. 객체 지향이나 multi threading 같은걸 알려주기 전에 학습하면서 짜둔 코드를 효율적으로 기록하는 법을 알려주는 게 옳지 않을까. 

또한 프로그래밍 초반이야 말로 다른 사람의 코드를 자주 보게 되는데 "그거 내 깃헙에 올려뒀어요~" 라던가 Github 뭐시기 링크만 달랑 첨부되어 있는 경우 코드를 어떻게 받아야 할지도 모르기 때문이다. 내가 비전공자라 그런지 나름 주변에서 프로그래밍을 배웠거나, 지금도 코딩을 하고 있는 사람들에게 코드 전달 목적으로 깃헙을 알려주면 답답한 일들이 자주 발생한다. 거의 대부분은 내가 업데이트를 할 때마다 전체 파일을 zip으로 다운로드하여서 필요한 코드를 골라가기만 하고 제대로 사용할 줄을 모른다. 최소한 raw 버튼의 사용법만 알아도 바로 필요한 코드만 긁어갈 수 있을 텐데.

나도 한동안 git을 쓰지 않았다. Cloud에 코드를 죄다 올려두고 자체 backup 기능이나 파일 버전 관리 기능을 사용해서 오랫동안 작업을 했었다. 그러다가 조금 내용이 많이 바뀐 것 같으면 프로젝트 파일을 통째로 새로 저장하고, 다른 목적을 위해서 프로그램을 수정하게 되어도 또 새로 저장하고... 그러한 결과 아래와 같은 일이 벌어진다.

전부 같은 "출석 부르기" 프로그램인데 사용목적과 내용에 따라서, 그리고 개발 상태에 따라서 폴더를 새로 만드니 뭐가 뭔지 알 수 없게 되었고, 각각 업데이트한 내용이 달라서 서로 호환도 안된다. 

정말로 코드 짜는 건 20% 밖에 안되고, 의외로 유지보수가 80%나 된다. 주석 잘 달아두자.

CUI가 익숙하지 않아서 이것저것 알아보다가 Sourcetree를 계기로 git에 입문했다. 

대략 다섯 권의 git 혹은 Github 관련 책을 읽었으나 생각보다 내용이 중구난방으로 작성되어 있었고 알파벳순으로 정렬된 매뉴얼처럼 정신없었다. 그래도 꾸역꾸역 읽어서 이제는 별문제 없이 사용하지만, conflict error가 나거나 이전 commit으로 돌릴 때, Github 특화된 기능을 사용할 때는 머리가 터질 뿐이다. 

'아씨 내가 차라리 책 한 권을 쓰면서 배우는 게 빠르겠다!'라는 생각에 이 글을 시작한다. 

우선순위를 고려한 목적은 아래와 같다. 

1. 내가 git의 모든 커멘드에 익숙해질 수 있도록.

2. 이후에 사용법이 궁금할 때 이 글들을 보고 refresh 할 수 있도록. 

3. git 혹은 github 관련 궁금증이 있을 때 제일 먼저 이 블로그로 사람들이 찾아오도록 하기 위해.

시간을 최대한 내서 끝까지 포스팅 할 예정이다. 

PS 출판을 원하시면 언제든 연락주세요