git 튜토리얼 (1)

들어가면서

Git을 자주 쓰는 사람들은 Git이 대세라고 확신할테고, 심한 경우에는 "요즘 Git도 안 쓰고 개발이 되냐"고 말하기도 한다. 그러나 아직 많은 사람들이 Git에 손을 못 대고 있거니와, 쓰더라도 자세히 모르고 그냥 쓰는 경우도 많다.

Git의 장점은 그냥 강력하다는 것이고, 단점은 개발의 핵심도 아닌 도우미 프로그램 치고는 너무 복잡하다는 것이다. 여기서 한 가지 위안거리가 있는데, Git의 기능 중 한 가지라도 배우면 그건 반드시 유용하게 써먹게 된다. 강력하고 어려운데 쓸데없다면 그게 왠 똥인가 말이다. 그런데 Git은 최소한 다 쓸모있다. 배운만큼 써먹자.

형상 관리 프로그램

형상관리 프로그램을 사용하지 않으면서 버전 관리를 할 수 있는 대표적인 방법은, 프로젝트 통째로 zip으로 압축하고 이름에 날짜를 적어 보관하는 것이다. 과거의 코드를 보고 싶으면 특정한 날짜의 압축을 풀어서 확인하면 된다. 매번 중요한 순간마다 zip으로 압축하는 것이 git에서 커밋(commit)이랑 똑같다.

커밋이란 말은 앞으로 자주 쓸 텐데, 지금은 소스 코드에 대한 청사진, 혹은 스냅샷 정도로 생각하면 좋다. 그냥 소스코드 버전으로 생각해도 된다. 특별히 결정적인 순간마다 저장해서 나중에 두고두고 꺼내보고 비교해볼 수 있다. 한 번 커밋한 내용은 원칙적으로 수정이 불가능하다.

형상관리 프로그램을 이용하면 매번 zip으로 압축해서 소스 코드를 보관할 필요가 없다. 대신 커밋으로 빠르게 코드를 보관하고 복원할 수 있다. 여러 사람이 작업할 때도 간편하게 버전을 관리할 수 있다. 버전 간의 차이점을 확인하고 싶을 때도 편리하게 툴을 이용할 수 있다.

SVN과 차이점

SVN에서는 모든 소스 버전 정보를 서버에서 관리한다. 프로그래머는 서버에 접속해서 특정한 버전의 커밋을 다운받고 편집한 뒤 새 버전으로 서버에 커밋한다. 반면에 Git은 모든 정보를 서버로부터 카피(clone)해서 로컬에 저장한다. 커밋도 로컬에서 한다. 서버와는 단지 sync를 맞출 뿐이다.

SVN이 웹메일이나 클라우드 컴퓨팅처럼 동작한다면, Git은 Google Drive처럼 동작한다.

Git과 GitHub

  GitHub는 Git으로 생성된 저장소를 운영하는 사이트이다. 기존 Git에 사용자 관리, 이슈 관리, 웹 소스 편집 등 기능을 붙여서 만들었다. GitHub 이전에 오픈 소스의 성지로 불리던 곳은 SourceForge인데 SVN으로 운영된다. 사람들은 SourceForge를 즐겨 이용하면서도 한 편으로는 자신만의 저장소를 만들고 싶어했다. 왜냐하면 SourceForge가 없어질 경우 모든 관리 데이터를 잃어버리기 때문이다. 이것은 모든 계란을 한 바구니에 담는 것과 마찬가지이다. 그래서 Google이나 Microsoft 등 굴지의 회사들은 SourceForge 이외에 자신들만의 저장소를 만들어서 운영하고자 했다. 그런데 GitHub가 나타나면서 모든 고민은 사라지고 GitHub 세상이 됐다. 이 세상 거의 모든 오픈소스 프로젝트를 GitHub에 담으면서도 사람들은 예전처럼 불안해하지 않는다. 서버와 동일한 관리 정보가 바로 자신의 컴퓨터에 있기 때문이다.

GitHub를 사용하면서도 한편으로 얼마든지 자신만의 서버를 만들어서 모든 내용을 GitHub와 공유할 수 있다. 로컬 컴퓨터의 내용을 두 군데 서버와 동시에 싱크를 맞추면 그만이다.

도우미 GUI  프로그램

Git은 기본적으로 command line으로 동작하게 만들어졌다. 윈도우 95가 나오면서 GUI 혁명이 이뤄진지 20년이 훨씬 지나가지만 아직도 command line방식을 고수하고 있는 프로그램이 있는데 Git 또한 그렇다고 하겠다.  이를 참다 못한 사람들이 Git API를 이용해서 GUI로 만들어놨다. 이것들은 사용하면 좋긴 한데, 자칫 Git에 대해 오해한 상태에서 계속 쓸 여지도 있다. 하여 우선 본 튜토리얼은 command line으로 진행하고, 나중에 GUI 프로그램도 살펴본다. 핵심 내용만 짚으면 별로 복잡한 명령어도 없다.

