□ 개요
Git를 실제 어떻게 사용하는지에 대한 실질적인 방법을 다루도록 하겠다.
□ 저장소 생성하기
> cd mysite
> git init
Initialized empty Git repository in /root/gitTutorial/mysite/.git/
이것으로 끝이다. 이제 프로젝트를 추적할 수 있는 Git 저장소가 생겼다.
이게 전부일 리 없다고 생각할지 모르지만 정말로 더 이상은 없다. Git 저장소를 설정하는 작업은 정말로 간단하다. git init 명령어는 .git 디렉터리를 생성하고 여기에 저장소 메타데이터를 모두 저장한다. 그리고 현재 비어있는 mysite 디렉터리는 저장소에서 체크아웃 할 코드의 작업 트리가 된다.
□ 변경하기
이제 빈 저장소에 파일을 추가하자. index.html 파일을 생성하고 해더와 "Hello World"란 텍스트를 추가한다. 내용은 다음과 같다.
<body>
<h1>Hello World!</h1>
</body>
</html>
---------------------------------------------------------------------
root@ubuntu:~/gitTutorial/mysite# git commit -m "add in heelo world HTML"
[master (root-commit) d5fde6e] add in heelo world HTML
1 files changed, 6 insertions(+), 0 deletions(-)
create mode 100644 index.html
root@ubuntu:~/gitTutorial/mysite# git log
commit d5fde6e2e1174824be35707fe862aea3a3c1109d
Author: Jemin Lee <leejaymin@nate.com>
Date: Sun Jun 3 00:58:42 2012 -0700
add in heelo world HTML
첫 줄에서 커밋명을 보여준다. 커밋명은 커밋을 추적할 수 있도록 Git이 생성한 SHA-1 해시(hash) 값이다. Git은 각 커밋의 식별자가 완벽히 고유하도록 SHA-1 해시를 이용한다. 분산 환경에서는 완벽히 고유하다는 점이 중요하다. 해시에 대한 자세한 설명은 추후에 다시 설명 하도록 하겠다.
commit은 해시의 7자리만 사용해도 된다.
두번째는 commit한 사람이고
세번째는 날자이다.
네번째는 commit 메시지이다.
□ Git SHA-1 해시를 사용하는 이유
SVN에서는 그냥 리비전 상수만 쓰면 됬었다.
하지만 Git는 분산 버전 관리 시스템이기 때문에 상수값만으로는 충돌을 회피할 수 없다.
따라서 해시를 이용한다. 해시 또한 충돌할 가능성이 있지만 그 확률은 거의 0에 가깝다.
수학적으로 2^63분의 1의 확률을 가진다.
또한 이 해시의 숫자를 모두 사용하지않고 7~8자리만 사용한다. 이것으로도 충분하다.
□ 프로젝트를 이용한 작업 시작하기
이제 저장소를 준비 했으며 이미 첫 번째 파일을 추적하고 있다. 이제부터 변경 사항을 다뤄보자.
<body>
<h1>Hello World!</h1>
</body>
</html>
------------------
1 <html>
2 <head>
3 <title>Hello World in Git</title>
4 </head>
5
6 <body>
7 <h1>Hello World!</h1>
8 </body>
9
10 </html>
그다음 아래 명령어를 실행해보면
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: index.html
#
no changes added to commit (use "git add" and/or "git commit -a")
출력 결과를 통해 변경된 파일을 Git이 알고 있지만 이것을 어떻게 처리할지는 아직 모른다는 사실을 알 수 있다. 변경한 파일은 수정된 파일(modified)로 표시 되지만, 갱신 전(Changed but not updated) 헤더에 있다. 이 파일을 커밋 하려면 변경 사항을 스테이징(stage)해야 한다.
변경 사항을 stage하면 커밋할 수 있도록 준비한다. Git에서는 사용자의 코드를 세 공에 저장한다.
첫째 위치는 파일을 편집할 때 직접 이용하는 작업 트리다.
작업트리 = 서브버전(SVN)이나 CVS에서는 작업 복사본이라고 부른다.
둘째 위치는 인덱스이며 이후에는 스테이징 영역(staging area)이라 부른다.
스테이징 영역은 작업 트리와 저장소 사이의 버퍼공간이다.
세번째 위치는 Git이 코드를 저장하는 저장소이다. 스테이징 영역은 저장소에 커밋하려는 대상만 올려두는 용도로 사용한다.
이제 git add명령어를 다시 이용하면 index.html 파일의 변경 내용을 스테이징할 수 있다. 아까 새 파일을 추가하기 위해서 사용한 명령어와 동일하다. 이번에는 새로운 파일임을 알리는 용도가 아니라 추적할 새로운 변경 내용이 있음을 Git에게 알린다.
oot@ubuntu:~/gitTutorial/mysite# git add index.html
root@ubuntu:~/gitTutorial/mysite# git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: index.html
#
root@ubuntu:~/gitTutorial/mysite# git commit -m "add <head> and <title> to index" \-m "This allows for a more semantic document" \-m "한글 테스트"
[master a67525a] add <head> and <title> to index
1 files changed, 5 insertions(+), 0 deletions(-)
root@ubuntu:~/gitTutorial/mysite# git log
commit a67525a717571244586d19e4a15b9dea25a04aec
Author: Jemin Lee <leejaymin@nate.com>
Date: Sun Jun 3 01:53:19 2012 -0700
add <head> and <title> to index
This allows for a more semantic document
한글 테스트
commit d5fde6e2e1174824be35707fe862aea3a3c1109d
Author: Jemin Lee <leejaymin@nate.com>
Date: Sun Jun 3 00:58:42 2012 -0700
add in heelo world HTML
root@ubuntu:~/gitTutorial/mysite# git log -1
commit a67525a717571244586d19e4a15b9dea25a04aec
Author: Jemin Lee <leejaymin@nate.com>
Date: Sun Jun 3 01:53:19 2012 -0700
add <head> and <title> to index
This allows for a more semantic doucment
한글 테스트
맨 처음 git add index.html을 하면 스테이징에 추가할 파일이 넣어진 것이다.
즉, 버퍼에 들어간 것이다.
그다음 git status를 해보면Changes not staged for commit -> Changes to be committed 으로 변경된 것을 알 수 있다.
modified: index.html 도 초록색으로 변경된 것을 알 수 있다. (변경 사항을 스테이징도 하지 않을경우 빨간색으로 보이게 된다.)
이제
git commit -m "add <head> and <title> to index" \-m "This allows for a more semantic document" \-m "한글 테스트"
위 명령어를 실행하면 commit을 저장소로 한것이다.
그다음 git log로 커밋 로그를 찍어보면 변경 이력을 쉽게 알 수있다.
git log -1을 하면 변경이력중 최상위 1개만 볼 수 있다.
TIp : 커밋 로그에 어떤 내용을 넣어야 할까?
커밋 로그에 어떤 내용을 작성 할지 정하는 일이 처음에는 조금 난해할 수 있다. 커밋 메시지는 메시지만으로도 의도를 드러내도록 커밋의 '이유'를 설명하는 모든 메타데이터를 포함해야 한다.
□ 브랜치 사용하고 이해하기
브랜치는 그냥 마음대로 사용하면 되는 것이지만, 실제로 유용한 형태의 브랜치는 두가지가 있다.
1) 프로젝트의 여러 버전을 브랜치 별로 관리하기 위해 생성한 브랜치와 특정 기능을 다루는 주제 브랜치다.
이 첫번째에 해당하는 실습을 진행해 보도록 하겠다.
git branch RB_1.0 master
첫 번째는 생성하려는 브랜치명이고 두 번째는 분기해 나올 브랜치명이다.
위 명령어의 의미는 master 브랜치에서 RB_1.0이라는 브랜치를 생성한다. Git에서 master는 기본 브랜치명이다. CVS나 SVN(서브버전)에서는 GIt의 master 브랜치와 같은 역항을 트렁크(trunk)라고 부른다.
이제 브랜치를 생성 했기 때문에 릴리즈 버전에 영향을 주지않고도 추가적으로 프로젝트를 진행 할 수 있는 것이다.
index.html 파일에 다음을 추가해 보자.
<li><a href="bio.html">Biography</a><li>
</ul>
> git commit -a
-a 매개변수의 의미는 Git에서 알고 있는 모든 변경된 파일을 커밋하라는 의미이다.
현재는 master 브랜치를 변경한 것이다. 브랜치를 변경해서 릴리즈 브랜치로 이동을 해보자.
>git checkout RB_1.0
index.html의 내용이 변경되는 것을 볼 수 있다.
이곳에 아래의 내용을 추가하자.
<meta name="description" content="hello world in Git"/>
그다음
>git commit -a
이제 릴리즈 준비가 끝났다.
□ 브랜치 사용하고 이해하기
지금 까지 작업한 코드의 1.0 릴리스 준비를 끝냈다. 여기에 태그를 붙여보자.
Git에서 코드에 태그를 붙이면 저장소 이력의 특정 지점을 기록하기 때문에 나중에 참조하기가 쉽다. 1.0 릴리스에 대한 태그니 숫자로 태그를 붙이자.
> git tag 1.0 RB_1.0
> git tag
1.0
태그를 해놨기 때문에 이제 브랜치를 제거해서 지저분한 부분을 정리하면 된다.
그전에 변경이력을 통합해준다.
즉, 브랜치를 merge하는 것이다. 아래의 명렁어를 입력한다.
>git checkout master // 마스터 브랜치로 이동
>git rebase RB_1.0 // 브랜치 merge
>git branch -d RB_1.0 //브랜치 삭제, tag를 해놧기 때문에 언제든지 복구할 수 있다.
그럼이제 tag를 통해서 어떻게 브랜치를 생성하는지 알아보겠다.
git branch RB_1.0.1 1.0 // tag 1.0을 기반해서 브랜치 생성
git checkout RB_1.0.1 // RB_1.0.1 새로 생성한 브랜치로 이동
git log --pretty=oneline // 변경 이력을 출력한다. 이전에 tag를 달았던 RB_1.0 브랜치의 변경 이력과 동일한 것을 알 수 있다.
'Computer Science > Git' 카테고리의 다른 글
| Git의 모든것(6) Git 이력 이용하기 (0) | 2012.06.14 |
|---|---|
| Git의 모든것(5) - 브랜치 사용 - (0) | 2012.06.04 |
| Git의 모든것(4) - 파일관리 하기- (0) | 2012.06.03 |
| Git의 모든것(3) - 차이점 살펴보기 - (0) | 2012.06.03 |
| Git의 모든것(1) -기초 개념- (0) | 2012.06.03 |