파일 이름을 변경하고 파일 이동하기

 

개발자는 누구나 실수하기 때문에 파일을 변경하고 새로 작성하고 이러한 작업들은 흔히 발생 하는 일이다.

 

Git에서 git mv <원본파일> <새로운 파일>과 같이 입력하면 파일을 이동 시킬 수 있다.

 

 

□ 파일 복사하기

 

Git은 파일이 아니라 그 내용을 추적한다는 사실은 모두가 잘 알 것이다. 왜냐하면 결국 파일 이름이란 그냥 그 파일에대한 메타데이터의 일종일 뿐이기 때문이다.

 

즉, git cp명령어 따위가 없다. 그냥 복사해도 git은 내용을 추적하기 때문에 알아서 중복된 내용으로 commit을 할 수 있게 한다. 하지만 같은 파일을 복사해서 사용하는것은 주의해야한다. 이렇게 중복된 코드를 사용한다는 것은 리펙토링이 필요하다는 의미를 내포하고 있기 때문이다.

 

□ 파일 무시하기

 

.gitignore을 통해서 각 편집기가 사용하는 임시 복원 파일과 같은 것들을 변경이력에서 무시하도록 할 수 있다.

즉 다른 개발자들은 필요없는 정보들은 구지 commit할 필요가 없는 것이다.

 

지역 저장소에서만 해당 파일을 무시하도록 설정할 수도 있다.

.git/info/exclude 파일을 수정하면 위 기능을 구현 할 수 있다.

 

정리하면

모두에게 무시 되어져야 한다면 .gitignore 파일에 규칙을 추가하고 저장소에 커밋한다.

자신에게만 해당된다면 .git/info/exclude파일에 추가한다.

 

Git을 이용해서 차이점을 살펴 보기

 

Git을 이용해서 변경사항을 추적하는 일은 다음과 같다.

1) Git은 작업트리의 변경사항

2) 스테이징 되어서 커밋하려는 변경 사항

3) 저장소간의 차이점을 보여주는 사항

 

매개변수 없이 git diff를 실행하면 아직 스테이징되지 않고 커밋되지도 않은

작업트리(작업 디렉터리)의 변경사항을 보여준다.

 

>git diff

root@ubuntu:/work_remotGitHub/mysite-remote# git diff
diff --git a/index.html b/index.html
index ca86894..06bfc3d 100644
--- a/index.html
+++ b/index.html
@@ -7,6 +7,7 @@
     <h1>Hello World!</h1>
     <ul>
         <li><a href="about.html">About</a></li>
-    </ul>
+                 <li><a href="contact.html">Contact</a></li>
+       </ul>
 </body>
 </html>

 

git diff를 매개변수 없이 실행하면 작업 트리의 변경 사항과 스테이징 영역을 비교 한다.

 

스테이징 영역과 저장소의 차이점을 알기 위해서는 아래를 실행 한다.

root@ubuntu:/work_remotGitHub/mysite-remote# git diff --cached
diff --git a/index.html b/index.html
index e812d0a..ca86894 100644
--- a/index.html
+++ b/index.html
@@ -6,7 +6,7 @@
 <body>
     <h1>Hello World!</h1>
     <ul>
-        <li><a href="bio.html">Biography</a></li>
+        <li><a href="about.html">About</a></li>
     </ul>
 </body>
 </html>

 

스테이징 한것은 <li><a href="about.html">About</a></li> 이기 때문에 이부분에 대해서만 결과가 나오는 것을 알 수 있다.

 

작업트리(작업디렉터리), 스테이징 영역, 저장소(repository) 3곳 모두에서의 모든 차이점을 보고 싶다면 HEAD 매개변수를 추가한다.

root@ubuntu:/work_remotGitHub/mysite-remote# git diff HEAD
diff --git a/index.html b/index.html
index e812d0a..06bfc3d 100644
--- a/index.html
+++ b/index.html
@@ -6,7 +6,8 @@
 <body>
     <h1>Hello World!</h1>
     <ul>
-        <li><a href="bio.html">Biography</a></li>
-    </ul>
+        <li><a href="about.html">About</a></li>
+                 <li><a href="contact.html">Contact</a></li>
+       </ul>

 </body>
 </html>

 

HEAD는 현재 작업중인 브랜치에서 가장 최신의 커밋을 나타내는 키워드다.

 

commit -a 해서 변견이력을 등록 한다. 메시지는 각자 알아서 상세히 기록 하자.

 

 

개요