지금부터 튜토리얼 시작

이제 진짜 시작이다.

GUI 프로그램을 활용하면 쉬워보이기는 하는데 핵심적인 원리와 내용을 설명하기가 어렵다. 그래서 우선은 커맨드 라인으로 진행하고, 나중에 GUI도 설명할 계획이다. 사실 커맨드 라인으로 다룰 줄 알게 되면, GUI 프로그램은 자동으로 그냥 사용법을 이해하게 된다. 진짜, 뻥 아니고.

위에서 잠깐 언급했듯이 Git은 기본적으로 서버 없이 로컬에서 돌아가는 프로그램이다. 만약 혼자 간편하게 소스코드를 관리할 목적으로 git을 사용한다면 GitHub도 필요 없고, 서버도 필요없이 간단하게 Git만 설치하면 된다.

모든 설명 과정은 윈도우 사용자 기준으로 진행된다. 리눅스 사용자들은 아무래도 알아서 잘 하는 습관이 되있을테고 이런 설명도 필요 없겠지.

Git을 설치하는 방법에는 여러 가지가 있는데, Visual Studio를 설치하다 보면 같이 번들로 설치되기도 한다. 어쨌든 가장 보통의 방법은 직접 다운받는 것이다. 대뜸 깃허브로 들어가면 다운 못 받는다. 거기는 git서비스를 제공하는 곳이고 https://git-scm.com 으로 들어간다. 첫 화면에 바로 다운로드 버튼이 보인다.

설치 과정 중에 default editor를 선택하게 된다. git에서 왠 에디터냐? 파일끼리 병합하고 어쩌고 하는데 에디터가 필요하다. 사실 여기 튜토리얼을 진행할 때는 별 필요가 없으므로 일단 적당히 아무거나 선택하고 넘어가자.

나머지는 그냥 대충 Next를 눌러도 상관이 없을 것 같다.

자, 이제 Git을 시작해보자. Git은 데이터베이스가 필요없다. 모든 소스 관리 정보를 소스코드가 들어있는 그 폴더 속에 저장한다.

커맨드 창(Command Prompt)을 띄우고 대뜸 git이라고 입력해보자.

아무 내용이나 막 나오면 일단 잘 깔렸다. 방금은 git.exe라는 프로그램을 실행한 것이다. 앞으로 이것을 git 프로그램이라 부르겠다.

이제 소스 코드가 들어있는 폴더로 이동한다. 이미 소스 코드가 들어있어도 상관없고, 빈 폴더에서 시작해도 좋다. 어쨌든 폴더로 가야 하는데, 커맨드 입력이 서툴면 아래 그림을 참고한다.



하여튼 드라이브를 옮길 때는 X: 와 같이 콜론을 이용하고, cd 명령어를 통해 폴더로 들어간다. 폴더에서 나오려면 "cd .." 을 입력하면 된다.

우선 나는 빈 폴더를 만들어서 시작할 것이다. 최초의 저장소를 생성하는 명령어는 git init이다. 앞서 말했지만 git init명령은 반드시 빈 폴더에서 할 필요가 없다. 이미 잘 돌아가고 있는 소스를 Git으로 관리하고 싶을 때도 그 시작은 git init이다.

명령이 실행되고 나면 .git 이라는 숨김 폴더가 생성된다. 리눅스에서 '.'으로 시작하는 이름은 무조건 숨김 속성이 되는데, 윈도우에서는 Hidden속성이 따로 부여된다. 폴더 내에 .git 폴더가 있으면 그것은 git으로 관리되는 폴더라고 할 수 있다. git프로그램은 반드시 .git폴더가 보이는 곳에서 실행해야 한다.

.git 폴더에는 Git 관리 정보가 다 들어간다. SVN으로 따지면 서버에 저장되어야 할 모든 정보들이 .git 폴더에 저장되는 것이다. 당연히 용량이 상당한데, 보통 관리되는 소스코드의 1/2 정도 크기이다. 나름의 방식으로 압축이 된다.

Git으로 관리되는 소스 코드를 카피할 때, .git 폴더만 카피해도 된다. 모든 커밋 정보가 .git 폴더에 들어있기 때문이다. 실제 소스 코드는 .git속에 들어있는 커밋을 이용해서 복원하면 그만이다. 서버에서 소스를 다운받을 때(clone) 실제로는 .git 폴더를 다운받는다.

현재 저장소의 상태를 확인하는 명령어는 git status이다.

뭐라고 영어로 나오는데 뭔 말인지 하나씩 살펴보자.

On branch master => 현재 branch를 나타낸다. 지금은 branch를 소스코드의 어떤 갈래, 분기점이라고 이해하자. branch가 아예 없으면 안 되니까 기본으로 하나 생성해주는데, 그 이름이 master이다.

No commits yet => 아직 아무 커밋도 없는 백지상태이다.

nothing to commit => commit할 파일이 없음을 나타낸다. 마지막 커밋과 비교해볼때 내가 작업한 내용이 없다는 뜻이다.

