[Git] Git 기초 , 기본 사용법 (2) - 되돌리기, 리모트 remote, 태그 tag

안녕하세요
이어서 Git 기본 사용법에 대한 포스팅입니다.
이 번 포스팅에서는 데이터 되돌리기에 대해서 정리해볼텐데 ,
Git으로 커밋했던 모든 것은 언제나 복구할 수 있지만 커밋하지 않고 잃어버린 것은 복구할 수 없습니다.

11. 되돌리기

Git 을 사용하다보면 때때로 되돌리고 싶은 시점이 생길 때가 있습니다. Git을 사용하면 우리가 한 실수중 복구하지 못할 게 거의 없지만 되돌린 것은 복구할 수 없습니다.

--amend 옵션은 너무 일찍 커밋했거나, 어떤 파일을 빼먹었을 때, 메세지를 잘 못 적었을 때 등등 다시 커밋하고 싶을 때 사용합니다.

$ git commit --amend

일반 commit과 마찬가지로 Staging Area를 커밋하는건데, 직전 커밋과 비교해서 수정한 사항이 없다면 메세지만 수정됩니다. 편집기가 실행되면 이전 커밋 메세지가 자동으로 포함됩니다. 메세지를 수정하지 않고 그대로 커밋해도 기존의 커밋을 덮어씁니다.

깜빡하고 빠뜨린 파일이 있을 때

$ git commit -m "initial commit"
$ git add forgotten_file
$ git commit --amend

두 번째 커밋은 첫 번째 커밋을 덮어씌웁니다. 결과적으로 실수했던 커밋은 사라지고 새로운 커밋으로 대체됩니다.

11-1. 파일 상태를 Unstage로 변경하기

파일이 두 개있다고 가정합니다. 두 파일을 따로따로 커밋하려고 했지만, 실수로 git add . 를 실행 해버렸을 때, staged상태의 파일을 꺼내는 방법입니다.

먼저 git status로 상태를 확인합니다.

$ git add *
$ git status
    On branch master
    Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README
modified: CONTRIBUTING.md

git reset HEAD <file>... 이 명령을 실행하면 Unstaged상태로 변경됩니다.

$ git reset HEAD CONTRIBUTING.md
Unstaged changes after reset:
M CONTRIBUTING.md

이 상태에서 다시 git status 명령으로 변경된 사항을 확인합니다.

$ git status
On branch master
Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README
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: CONTRIBUTING.md

잘 동작합니다.

git reset 명령을 --hard 옵션과 함께 사용하면 워킹 디렉터리 파일까지 수정되기에 조심해야 합니다. 반대로 --hard 옵션을 사용하지 않으면 git reset명령은 Staging Area의 파일만 조작하기 때문에 위험하지 않습니다.

11-2. modified 파일 되돌리기

특정 파일을 최근에 커밋했던 버전으로 되돌리고 싶은 경우입니다.

방금 전 11-1에서 해봤던 코드의 일부입니다.

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: CONTRIBUTING.md

use "git checkout -- <file> to discard changes 워킹 디렉토리의 변경을 취소하는 방법이 나와있습니다.
checkout 명령을 실행 한 뒤, 상태를 확인해보면 modified 상태였던 파일이 원래대로 복구된 걸 볼 수 있습니다.
저장소에 있는 데이터를 가지고 나온다는 의미로 해석하면 이해하기 쉬울 것 같습니다.

$ git checkout -- CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README

12. 리모트 저장소

리모트 저장소는 인터넷이나 네트워크 어딘가에 있는 저장소를 말합니다. github를 이용한다면 github의 리포지토리가 됩니다.

12-1. 리모트 저장소 확인하기

git remote 명령으로 현재 프로젝트에 등록된 리모트 저장소를 확인할 수 있습니다.
이 명령은 리모트 저장소의 단축 이름을 보여줍니다. 저장소를 clone하면 자동으로 origin이라는 저장소가 등록됩니다.

git remote -v로 명령어에 옵션을 주면, 단축 이름과 함게 URL도 볼 수 있습니다.
리모트 저장소가 여러개 있다면 목록을 보여줍니다.

12-2. 리모트 저장소 추가하기

저장소를 clone으로 가져온 경우가 아니라면 직접 추가해야 합니다.
git remote add [단축 이름] [url] 명령으로 실행합니다.

12-3. 리모트 저장소를 Pull, Fetch하기

• Fetch

리모트 저장소에서 데이터를 가져오려면 간단히 git fetch [remote-url]을 실행합니다.
이 명령은 로컬에는 없지만, 리모트 저장소에 있는 데이터를 모두 가져옵니다.
그러면 리모트 저장소의 모든 브랜치를 로컬에서 접근할 수 있어서 언제든지 Merge를 하거나 내용을 살펴볼 수 있습니다.
결국, git fetch 명령어는 자동으로 Merge를 하지 않는다는 의미입니다. 수동으로 직접해야합니다.

• Pull

git pull 명령은 리모트 저장소 브랜치에서 데이터를 가져올 뿐 아니라 자동으로 Merge까지 시켜줍니다.

• 자주 쓰이는 패턴

정리하면 git clone명령은 데이터를 가져옴과 동시에 자동으로 로컬의 master브랜치가 리모트저장소의 master브랜치를 추적하도록 합니다. 그리고 로컬의 업데이트가 필요할 때, git pull 명령을 실행하면 clone한 서버에서 데이터를 가져오고 자동으로 Merge해줍니다.

$ git clone [url]
...
... 
얼마 뒤 원격 저장소의 데이터로 업데이트 하고 싶을 때
$ git pull