매번 소스코드를 압축하고 뒤에다가 날자를 붙이는 번거로운 작업을 하면서 프로젝트를 진행 할 수는 없다.

현재 많이 쓰이고 있는 CVS나 SVN과 다른 분산 버전 관리 시스템인 Git(깃)을 소개한다.

Git vs CVS, SVN

cvs와 svn의 경우 저장소(repository)가 원격 서버에 있는 방식이다. 즉, 중앙에 집중적인 버전 관리 시스템을 가지고 있는 것이다.

이러한 중앙 집중식 저장소는 컴퓨터에 직접 접근해야 하는 문제는 개선 했지만 여전히 한계가 있다. 먼저, 사용자는 최신 버전의 코드만 가지고 있다. 변경 이력을 보려면 저장소에 정보를 요청해야 하는 것이다. 즉, 반드시 네트워크상에서 원격 저장소로 접근해야 한다는 점이 문제인 것이다.

하지만 Git(깃)이 따르는 모델인 분산 버전 관리 시스템에서는 모든 팀원이 변경 사항을 전송하는 중앙 저장소를 가지는 대신, 각자가 프로젝트의 전체 이력이 있는 자신만의 저장소를 가진다. 커밋할 때는 원격 저장소에 연결할 필요가 없이 변경 사항을 지역 저장소에 기록한다.

은행으로 비유하자면, 중앙 집중식 시스템이 팀 구성원 모두가 사용하는 하나의 은행을 가지는 것이라면, 분산 시스템은 각 개발자가 자신만의 개인 은행을 가지는 것과 같다.

이쯤 되면 다른 사람들이 작업한 변경 사항을 어떻게 동기화 해야 할지, 그리고 내가 수정한 변경 사항을 다른 사람들이 제대로 가지고 있을지 궁금할 법하다. 각 개발자는 여전히 중앙 프로젝트 저장소에 변경 사항을 전송 한다. 개발자가 직접 변경 사항을 중앙 저장소에 전송 하려고 접속할 수 있다. 이런 행동을 Git에서는 푸싱(Pushing)이라고 한다. 또는, 변경 사항을 모아둔 패치를 만들어 프로젝트를 관리하는 사람에게 제출해서 중앙 저장소에 반영하게 할 수 있다.

Git의 작업 트리

사용자가 모든 변경 작업을 수행하는 위치는 작업트리이다.

작업 트리란 결국 저장소를 바라보는 자신의 현재 시점이다. 작업 트리는 소스코드, 빌드 파일, 단위 테스트 등 프로젝트의 모든 파일을 가지고 있는 것이다.

몇몇 버전 관리 시스템에서는 작업트리를 작업 복사본(working copy)이라고 한다. 다른 버전 관리 시스템을 사용하다가 Git을 처음 사용하는 사람들은 저장소와 작업 트리를 구분하는 데 혼란을 겪는다. Subversion(SVN)과 같은 버전 관리 시스템에서 저장소는 '저 너머'의 다른 서버에 존재한다.

하지만 Git 에서 '저 너머'란 로컬 컴퓨터의 프로젝트 디렉터리에 있는 .git/ 디렉터리를 의미한다. 즉 저장소의 이력을 보고 변경 사항을 살펴보려고 다른 서버에 있는 저장소와 통신하지 않아도 된다.

그럼 이 작업 트리를 처음 가져오려면 어떻게 해야 할까? Git에게 자신의 프로젝트를 저장소에 초기화 하도록 요청하거나, 기존 저장소의 프로젝트를 복제(clone)할 수 있다.

복제하기는 지역 저장소(현재 본인의 로컬 컴퓨터)를 만든 후 개발의 기본 흐름인 마스터 브랜치에서 복사본을 체크아웃(check out)한다. Check out은 git이 사용자의 작업 트리를 저장소의 특정 시점과 일치하도록 변경하는 작업이다.

결국 버전관리 시스템은 결국 이 변경사항을 어떻게 추적하는지가 전부이다. 이제 본격적으로 변경사항을 어떻게 추적하는지에 대해서 설명 하도록 하겠다.

파일 다루고 동기화 하기

버전 관리 시스템을 사용하는 주된 이유는 변경을 계속해서 추적하기 위함이다. 개발자는 소스 코드를 변경하고, 잘못된 영향(side effect)을 끼치지는 않았는지 단위 테스트를 수행한 다음 commit한다.

pulling : 다른 개발자가 변경사항을 푸싱 한것을 가져오는 작업을 말한다. CVS, SVN에서의 update와 유사한 기능을 한다.