이제 이 폴더에 아무 작업이나 해보자. 여기서는 file.txt를 만들고 아무 내용이나 넣어보자. 기왕이면 두 개를 만들자.

이제 git status 를 다시 입력하면 다음과 같이 나타난다.

Untracked files 라는 문구가 있다. 처음 보는 파일, 혹은 관리되지 않는 파일이라는 뜻이다. 소스 코드 내의 모든 파일은 매 커밋 때마다 변화를 추적하는데, 이 파일은 아예 첨 본다는 뜻이다.

이제 새로 만든 파일을 커밋할텐데, 그러려면 파일을 스테이지에 올리는 작업이 필요하다. 이게 무슨 말이냐? 수정된 파일이 엄청 많은데, 그 중에서 필요한 파일만 꼭 커밋하고 나머지는 임시로 만든 것이니 그대로 두고 싶을 수 있다. 그럴 때 필요한 파일만 스테이지에 올려서 커밋하고, 나머지는 그대로 둔다. 대체로는 소스를 빌드해서 생긴 exe파일이나 기타 임시 파일들은 커밋하지 않고 소스 파일만 커밋한다.

여기 예제에서는 file.txt를 커밋하고 싶으니 이것만 스테이지에 올린다. git add 명령을 이용한다.

스테이지에 올라간 파일은 커밋 대기 상태가 되며, 이 순간 파일의 내용은 임시로 저장된다. 만약 파일이 너무 많으면 "git add --all"로 모든 언스테이지 파일을 스테이지에 올릴 수 있다. 참고로 별표(*)를 이용하는 것도 가능하다.

스테이지에 파일을 올렸는데 지우거나 수정하면 어떻게 되나? 직접 해 보면 안다.

스테이지에 올라간 상태를 기점으로 해서 변경된 내용은 언 스테이지 상태가 된다. 만약 이 상태로 커밋하면 스테이지에 올릴 당시 저장되었던 file.txt의 내용이 커밋된다. 하여튼 스테이지에 올린다는 것은, 커밋할 내용을 고르기 + 임시로 저장하기 정도로 생각하면 된다.

만약 스테이지에 올리고 수정 후 또 올리고 .. 를 반복한다면 ? 스테이지가 여러 개 생기느냐? 그건 아니고 그냥 하나의 스테이지가 계속 누적되어 유지된다.

하여튼 원점으로 돌아와서 file.txt를 다시 만들고 add 명령으로 재차 스테이지에 올렸다, 치고. 이제 진짜 커밋을 해보자.

대충

git commit -m "첫 커밋이다!"

라고 입력하면 아래와 같이 뜬다.

이게 뭔 말이냐, 이메일과 이름이 없다는 뜻이다. 커밋할 때는 작성자, 이메일, 메시지(설명), 이 세 가지 정보가 무조건 들어가야 한다.

그러므로 다음과 같이 입력하면 커밋이 되긴 된다.

git commit -m "첫 커밋이다!" --author="myname <myemail@aaa.com>"

여기서 잠깐, 이름과 이메일은 아무거나 넣어도 되나? 네. 그렇다. 깃허브에 올릴 때도? 아 물론이죠. 이름과 이메일을 남기는 것은.. 사실 그냥 주석의 연장선으로 보면 된다.

다만 GitHub를 이용할 경우, 왠만하면 GitHub에서 쓰는 아이디를 넣어주는 것이 좋다. 나중에 연동되는 기능이 있기 때문이고, 그냥 보기에도 좋기 때문이다. 여러 개의 저장소를 동시에 쓴다면? 아 몰랑..~ 이름 여러 개는 넣을 수 없으니 그땐 뭐 알아서 하는 거지.

하여튼...

매번 이름과 이메일을 넣기 귀찮으니 global 속성으로 정해줄 수 있다. 위의 캡쳐 화면처럼 따라서 입력하면 된다. 좀 길지만 한 번만 하면 되는 거니 참자.

그러고 나서 다시 git commit -m "메시지" 를 입력하면 대망의 커밋이 된다.

git status를 입력하면 아까 초록색으로 스테이지 됐던 것이 사라졌다? 어디갔어? 커밋했으니까 이제 없지. 대신 빨간색 언스테이지 파일은 그대로이다. 이제 git log를 입력해보자.

git log를 입력하면 현재까지의 모든 커밋을 쭉 볼 수 있다. 길어질 경우 나가는 키가 'q'다. 자.. 근데 한글이 깨져 있다! ㅜㅜ 해결 하는 방법이 아예 없는 것은 아니지만 괜히 인코딩만 더 꼬일 수 있으므로 그냥 두는게 좋다. 어차피 GUI 툴을 쓰면 다 해결된다.

.
.
.

다음 튜토리얼에서는 커밋을 실용적으로 활용하는 예 - 수정된 부분 확인, 분기, 병합 등을 해볼 것인데.. 과연 안 귀찮을 수 있을지..