오늘은 분산 버전 관리 시스템인 Git 에 대해서 알아보도록 하겠습니다.
Git을 통한 프로젝트 관리는 유용하고 많은 도움이 될 것이라 생각됩니다. 저는 Windows환경에서 진행했음을 알려드립니다.
먼저 간단히 진행 순서를 알려드리겠습니다.
1. 저장소 생성하기
2. 파일 추가하고 변경하기
3. 새 브랜치 만들기
4. 릴리스에 태그 붙이고 저장소 관리하기
5. 저장소 복제하기
위의 과정을 진행하도록 하겠습니다. ( Git 이 다운받아져 있다는 전제하에 진행하겠습니다. )
1. 저장소 생성하기
Git 에서 저장소를 생성하는 방법은 간단하지만 서브버전이나 CVS를 사용해왔다면 조금 이상해 보일 수 있습니다. 대부분의 버전 관리 시스템에서 저장소는 자신이 가지고 있는 복사본과 떨어져 존재하지만 Git에서는 작업 트리와 함께 .git 디렉토리에 저장됩니다.
그럼 먼저 Git bash를 열고 프로젝트 코드를 저장할 위치를 정할건데요. 프로젝트 이름은 mysite 라고 정하겠습니다. 프로젝트 이름과 같은 디렉토리를 생성하고 디렉토리 안으로 이동한 다음 git init 이라는 명령어를 입력해주면 됩니다.

이것으로 끝입니다. 이제 프로젝트를 추적할 수 있는 Git 저장소가 생겼습니다.
이게 전부일리 없다고 생각할지 모르지만 정말로 더 이상 없습니다. Git 저장소를 설정하는 작업은 정말로 간단합니다.
git init 명령어는 .git 디렉토리를 생성하고 여기에 저장소 메타데이터를 모두 저장합니다. 그리고 현재 비어있는 mysite 디렉토리는 저장소에서 체크아웃 할 코드의 작업 트리가 됩니다.
2. 파일 추가하기
이제 빈 저장소에 파일을 추가하겠습니다. index.html 파일을 생성하고 헤더와 'Hello World!'란 텍스트를 추가합니다.
index.html
|
<html>
<body>
<h1>Hello World!</h1>
</body>
</html> |
cs |
추적을 시작할 간단한 HTML 페이지다. 계속해서 이 파일에 내용을 추가합니다.
이제 추적할 파일이 생겼으니 Git에게 이 파일을 추적하겠다는 사실으르 알립니다.
Git에게 알리는 작업은 두 단계에 걸쳐서 진행됩니다. 먼저 git add 명령어로 HTML 파일을 Git의 관리 목록에 추가합니다. 그러고 나서 git commit으로 커밋합니다.

추적 하려는 파일이나 파일의 목록을 git add에 매개변수로 전달합니다. 그리고 git commit은 커밋을 생성합니다.
커밋은 저장소에 저장된 개별적인 이력으로, 각 커밋은 코드의 진행 상태를 기록합니다. Git은 앞에서 설정한 내용을 참조해서 사용자의 이름과 이메일 주소를 기록하고 각 커밋에 메시지를 추가합니다.
앞의 명령어에서 -m 다음의 문자열이 커밋에 추가되는 메시지입니다. 잘 작성한 로그 메시지는 모든 버전 관리 시스템의 핵심 요소로, 로그 메시지에 커밋하는 이유를 설명합니다. 새 파일이 무엇을 하는지? 코드에서 무엇을 변경했는지? 를 알 수 있습니다.
git log 를 실행하면 지금까지의 커밋 내용을 볼 수 있습니다.

첫 줄에서 커밋명을 보여줍니다. 커밋명은 커밋을 추적할 수 있도록 Git이 생성한 SHA-1 해시(hash) 값입니다. Git은 각 커밋의 식별자가 완벽히 고유하도록 SHA-1 해시를 이용합니다. 분산 환경에서는 완벽히 고유하다는 점이 중요합니다.
git log 출력의 둘째 줄은 커밋한 사람의 정보입니다. 셋째 줄은 커밋한 날짜고, 마지막 줄은 커밋 로그 메시지입니다.
3. 프로젝트를 이용한 작업 시작하기
이제 저장소를 준비했으며 이미 첫 번째 파일을 추적하고 있습니다. 이제부터 변경 사항을 다뤄보겠습니다.
지금까지 HTML에 <head>와 <title> 엘리먼트가 빠져 있었습니다. 엘리먼트를 추가한 index.html 파일은 다음과 같습니다.
index.html
|
<html>
<head>
<title>Hello World in Git</title>
</head>
<body>
<h1>Hello World!</h1>
</body>
</html> |
cs |
방금 파일을 변경했음을 Git도 알고 있습니다. git status 명령어는 저장소의 현재시점인 작업 트리의 상태를 보여줍니다.
서브버전이나 CVS 사용자는 작업 트리를 작업 복사본이라고 알고 있습니다.