12-4. 리모트 저장소에 Push하기

git push origin master 명령어가 익숙하다면 쉽게 이해할 수 있습니다.
git push [리모트 저장소 이름] [브랜치 이름] 이 명령은 저장소에 쓰는 것이기 때문에 조건이 필요합니다.

• 리모트 저장소에 쓰기 권한이 있어야합니다.
• Clone한 사람이 여러 명 있을 때, 다른 사람이 Push한 후에 Push할 수 없다.
  • 먼저 다른사람이 작업한 것을 가져와서 Merge한 후에 Push할 수 있다.

Merge하는 방법에 대해서는 다른 포스팅에서 자세히 다뤄보겠습니다.

12-5. 리모트 저장소 살펴보기

git remote show [저장소 이름] 명령은 리모트 저장소의 구체적인 정보를 확인할 수 있습니다.
다음은 브랜치가 많은 경우 출력되는 예 입니다.

$ git remote show origin
* remote origin
URL: https://github.com/my-org/complex-project
Fetch URL: https://github.com/my-org/complex-project
Push URL: https://github.com/my-org/complex-project
HEAD branch: master
Remote branches:
    master tracked
    dev-branch tracked
    markdown-strip tracked
issue-43 new (next fetch will store in remotes/origin)
issue-45 new (next fetch will store in remotes/origin)
refs/remotes/origin/issue-11 stale (use 'git remote prune' to remove)
Local branches configured for 'git pull':
    dev-branch merges with remote dev-branch
master merges with remote master
Local refs configured for 'git push':
    dev-branch pushes to dev-branch (up to date)
    markdown-strip pushes to markdown-strip (up to date)
    master pushes to master (up to date)

Local refs configured for 'git push' 를 보면 git push 명령어에 브랜치를 생략하면 자동으로 어떤 브랜치에서 어떤 브랜치로 Push되는지 보여줍니다.
이 외에도 Local branches configured for 'git pull' 처럼 자동 Merge되는 브랜치도 확인됩니다.

12-6. 리모트 저장소 이름 바꾸기 & 삭제하기

git remote rename [원래 이름] [새 이름]은 저장소의 이름을 수정합니다.
git remote rm [저장소 이름] 으로 리모트 저장소를 삭제할 수 있습니다.

13. 태그

태그는 보통 릴리즈할 때 버전정보로 많이 사용합니다.

13-1. 태그 조회

git tag 명령으로 이미 만들어진 태그가 있는지 확인할 수 있습니다.
이 명령은 알파벳 순서대로 태그를 보여주지만 순서는 중요하지 않습니다.

1.8.5 버전의 태그들만 검색하고 싶은 경우 입니다.

$ git tag -l "v1.8.5*"
v1.8.5
v1.8.5-rc0
v1.8.5-rc1
v1.8.5-rc2
v1.8.5-rc3
v1.8.5.1
v1.8.5.2
v1.8.5.3
v1.8.5.4
v1.8.5.5

13-2. 태그 붙이기

Git의 태그는 Lightweight 태그와 Annotated태그로 두 종류가 있습니다.

• Lightweight 는 비교적 단순한 태그로 단순히 특정 커밋에 대한 포인터일 뿐입니다.
• Annotated는 해당 커밋에 대한 많은 정보들을 담고있습니다.
  예를 들어, 태그 만든 사람 이름, 이메일, 태그를 만든 날짜, 태그 메세지, GPG 서명(서명의 일종인가 봅니다.) 등을 포함할 수 있습니다.

일반적으로 Lightweight를 사용하고 많은 정보 저장이 필요할 때만 Annotated를 사용하면 됩니다.

13-3. 태그 사용법

• Annotated 사용법 입니다. -a 옵션을 사용합니다.

  $ git tag -a v1.4 -m "my version 1.4"
  $ git tag
  v0.1
  v1.3
  v1.4

• Lightweight 사용법 입니다. 옵션을 사용하지 않습니다.

$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5

태그를 설정하고나면 git show [태그명] 으로 태그 정보를 확인할 수 있습니다.
Lightweight으로 태그를 저장한 경우 커밋 정보만을 보여주게되지만, Annotate는 함께 저장한 태그 정보들도 보여주게 됩니다.

Lightweight 태그 정보

$ git show v1.4-lw
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number

Annotated 태그 정보

$ git show v1.4
tag v1.4
Tagger: Ben Straub <ben@straub.cc>
Date: Sat May 3 20:19:12 2014 -0700
my version 1.4
    commit ca82a6dff817ec66f44342007202690a93763949
    Author: Scott Chacon <schacon@gee-mail.com>
    Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number

13-4. 나중에 태그하기

예전 커밋에 대해 태그하는 방법입니다.

아래와 같은 커밋 로그가 있다고 가정합니다.

$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support

9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile    <---여기

964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme

커밋 체크섬을 모두 붙일 필요는 없습니다. 9fceb02는 updated rakefile의 앞 7자리를 땄습니다.

$ git tag -a v1.2 9fceb02

13-5. 태그 공유하기

git push명령은 자동으로 리모트 서버에 태그를 전송하지 않습니다.

git push origin [태그 이름] 을 실행하면 태그가 전송됩니다.
만약 한번에 태그를 전송하고 싶다면 --tags 옵션을 추가합니다.

$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
* [new tag] v1.4 -> v1.4
* [new tag] v1.4-lw -> v1.4-lw

이제 누군가 저장소에서 Clone 하거나 Pull을 하면 모든 태그 정보도 함께 전송됩니다.

---

여기까지로 기본적인 사용법에 대해 알아봤습니다.
감사합니다!