□ 프로젝트, 디렉터리, 파일 추적하기

여기서는 저장 대상을 구조화하는 방법에 대해서 이야기 해보자.

Git는 제일 원초적인 방법으로 저장한 파일의 내용을 분석해서 그 변경이력을 추적하게 된다.

여타 다른 버전관리 시스템에서는 파일 자체를 추적하는데, git은 내용을 추적하기 때문에 다르다고 할 수 있다.

즉 models.py 파일을 추적하는 대신 models.py에 있는 변수나 함수 등을 구성하는 각 문자와 줄을 추적하며 이름, 파일 모드(file mode), 심볼릭 파일 여부와 같은 메타 데이터(metadata)를 models.py에 추가 한다. 이것은 미묘한 차이점이지만 중요하다.

이러한 점은 기술적으로도 큰 이점이다. 저장소의 전체 이력을 저장하는데 필요한 공간이 줄어든다. 그리고 두 파일 사이에서 함수나 클래스의 이동을 알아내거나 어디에서 복사된 코드인지 결정하는 것과 같은 작업이 가능해졌으며 빠르다.

결국 , 프로젝트란 저장소에 파일과 디렉터리를 조직화한 형태에 불과하다.

□ 태그를 이용해 마일스톤 추적하기

프로젝트를 진행함에 따라 마일스톤(milestone)에 도달하게 된다. 애자일 방법론을 따른다면 매주마다 새로운 기능을 추가하는 주간 개발 주기를 따를 태고, 수 개월에 한 번씩 업데이트를 릴리스하는 기존의 방법론 중 하나를 따를 수도 있다.

둘 중 어느 경우라도 특정 마일스톤을 달성했을 때의 저장소 상태를 추적할 수 있어야 한다. 태그(tag)를 이용해 이러한 상태를 추적한다. 태그에 저장소 이력의 특정 위치를 기록해두면 나중에 편리하게 참조할 수 있다.

태그는 저장소 이력의 특정 시점을 기록하는 용도로 사용하는 이름일 뿐이며, 공개 릴리스 같은 주요 마일스톤이나 버그 수정 같이 사소한 것들도 표현할 수 있다.

쉽게 기억할 수 있는 이름을 특정 리비전의 태그에 부여함으로써 저장소의 이력을 계속해서 추적할 수 있다.

□ 브랜치로 분기 이력 만들기

만약 달력 프로그램을 다시 작성하려면 팀원의 동의를 구해야 하며 변경 사항을 추적해야 한다. 코드 전체를 다른 디렉터리에 복사해두고 바꾸기 시작해도 되지만, 이렇게 변경하면 내역을 추적할 방법도 없고, 더 중요하게는 이것 저것 실험하면서 했던 실수를 되돌릴 수도 없다는 문제가 생긴다.

이런 때 브랜치가 필요하다. 브랜치를 생성하려면 파일이 분기하는 위치가 저장소에 기록된다. 브랜치는 다른 브랜치와 분리하여 내용에 대한 변경 사항을 지속적으로 추적한다. 그래서 분기 이력을 생성할 수 있다.

마스터 브랜치(master branch)는 개발의 기본 줄기이다. // 다른 버전 관리 시스템(svn)에서는 트렁크(trunk)라고 부리기도 한다.

브랜치를 생성하면 기본 줄기에서 분기된다.

브랜치는 계속 남겨둘수도 있고, 바로 지워 버릴 수도 있다.

또한 Git에서는 브랜치도 다른 모든 것과 마찬가지로 다른 사람과 공유하지 않고 지역적으로 생성할 수 있다. 지역 브랜치를 생성하고 공유하지 않는 데에도 나름의 이점이 있다. 개인적으로 몇 가지를 실험해보고, 만족스러운 수준이 된후에 공유할 수 있다. 실험한 내용이 제대로 동작하지 않으면 그냥 조용히 지워버리면 된다.

Git을 이용하면서 브랜치와 태그는 중요한 부분이기에 추후에 따로 자세히 설명 하도록 하겠다.

대부분의 브랜치는 초신의 내용을 유지할 수 있도록 다른 브랜치에 합쳐야 한다.

□ 합치기(Merge)

합치기를 이용해 여러 브랜치의 이력을 하나로 합친다. Git은 사용자가 직접하는 방식과 동일하게 이력을 합친다. Git은 두 브랜치의 변경 사항을 놓고 어디서 변경이 발생했는지 비교한다.

