포럼 회원으로 등록하신분만 다운로드가 가능합니다. 최대 업로드 가능한 용량은 20MB 입니다.

안녕하세요?

 

현재 국내에 GIT에 대한 제대로 된 문서가 없기에,  GIT 사용자 가이드에 대하여 번역을 시작하게 되었습니다.

번역의 오류로 틀린 내용이 있을 수도 있으니, 오류 발견시 댓글을 남겨주시면 감사하겠습니다.

 

GIT 사용법 (ProGIT) - 2.2. GIT 저장소(Repository)에 기록

 

원본 : ProGIT  Book(http://progit.org)

번역 : 김재훈(이솝 임베디드 포럼, http://www.aesop.or.kr)

 

2.2.1. 저장소(Repository)로의 변경 내용 기록

 

앞 장에서 위는 GIT 저장소(Repository)를 준비하고, git clone 명령을 이용하여 프로젝트 파일의 복사본을 취득할 수 있었습니다. 사용자는 프로젝트의 복사본을 취득하고 이 프로젝트에 사용자가 어떤 변경 작업을 수행하게 됩니다. 그리고 적당한 시점에서 변경된 내용의 Snapshot을 저장소(Repository)에 위탁하게 됩니다.

 

우선 작업하는 프로젝스 복사본 내부의 각 파일의 속성으로 "추적되고 있다(Tracked)"와 "추적되고 있지 않다(Untracked)"와 같은 두 가지 속성이 있다는 것을 우선 알아두도록 합니다.

 

추적되고 있는 파일이란, 프로젝트의 Snapshot에 존재하고 있는 파일 입니다. 즉, GIT 저장소에 저장되어 버전 관리를 수행하고 있는 파일을 말합니다. 이런 파일들은 다시 "변경되어 있지 않다(unmodified)", "변경되었다(modified)", "스테이지 되고 있다(staged)"의 세 가지 상태가 있습니다.

 

추적되어 있지 않은 파일은 Snapshot에 존재하고 있지 않는 파일 입니다. 즉, GIT의 저장소에서 버전관리를 수행하지도 않으며, staging 영역에도 존재하지 않는 파일 입니다.

 

최초로 프로젝트를 클론(Clone)한 시점에서 모든 파일은 "추적되고 있다"와 "변경되어 있지 않다"의 상태가 됩니다.

사용자는 프로젝트를 체크아웃만 했지 아무것도 편집하고 있지는 않았기 때문 입니다.

 

만약 GIT가 추적하고 있는 파일을 사용자가 편집한다면, GIT는 그것을 "변경되었다(modified)"라고 간주 합니다. 현재 GIT가 추적하고 있는 파일이 변경되었기 때문입니다. 사용자는 변경된 파일을 staging 하고, 이것을 GIT 저장소에 위탁하는 절차를 거치게 됩니다. GIT에서 버전관리 작업은 이 절차의 반복이라고 생각하시면 됩니다.

 

여기까지의 흐름을 그림 2-1로 간단하게 정리해 보겠습니다.

 

2-1.PNG

그림 2-1. 파일 상태의 흐름

 

2.2.2. 파일 상태의 확인

 

어느 파일이 어떤 관리 상태에 있는지 알기 위해서 주로 사용하는 명령이 git status 입니다.

이 명령을 git clone 직후에 수행하면 아마 다음과 같은 결과가 나올 것 입니다.

 

$ git status
# On branch master
nothing to commit (working directory clean)

 

위의 결과에서 의미하는 것은, 현재 이 프로젝트는 변경되지 않은 깨끗한 복사본 이라는 의미 입니다. 즉 GIT가 추적하고 있는 파일들 중에 변경된 것들이 없다라는 것을 의미 합니다. 또한 GIT로 추적되고 있지 않는 파일도 존재하고 있지 않습니다.  GIT는 현재 프로젝트가 위치한 디렉터리에서 추적되고 있지 않는 파일이 있다면, 그 파일을 표시 합니다.

 

마지막으로, 이 명령을 실행하면 여러분이 지금 어느 브랜치에 있는지를 알 수 있습니다.

현 시점에서는 향상 master 브랜치에 위치하게 됩니다. 이것은 디폴트 값이기 때문에 현재 챕터에서는 그렇게 신경쓸 필요가 없습니다. GIT의 브랜치에 대해서는 다음 장에서 자세하게 설명할 예정 입니다.

 

그럼 여기서, 새로운 파일을 프로젝트에 추가해 보도록 해봅니다.

간단하게 README 파일을 프로젝트에 추가해 보겠습니다. 그 이전에 프로젝트에 README 파일이 없었던 경우, git status 명령을 실행하면 다음과 같이 표시 됩니다.

 

$ vim README
$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# README
nothing added to commit but untracked files present (use "git add" to track)

 

위의 출력 결과에서 "Untracked files"란에 README 파일이 보이며, 이 파일이 현재 추적되고 있지 않다는 것을 알 수 있습니다. 이것은 GIT가 "이전의 snapshot(위탁)에는 이 파일이 존재하지 않았다"라는 것을 의미 합니다.

사용자가 명시적으로 지시하지 않는 한 GIT는 위탁시에 이 파일을 포함하지 않습니다.

따라서 프로젝트를 컴파일 할 때 자동으로 생성되는 바이너리 및 오브젝트 파일 등과 같이 위탁하고 싶지 않는 파일들이 잘못 위탁될 걱정은 하지 않으셔도 됩니다.

 

우리는 README 파일을 위탁에 포함하고 싶은 것이기 때문에, 다음은 이 파일을 추적 대상에 포함하는 것을 해보도록 합니다.

 

2.2.3. 새로운 파일의 추적

 

GIT에 새로운 파일을 추적하고자 한다면, git add 명령어를 사용합니다. README 파일의 추적을 하고자 할 경우에는 다음과 같은 명령어를 수행하면 됩니다.

 

$ git add README

 

이제 다시 git status 명령을 수행한다면 다음과 같이 README 파일은 추적 대상이 되어, Staged 되고 있는 것을 알 수 있습니다.

 

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# new file:   README


 

파일이 현재 staged 되고 있다고 판단할 수 있는 것은 "Changed to be commited"란에 표시되고 있기 때문 입니다.

여기서 GIT의 저장소(Repository)에 위탁을 실시하면, git add 한 시점 상태의 파일이 snapshot로서 GIT 저장소에 기록이 됩니다.

우리는 방금전 git init 한 후 디렉터리 내의 파일을 추적에 추가하기 위해서 git add 명령을 사용하였습니다.

git add 명령 뒤에는 추적할 파일 또는 디렉터리의 경로를 지정할 수 있습니다. 만약 디렉터리를 지정했을 경우에는 그 디렉터리에 밑에 있는 모든 파일들을 재귀적으로 추가하게 됩니다.

 

2.2.4. 변경한 파일의 staging

 

이제 추적 대상이 되고 있는 파일을 편집해 보도록 합니다.

예를 들어 이미 추적 대상으로 포함된 파일인 benchmarks.rb를 변경해 status 명령을 실행하면 결과는 다음과 같이 출력 됩니다.

 

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# new file:   README
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
# modified:   benchmarks.rb
#


 위와 같이 benchmarks.rb 파일을 변경하면 "Changed but not updated"라고 git status에 출력 됩니다.

이것은 추적 대상의 파일이 작업 디렉터리내에서 변경되었지만 아직 staged 되어 있지 않다고 하는 의미 입니다.

변경된 파일을 staged 하려면 git add 명령을 실행 합니다. (git add 명령은 새로운 파일을 추적에 포함, 파일의 stating 및 merge 시에 충돌이 발생한 파일에 대한 해결 시에도 사용 됩니다.)

 

이제 git add benchmarks.rb 명령을 수행하여 GIT에 staged를 하고, git status 명령을 수행해 봅니다.

 

$ git add benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# new file:   README
# modified:   benchmarks.rb
#


 이것으로 README 파일과 benchmarks.rb 파일 모두 staged 되었습니다. 이제 다음에 GIT 저장소에 위탁할 때는 이 파일들이 포함되게 됩니다. 그런데, 파일의 변경을 끝내고 GIT 저장소에 위탁할 준비가 끝난 상태에서 개발자가 benchmarks.rb 파일에 약간의 변경을 더 하고나서 GIT 저장소에 위탁하고 싶어졌다고 가정해 봅니다.

 

하지만, benchmarks.rb 파일을 수정하고 git status 명령을 수행해 보면 다음과 같이 약간 다른 메시지가 나오게 됩니다.

 

$ vim benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# new file:   README
# modified:   benchmarks.rb
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
# modified:   benchmarks.rb
#


 위의 메시지를 본다면, benchmarks.rb 파일은 staged 되고 있는 쪽과 staged 되고 있지 않는 쪽 모두 다 메시지가 표시되고 있습니다. 위의 상황은 git add 명령을 실행하여 staged  시점 상태의 파일과 benchmarks.rb 파일이 추가로 변경된 시점의 상황이 틀리기 때문에 발생 합니다. 즉, git add를 한 후에 파일을 변경 했을 경우, 최신판의 파일을 다시 staged 하려면 다시 한 번 git add 명령을 실행 하시면 됩니다.

 

$ git add benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# new file:   README
# modified:   benchmarks.rb
#

 

2.2.5. 파일의 무시

 

어떤 종류의 파일에 대해서 GIT가 자동적으로 추적하지 않기를 바라는 상황도 있습니다. 예를 들어, 로그 파일이나 빌드시에 생성되는 각종 오브젝트 파일들이 여기에 해당 될 것 입니다. 이와 같은 경우는 .gitignore 라는 이름의 파일을 작성하고 그 안에 무시하고 싶은 파일의 패턴을 적으시면 됩니다.

 

예를들어 .gitignore 파일은 다음과 같이 작성 합니다.

 

$ cat .gitignore
*.[oa]
*~


위의 예제에서 첫 번째 행이 의미하는 것은 .o 또는 .a로 끝나는 이름의 파일을 무시하라는 뜻 입니다. 두 번째 행에서는 "~로 끝나는 이름의 파일을 무시한다는 뜻입니다. 보통 Emacs와 Vi 등과 같은 많은 종류의 에디터가 이와 같은 형식으로 임시 파일을 생성하기 때문 입니다. .gitignore 파일에 자주 포함되는 패턴들 중에는 log,tmp,pid와 같은 이름의 파일이나 디렉터리가 있습니다. 

따라서, 개발자는 GIT를 사용하기 이전에 .gitignore 파일을 미리 준비해 놓는게 좋습니다. 그러면, 엉뚱한 파일을 GIT 저장소(Repository)에 위탁해 버리는 사고를 미연에 방지할 수 있습니다.

 

.gitignore 파일에 기술하는 무시 패턴의 규칙은 다음과 같습니다.

 

- 공백의 행 또는 #으로 시작되는 행은 규칙에서 무시한다.

- 표준의 glob 패턴을 사용 가능

- 디렉터리를 지정하려면 패턴의 마지막에 slash(/)를 붙인다.

- 패턴의 값을 역전 시키려먼 패턴의 맨 앞에 느낌표(!)를 붙인다.

 

glob 패턴이란, 쉘로 이용하는 간이 정규 표현과 같은 것 입니다.

asterisk (*)는 0개 이상의 문자와 매치 됩니다. [abc]의 경우에는 [ ] 묶음 내의 문자와 매치 합니다. (이 경우는 a,b 혹은 c)  물음표(?)는 한 글자에 매치 합니다. 또 하이픈 단락의 문자를 [ ]로 둘러싼 형식 ([0-9])는 두 문자 사이의 임의의 문자에 매치 합니다. (이 경우는 0부터 9까지 사이의 문자)

 

그럼, .gitignore 파일의 예를 또 하나 보도록 합니다.

 

# 코멘트, 여기에 있는 내용은 무시 됩니다.

*.a                              # .a 파일은 무시

!lib.a                           # 그러나 lib.a 파일은 위의 .a 파일 무시 조건에서 만나도 예외로 추적 대상에 포함 합니다.

/TODO                      # 루트 디렉터리의 TODO 파일은 무시하고, 서브 디렉터리의 TODO 파일은 무시하지 않습니다.

build/                          # build/ 디렉터리의 모든 파일을 무시 합니다.

doc/*.txt                     # doc/notes.txt 파일은 무시하지만, doc/server/arch.txt 파일은 무시하지 않습니다.


 

2.2.6. staged 되고 있는 변경 / 되어 있지 않은 변경의 열람

 

git status 명령만으로는 어느 파일이 변경되었는지 만 알 수 있고, 실제로 어떻게 바뀌었는지 알 수가 없습니다.

이 경우에는 git diff 명령을 사용 합니다. git diff 명령에 대해서는 다음에 자세하게 설명할 예정 입니다.

git diff 명령을 가장 자주 사용하는 경우는 "변경은 했지만 아직 staged 하고 있지 않는 변경 내역은?"과 "위탁 대상으로 된 staged 된 변경 내역은?"에 대한 부분 입니다. 

물론 git status 명령을 사용하여 이것에 대한 대략적인 결과는 할 수 있습니다. 하지만, git diff 명령은 추가하거나 삭제한 정확한 행에 대해 패치 형식으로 표시 합니다.

 

방금전에 생성한 README 파일을 편집하고 GIT에 staged하고, benchmarks.rb 파일은 편집만 해놓고 아직 staged 하지 않은 상태에 있다고 가정 합니다. 여기서 git status 명령을 수행하면, 다음과 같은 결과가 나오게 됩니다.

 

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# new file:   README
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
# modified:   benchmarks.rb
#

 

변경했지만 아직 staged 하고 있지 않는 내용을 보려면, 인수 없이 git diff 명령만을 수행 합니다.

 

$ git diff
diff --git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..da65585 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
           @commit.parents[0].parents[0].parents[0]
         end

+        run_code(x, 'commits 1') do
+          git.commits.size
+        end
+
         run_code(x, 'commits 2') do
           log = git.commits('master', 15)
           log.size

 

이 명령은, 작업 디렉터리의 내용과 staging 영역에 저장된 내용을 비교 합니다. 위의 결과를 보면 당신이 변경한 내용이 아직 staged 되어 있지 않은 것을 알 수 있습니다.

 

저장소(Repository)에 위탁한 내용과 staged 된 내용을 비교해 보고 싶은 경우에는 git diff -cached 명령을 사용 합니다.

(Git 버전 1.6.1 이후에는 git diff -staged 명령도 사용할 수있습니다. 이 쪽이 기억하기 쉬울 것 입니다.)

이 명령은 staged 되고 있는 변경과 마지막으로 저장소에 위탁된 내용을 비교 합니다.

 

$ git diff --cached
diff --git a/README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
+++ b/README2
@@ -0,0 +1,5 @@
+grit
+ by Tom Preston-Werner, Chris Wanstrath
+ http://github.com/mojombo/grit
+
+Grit is a Ruby library for extracting information from a Git repository


git diff 명령 자체는 위와 같이 위탁 이후의 모든 변경 사항에 대해 표시하지 않는 다는 것에 주의해야 합니다.

어디까지나 staged 되어있지 않은 변경의 내용만 표시 합니다. git를 처음 접근하시는 분이 변경 내용을 모두 staged 해버린 상태에서 이 명령을 실행하면 아무런 출력도 하지 않기 때문에 조금 당황할 수도 있습니다.  

 

다음은 git diff 명령의 또 하나의 예 입니다. benchmarks.rb 파일을 일단 staged 한 이후에 편집해 보도록 합니다.

git diff를 사용하면, staged 된 파일의 변경과 아직 staged 되어 있지 않는 파일의 변경 내역을 볼 수 있습니다.

 

$ git add benchmarks.rb
$ echo '# test line' >> benchmarks.rb
$ git status
# On branch master
#
# Changes to be committed:
#
# modified:   benchmarks.rb
#
# Changed but not updated:
#
# modified:   benchmarks.rb
#


이제, 여기서 git diff 명령을 수행하면, 아직 staged 되어 있지 않은 변경 사항에 대하여 알 수 있습니다.

 

$ git diff
diff --git a/benchmarks.rb b/benchmarks.rb
index e445e28..86b2f7c 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -127,3 +127,4 @@ end
 main()

 ##pp Grit::GitRuby.cache_client.stats
+# test line

 

그리고, git diff --cached 명령을 사용하면 저장소와 staged 된 내용을 비교하여, 변경된 내역을 알 수 있습니다.

 

$ git diff --cached
diff --git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..e445e28 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
          @commit.parents[0].parents[0].parents[0]
        end

+        run_code(x, 'commits 1') do
+          git.commits.size
+        end
+             
        run_code(x, 'commits 2') do
          log = git.commits('master', 15)
          log.size

 

2.2.7. 변경된 사항을 저장소(Repository)에 위탁

 

이제 staging 영역에 변경된 사항들을 모아 준비가 완료 되었다면, 변경된 사항을 GIT 저장소(Repository)에 위탁할 수 있습니다. 위탁의 대상이 되는 것은 추가하거나 변경한 것 중 staged 된 것만 가능 합니다. 따라서 아직 git add를 실행하여 staged 되어 있지 않은 파일은 위탁 대상에 포함되지 않습니다. staged 되어 있지 않은 파일은 변경된 채로 그냥 디스크에 계속 남아있게 됩니다.

 

이번 경우는 마지막에 git status 명령을 실행하여 모든 것이 staged 되고 있는 것을 확인했다는 것을 가정 합니다. 즉, 변경된 사항들을 저장소에 위탁할 준비가 되어 있는 상태를 말 합니다. 

변경된 사항을 저장소에 위탁하기 위한 가장 간단한 방법은 git commit 명령을 입력하는 것 입니다.

 

$ git commit


이것을 실행하면, 앞서 지정된 에디터가 실행 됩니다. (Shell의 $EDITOR 환경 변수로 설정되어 있는 에디터로써 리눅스에서 통상적으로 vim 또는 emacs 입ㄴ다. 그 이외에도 1장에서 설명한 바와 같이 git config --global core.editor 명령으로 자신이 사용하는 에디터를 지정할 수 있습니다.)

 

지정된 에디터가 실행되면 다음과 같은 텍스트가 표시 됩니다. (다음 화면은 Vim 에디터의 예 입니다.)

 

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   README
#       modified:   benchmarks.rb
~
~
~
".git/COMMIT_EDITMSG" 10L, 283C


실행된 에디터에서 표시되는 메시지는 기본으로 기록되는 위탁 메시지 입니다.  이 메시지를 지워 스스로 위탁 메시지를 기록하거나 추가 할 수도 있고, 향후에 무엇을 위탁했는지 알기 위해 그대로 남겨둬도 괜찮습니다.

(만약 내가 무엇을 변경했는지를 보다 명확하게 알기 위해서는 git commit 명령에 -v 옵션을 지정 합니다. 그러면 diff한 내용이 에디터에 표시되기 때문에 무엇을 변경 했는지 보다 정확하게 알 수 있게 됩니다.)

 

에디터를 종료시키면 Git는 작성한 메시지를 포함하여 Git 저장소에 위탁을 수행 합니다.

(참고로 코멘트 및 diff 내용은 삭제 됩니다.)

 

에디터가 열리는 것이 귀찮다면, 위탁 메시지를 인-라인으로 기술 할 수도 있습니다. 이 경우에는 commit 명령 다음에 -m 옵션을 붙이고 다음과 같이 기술 합니다.

 

$ git commit -m "Story 182: Fix benchmarks for speed"
[master]: created 463dc4f: "Fix benchmarks for speed"
 2 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 README

 

이렇게 해서 여러분은 GIT 저장소에 첫 위탁을 할 수 있었습니다. 이번 위탁에 대하여 "어느 브랜치에 위탁했는가 (master)", "그 위탁의 SHA-1 체크 섬 (463dc4f)", "변경된 파일의 수", "그 위탁으로 추가되거나 삭제 되거나 한 행의 수" 등의 정보가 표시되는 것을 볼 수 있습니다.

 

참고로, 위탁이 기록되는 것은 stating 영역의 snapshot 이라는 것을 기억해 두어야 합니다. staged 하고 있지 않는 정보에 대해서는 변경된 상태인 채 위탁하지 않고 남아 있습니다. 만약 다른 저장소로 위탁하거나 추가로 현재 저장소에 위탁하기 위해서는 재차 add 명령을 수행할 필요가 있습니다.

 

위탁 할 때마다 프로젝트의 snapshot이 기록되어 나중에 그것을 취소하거나 참조하거나 할 수 있게 됩니다.

 

2.2.8. staging 영역의 생략

 

저장소에 위탁할 내용을 쉽게 편집하고 관리 할 수 있으며, 실수를 방지할 수 있다는 점 때문에 stating 영역은 매우 편리 합니다. 하지만, 평상시에 반복적으로 수행하는 작업의 경우 필요 이상으로 복잡하게 느껴질 수도 있습니다.

stating 영역으로의 저장을 생략하기 위해서 Git는 간단한 옵션을 제공 합니다. git commit 명령에 - 옵션을 지정하면 추적 대상이 되고 있는 파일들을 자동적으로 staged 하고나서 위탁 절차를 수행 합니다.

즉 git add 명령을 생략할 수 있다는 것 입니다.

 

$ git status
# On branch master
#
# Changed but not updated:
#
# modified:   benchmarks.rb
#
$ git commit -a -m 'added new benchmarks'
[master 83e38c7] added new benchmarks
 1 files changed, 5 insertions(+), 0 deletions(-)


이 경우, 위탁하기 전에 benchmarks.rb를 git add 할 필요가 없다는 것에 주의 합니다.

 

2.2.9. 파일의 삭제

 

파일을 Git로부터 삭제하려면, 추적 대상에서 제외(정확하게 말하면 staging 영역에서 삭제)하고 위탁 합니다.

git rm 명령은 이 작업을 수행하며, 작업 디렉터리로부터 파일의 추적에 포함되지 않도록 합니다.

하지만,  프로젝트에서 추적에 포함되지 않는 파일은 계속 남아있기 때문에, 완전히 삭제하려면 rm 명령을 사용하여 마지막으로 직접 삭제해야 합니다.

 

단지, 작업 디렉터리에서 rm 명령을 이용하여 파일을 삭제했을 경우, git status 명령을 수행한 출력 화면에서 "Changed but not updated" (즉 staged 되어 있지 않다.) 라고 표시 됩니다.

 

$ rm grit.gemspec
$ git status
# On branch master
#
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#
#       deleted:    grit.gemspec
#


이제, git rm을 수행하면, 파일의 삭제된 내용이 staged 됩니다.

 

$ git rm grit.gemspec
rm 'grit.gemspec'
$ git status
# On branch master
#
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       deleted:    grit.gemspec
#


이제 다음에 저장소에 위탁할 경우에는 파일이 삭제 되어 있으며, 추적 대상에서 제외 됩니다.

 

만약 변경한 파일을 벌써 staged 하고 있다면, -f 옵션으로 강제로 삭제해야 합니다. -f 옵션은 git의 추적 기록과 파일을 함께 삭제하는 옵션 입니다. 하지만 -f 옵션을 이용하여 아직 snapshot에 기록되어 있지 않은 파일을 잘못해서 삭제해 버리면 Git는 그 파일을 영원히 복구하지 못합니다. 따라서 가급적 -f 옵션은 사용하지 않는 것이 좋습니다. 

 

이 밖에 "이런 기능을 추가하면 좋겠다." 라고 생각될 기능 같은 경우 파일 자체는 현재 작업 디렉터리에 남겨 놓으면서 staging 영역에서의 삭제만을 실시 할 수도 있습니다. 즉, 하드디스크상에는 파일을 남겨 두고 싶지만, Git 에서 추적 시키고 싶지 않은 경우 입니다.

 

이 기능이 특히 필요할 경우는 .gitignore 파일에 추적 제외 대상으로 포함하는 것을 실수로 잊어먹어서 로그 파일이나 수많은 .a 파일이 실수로 staging 영역에 추가되어 버렸을 경우 입니다.

 

이런 경우는 --cached 옵션을 사용 합니다.

 

$ git rm --cached readme.txt

 

이외에 파일명이나 디렉터리명, 그리고 파일의 glob 형식의 패턴을 git rm 명령에 사용할 수 있습니다. 즉, 다음과 같이 사용할 수도 있는 것 입니다.

 

$ git rm log/*.log


* 의 전에, 백슬래쉬()가 있는 것에 주의해야 합니다. 이것이 필요한 이유는, 쉘에 의하여 파일 명에 대한 작업이 수행되면서 GIT도 같이 작업을 수행할 수 있기 때문 입니다. 이 명령은 log/ 디렉터리에 있는 .log 확장자를 가진 파일을 모두 삭제 합니다. 또한, 이렇게 사용 할 수도 있습니다.

 

$ git rm *~

 

위 명령은 ~로 끝나는 파일을 모두 삭제 합니다.

 

2.2.10. 파일의 이동

 

다른 수많은 VCS와 달리 Git는 파일의 이동을 명시적으로 추적할 필요가 없습니다. Git안에서 파일명을 변경해도 파일 이름을 변경해다는 메타데이터는 Git에 보존되지 않습니다. 하지만, Git는 우수한 시스템이기 때문에 파일명이 바뀐 것을 알 수 있습니다. 파일의 이동을 알아내는 구조에 대해서는 잠시 후에 설명 합니다.

 

하지만, git에는 mv 명령이 있습니다. git에서 파일명을 변경하고 싶다면 다음의 명령을 실행 합니다.

 

$ git mv file_from file_to


위의 명령을 실행하고나서 status를 확인하면, git는 파일명이 변경되었다고 표시되는 것을 알 수 있을 것 입니다.

 

$ git mv README.txt README
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
# Changes to be committed:
#   (use "git reset HEAD &l


 

profile

인생은 연극이고 세상은 무대이다!

이솝 임베디드 포럼 운영 및 비즈니스와 관련된 것 이외에 E-Mail이나 메신저 및 휴대폰 등을 통한 개인적인 질문 및 답변은 받지 않습니다. 문의 사항은 이솝 임베디드 포럼 게시판을 이용해 주시면 감사하겠습니다.

첨부
엮인글 :
http://www.aesop.or.kr/index.php?mid=Board_Documents_Linux_Applications&document_srl=35591&act=trackback&key=f39

엉금엉금

2010.01.22 00:48:40
*.137.74.80

여기까지는 쉽게쉽게 따라왔네요..

감사합니다.

최강산

2010.01.26 23:41:48
*.131.74.195

이렇게 쉽게 번역까지 해주셔서 감사합니다^^

List of Articles
번호 제목 글쓴이 날짜 조회 수
93 Yocto project 소개자료 [2] 고도리 2019-08-24 430
92 Yocto zynq howto - 예전자료 고도리 2019-08-24 166
91 apache-1.3.33 arm porting by tssuk [3] 고도리 2013-05-21 2924
90 i2c scan하는 코드입니다. 고도리 2012-07-27 5043
89 dropbear ssh daemon 포팅하기 [1] 고도리 2012-06-30 5667
88 ffmpeg을 이용한 camera 영상 저장 file [1] 고도리 2012-05-01 5859
87 Linux application에서의 clock과 system timer설정 고도리 2011-08-15 7364
86 ffmpeg x86 compile & cross compile howto file 고도리 2011-08-05 7819
85 oss를 이용한 read, write, read/write program file [2] 고도리 2011-01-25 10523
84 GIT 사용법 (ProGIT) - 2.6. 태그(TAGS) 붙이기 [2] JhoonKim 2010-02-09 15124
83 GIT 사용법 (ProGIT) - 2.5. 원격 저장소의 사용 방법 [2] JhoonKim 2010-02-04 16044
82 GIT 사용법 (ProGIT) - 2.4. 작업의 취소 [1] JhoonKim 2010-02-03 15100
81 GIT 사용법 (ProGIT) - 2.3. 위탁 이력의 열람 file [1] JhoonKim 2010-02-03 13302
» GIT 사용법 (ProGIT) - 2.2. GIT 저장소(Repository)에 기록 file [2] JhoonKim 2010-01-21 16019
79 GIT 사용법 (ProGIT) - 2.1. GIT 저장소(Repository)의 취득 JhoonKim 2010-01-20 18347
78 GIT 사용법 (ProGIT) - 1.5. 최초 GIT의 환경 설정 [3] JhoonKim 2010-01-13 16592
77 GIT 사용법 (ProGIT) - 1.4. GIT 설치 JhoonKim 2010-01-11 21192
76 GIT 사용법 (ProGIT) - 1.2. GIT 개발 역사 / 1.3. GIT 기본 ... file [3] JhoonKim 2010-01-10 14777
75 GIT 사용법 (ProGIT) - 1.1. 버전 관리 시스템의 개념 file [6] JhoonKim 2010-01-07 19489
74 I.MX Multimedia and Applications Framework 기술자료 ... file [2] 장석원 2009-10-26 11048

사용자 로그인