출력 결과를 통해 변경된 파일을 Git이 알고 있지만 이를 어떻게 처리할지는 아직 모른다는 사실을 알 수 있습니다.
변경한 파일은 수정된 파일(modified)로 표시되지만, 갱신 전(Changed but not updated) 헤더에 있습니다. 이 파일을 커밋하려면 변경 사항을 스테이징(stage)해야 합니다. 변경 사항을 스테이징하면 커밋할 수 있도록 준비합니다. Git에서는 사용자의 코드를 세 곳에 저장합니다.
첫째 위치는 파일을 편집할 때 직접 이용하는 작업트리다.
둘째 위치는 인덱스이며 이후에는 스테이징 영역(staging area)이라 부릅니다. 스테이징 영역은 작업 트리와 저장소 사이의 버퍼(buffer)공간입니다.
마지막 위치는 Git이 코드를 저장하는 저장소입니다. 스테이징 영역은 저장소에 커밋하려는 대상만 올려두는 용도로 사용합니다.
이제 git add 명령어를 다시 이용하면 index.html 파일의 변경 내용을 스테이징할 수 있습니다. 이전에 새 파일을 추가하기 위해서 사용한 명령어와 동일합니다. 다만 새로운 파일임을 알리는 용도가 아니라 추적할 새로운 변경 내용이 있음을 Git에게 알립니다.

수정된 index.html 파일을 추가한 다음 git status 명령어를 실행하면 헤더 영역이 갱신 전에서 커밋 예정(Changes to be commit-ted)로 바뀐 것을 확인할 수 있습니다. 색상 출력을 켜놨다면 index.html을 가리키는 줄의 색이 빨간색에서 녹색으로 바뀐 것도 볼 수 있습니다.
그럼 git commit 명령어를 실행해보겠습니다. 이때, -m 매개변수를 이용해서 변경한 이유를 설명한 것도 잊지 말아야합니다.

두 개의 -m 매개변수를 사용했습니다. Git에서는 원하는 대로 -m 매개변수를 사용할 수 있고, 매개변수마다 하나의 문단으로 취급합니다.
git log로 메시지가 두 개의 문단으로 구성됨을 확인할 수 있습니다.

git log 명령어에 새로운 매개변수 -1을 이용했습니다. 숫자를 변경하면 보고 싶은 커밋 개수만큼 git log의 출력을 제한할 수 있습니다.
4.브랜치 사용하고 이해하기
브랜치를 이용하면 작업 중인 프로젝트의 분기 이력을 관리할 수 있습니다. 분기 이력이 훌륭하긴 하지만 실제 프로젝트에서는 어떻게 사용해야 할까요? 실제 유용한 형태의 브랜치는 두 가지가 있습니다. 바로 프로젝트의 여러 버전을 브랜치 별로 관리하기 위해 생성한 브랜치와 특정 기능을 다루는 주제 브랜치입니다. 저는 첫번째 형태의 브랜치를 다루도록 하겠습니다.
mysite코드는 릴리스 준비가 거의 끝났지만 그래도 관련된 사람들에게 승인을 받아야 합니다. 승인을 기다리는 중에도 다음 버전의 새로운 기능을 추가할 수 있습니다.
브랜치를 이용하면 릴리스 준비가 된 코드의 복사본을 보관해둘 수 있으므로 개발을 멈출 필요가 없습니다. 브랜치를 생성하는 명령어는 git branch이며 매개변수를 두 개 받습니다. 첫번째는 생성하려는 브랜치명이고 두번째는 분기해 나올브랜치명입니다.

이 명령어는 master 브랜치에서 RB_1.0이라는 브랜치를 생성합니다. Git에서 master는 기본 브랜치명입니다. CVS나 서브버전에서는 Git의 master 브랜치와 같은 역할을 트렁크(trunk)라고 부릅니다. 브랜치명에서 사용한 RB는 릴리스 브랜치(release branch)의 약어입니다. RB라는 접두어를 붙이면 릴리스 브랜치를 파악하기 쉬워집니다.
이제 릴리스 준비 중인 코드에 영향을 주지 않고도 내용을 변경할 수 있습니다. index.html 파일에 약력(Biography) 페이지로 가는 링크를 추가합니다.
</body> 태그 앞에 다음 내용을 추가합니다.
index.html
|
<html>
<head>
<title>Hello World in Git</title>
</head>
<body>
<h1>Hello World!</h1>
<ul>
<li><a href="bio.html">Biography</a></li>
</ul>
</body>
</html>
|
cs |
이제 변경사항을 커밋하겠습니다. 이전과는 조금 다른 형태의 명령어를 사용합니다.
출처 : Git, 분산버전관리시스템