안녕하세요?

현재 국내에 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장에서 설명 합니다.)

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