파일이 서로 다른 영역이 변경되었다면 Git이 알아서 합친다. 때로는 Git이 합칠 수 없는 상황이 발생 한다. 이때는 오류가 있음을 기록하고 사용자에게 충돌이 있음을 알린다.

즉, 같은 팀의 개발자가 코드에서 같은 위치를 서로 다르게 수정했다고 하자. Git은 이러한 상황을 보고 둘 중에 어느 것이 올바른지 결정할 수 없기 때문에 충돌로 표시하고, 사용자가 어떤 변경이 올바른지 알려주기를 기다린다.

Git의 막강한 기능은 바로 merge의 변경 이력 추적에 있다. merge 추적을 통해 이러한 작업을 처리하기 위해서는 손수 해야하는 불편함이 과거 버전관리 시스템에는 있었다. 하지만 Git의 경우 함께 합쳐진 커밋 내역을 주적하고, 이미 합쳐진 내용을 다시 합치지 않게 한다.

이게 가능하기 때문에 더 이상 브랜치 사용을 꺼려하지 않아도 되는 것이다.

(단, subversion 1.5.0부터는 merge trace 기능을 support한다.)

□ 잠금 옵션

도서관의 책을 빌리는것과 같은 것이다. 한번에 한사람만 책을 빌릴 수 있는 것이다. 이를 버전 관리에 적용할 경우

즉 한번에 한 사람만이 소스 코드를 수정 할 수 있다는 말이다.

strict locking : 특정 코드의 복사본은 한 번에 한 사람만 가질 수 있다. 이는 함께 일하는 팀원 간에는 그다지 효율적인 방식이 아닐 뿐더러 사로 느슨하게 연결된 분산 버전 관리 시스템 모델과도 어울리지 않는다.

optimistic locking : 대부분의 경우 서로 변경한 영역에 충돌이 없으리라고 가정하므로 다수의 개발자가 같은 파일에 있는 동일한 코드를 이용하는 것을 허용한다.

시나리오)

개발자 A와 B가 동시에 같은 파일을 복사본을 만들어서 수정한다. 이때 optimistic locking이기 때문에 동시에 2명이 체크아웃하는것을 허용한다.

그리고 개발자 A가 자신의 변경사항을 푸슁한다. 그리고 개발자 B가 푸슁하려고한다. 그러면 Git은 거부한다.

그러면 개발자 B는 A가 푸슁한 이력을 폴링해서 자신의 저장소에 반영해야한다. 그다음 다시 푸슁하면 성공한다.

복잡하지만 생각해보면 간단한 이력 업데이트 방식이다. 또한 한팀에서 두명이 동시에 같은 파일을 편집하는 경우도 흔치 않을 것이다.

지금 까지 거시적 관점에서 Git 즉, 분산 버전 관리 시스템의 구성을 보았다. 이제 다음 포스트에서 좀 더 상세한 Git의 사용법에 대해서 다루도록 하겠다.

□ 개요

Git를 실제 어떻게 사용하는지에 대한 실질적인 방법을 다루도록 하겠다.

 

□ 저장소 생성하기

> mkdir mysite
> cd mysite
> git init
Initialized empty Git repository in /root/gitTutorial/mysite/.git/

 

이것으로 끝이다. 이제 프로젝트를 추적할 수 있는 Git 저장소가 생겼다.

이게 전부일 리 없다고 생각할지 모르지만 정말로 더 이상은 없다. Git 저장소를 설정하는 작업은 정말로 간단하다. git init 명령어는 .git 디렉터리를 생성하고 여기에 저장소 메타데이터를 모두 저장한다. 그리고 현재 비어있는 mysite 디렉터리는 저장소에서 체크아웃 할 코드의 작업 트리가 된다.

 

□ 변경하기

이제 빈 저장소에 파일을 추가하자. index.html 파일을 생성하고 해더와 "Hello World"란 텍스트를 추가한다. 내용은 다음과 같다.

<html>
<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자리만 사용한다. 이것으로도 충분하다.


 

□ 프로젝트를 이용한 작업 시작하기

이제 저장소를 준비 했으며 이미 첫 번째 파일을 추적하고 있다. 이제부터 변경 사항을 다뤄보자.

<html>
<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>

 

그다음 아래 명령어를 실행해보면

 

root@ubuntu:~/gitTutorial/mysite# git status
# 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 파일에 다음을 추가해 보자.

<ul>

<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 브랜치의 변경 이력과 동일한 것을 알 수 있다.

 

 

+ Recent posts