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

안녕하세요?

 

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

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

 

GIT 사용법 (ProGIT) - 2.4. 작업의 재시도

 

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

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

 

2.4. 작업의 취소

 

어떤 상황인 경우, 우리는 기존에 했던 작업을 취소하고 다시 하고 싶어질 때가 있습니다.

이 장에서는 GIT에 위탁했던 사항들을 취소하기 위한 기본적인 방법에 대해 설명 하고자 합니다.

주의 할 점은 작업을 재시도 했던 내역에 대해 작업을 다시 재시도 한다면, 기존에 재시도 했던 작업 내용을 잃어 버리는 경우가 생길 수 있다는 것 입니다. 따라서, 작업의 재시도는 매우 신중하게 해야 합니다.

 

2.4.1. 바로 앞의 위탁 사항의 변경

 

작업의 재시도를 필요로 하는 자주 있는 경우는 "위탁에 추가 해야할 파일들을 빼먹은 경우", "위탁 메시지를 잘 못 작성한 경우" 등 입니다. 기존에 수행했던 위탁을 다시 하기 위해서는 --amend 옵션을 붙여 다시 한 번 더 위탁할 수 있습니다.

 

$ git commit --amend


이 명령은 staging 영역의 내용을 위탁에 사용 합니다. 만약 바로 앞의 위탁 이후에 프로젝트에 아무 변경을 하지 않은 상태에서 이 명령을 수행 한다면, snapshot의 내용은 완전히 동일하며, 단지 위탁 메시지의 변경만을 수행하게 됩니다.

 

이 명령을 수행하면, 위탁 메시지를 쓰기 위한 에디터가 동일하게 열립니다. 하지만, 에디터 안에는 사용자가 이미 바로 앞의 위탁에서 썻던 메시지가 그대로 남아 있게 됩니다. 이 메시지를 수정하면, 바로 앞에 위탁시의 작성 했던 메시지가 수정된 내용으로 교체 됩니다.

 

예를 들어, 일단 GIT에 위탁한 후, 어떤 파일이 위탁시에 빠져있었다고 가정해 봅니다. 이런 경우에는 이번 위탁에 빠진 파일을 추가 하기 위해서는 다음과 같이 합니다.

 

$ git commit -m '초기 위탁'
$ git add 잊고 있었던 파일
$ git commit --amend


 위의 3개의 명령의 결과로, 최종적으로 완성되는 것이 하나의 위탁 입니다. 맨 마지막의 commit 명령이 최초의 위탁의 결과를 덧쓰기 하게 됩니다.

 

2.4.2. staged 한 파일의 취소

 

다음에 계속되는 두 섹션에서는, staging 영역과 작업 디렉터리 변경에 관한 작업에 대해 알아보고자 합니다.

git status 명령을 수행하면 친절하게 변경 내용을 취소하는 방법에 대해 설명이 되어 있습니다.

예를 들어, 여러분이 두 파일을 변경하고 각각의 파일을 다르게 위탁을 할 생각이었는데, 잘 못해서 git add * 와 같은 명령을 입력하여, 한꺼번에 위탁했을 경우를 생각해 봅시다.

 

이 경우 두개의 파일이 모두 staged 되어 버렸습니다. staged 된 두 파일 중에 하나만 staged를 취소하는 방법은 어떻게 될까요? 이것은 git status 명령이 가르쳐 줍니다.

 

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


위에서 보면 "Chandged to be committed" 후에, (use "git reset HEAD <file>..." to unstage) 라고 나와 있습니다.

그럼 이 설명에 따라, benchmarks.rb 파일의 staged를 취소해 봅시다.

 

$ git reset HEAD benchmarks.rb
benchmarks.rb: locally modified
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   README.txt
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   benchmarks.rb
#


git reset 명령은 처음 접하는 명령이지만, 이미 staged 된 파일을 취소할 때 사용합니다.

위와 같이 staged를 취소하면, benchmarks.rb 파일은 변경되었지만 staged 되어 있지 않은 상태로 돌아오게 됩니다.

 

2.4.3. 파일 변경의 취소

 

만약 여러 분이 benchmarks.rb 파일을 수정하였지만 마지막으로 위탁된 파일로 내용을 되돌리고 싶을 경우에는 어떻게 할까요? 보통 코드를 수정하다가 잘못되었을 때 원본으로 복구를 할 경우가 많이 생깁니다.

이런 경우도 git status 명령을 입력하면 그 방법을 알 수 있습니다. 앞에서 출력된 git status 명령에서 그 방법이 알기 쉽게 표시되어 있습니다. 

 

# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   benchmarks.rb
#


위와 같이 변경을 취소하는 방법이 설명되어 있습니다. 그럼 설명된 것과 같이 명령을 입력한 후 git status 명령을 다시 입력해 봅니다.

 

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


위의 결과에서 알 수 있듯이, 변경된 사항이 삭제 된 것을 알 수 있습니다. 하지만 이것은 위험한 작업이라는 것을 우선 알아두셔야 합니다. 삭제 되기 이전의 변경 사항의 경우 완전이 사라져 버리며 복구할 수 있기 때문 입니다.

따라서, 이 파일의 변경 사항이 불필요 한 것이라고 확신할 때에만 이 명령을 사용하시길 바라며, 다른 경우에는 되도록이면 이 명령은 사용하지 않는 것이 좋습니다.

 

만약 당신이 단지 파일을 정리하고 싶을 뿐이라면, 다음 장에서 설명하는 stash나 branch를 학습하시면 됩니다. 파일을 정리하고 관리하는 데에는 주로 이쪽을 추천 합니다.

 

참고로, Git에 위탁한 내용의 거의 모든 것은 복구가 가능하다는 것을 알아두시기 바랍니다.

삭제한 branch의 위탁이나 --amend 위탁으로 덧쓰기되었던 원래의 위탁 내역 조차도 복구 할 수 있습니다.

(데이터의 복원 방법은 9장에서 설명 합니다.)

 

하지만, 아직 위탁하지 않은 내용의 경우 앞에서 설명한 취소 및 삭제 명령을 통하여 잃어버리면, 그것은 두 번 다시 복구할 수 없습니다. 

profile

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

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

엮인글 :
http://www.aesop.or.kr/index.php?mid=Board_Documents_Linux_Applications&document_srl=35598&act=trackback&key=dad

미스터쿨

2010.08.10 02:55:14
*.5.246.142

번역에 정말 감사드리고, 오타있는거 같아요.

 

삭제 되기 이전의 변경 사항의 경우 완전이 사라져 버리며 복구할 수 있기 때문 입니다.

 

있기 => 없기

 

 

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
» GIT 사용법 (ProGIT) - 2.4. 작업의 취소 [1] JhoonKim 2010-02-03 15100
81 GIT 사용법 (ProGIT) - 2.3. 위탁 이력의 열람 file [1] JhoonKim 2010-02-03 13302
80 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

사용자 로그인