Dev Ops/Git Git 사용법 III (되돌리기/수정 파일 되돌리기/Pull/Fetch/tag)
  • 728x90
    반응형

     

    Git 사용법


     

    목차

       

       

      되돌리기

      📌 Git를 사용하면 실수는 대부분 복구할 수 있지만 되돌린 것은 복구할 수 없다.

      완료한 커밋을 수정해야 할 때 --amend옵션을 사용한다.

       

      $ git commit --amend

       

      이 명령은 Staging Area를 사용하여 커밋한다. 만약 마지막으로한 커밋 후 수정한 것이 없다면 조금 전에 한 커밋과 모든 것이 같다. 이때는 커밋 메시지만 수정한다.

       

      커밋을 했는데 Stage 하는 것을 빼먹은 파일이 있으면 아래와 같이 수정할 수 있다.

      $ git commit -m 'initial commit'

      $ git add forgotten_file

      $ git commit --amend

       

      여기서 실행한 명령어 3개는 모두 커밋 한개로 기록된다. 두 번째 커밋은 첫 번째 커밋을 덮어쓴다.

       

       

       

      잘못 Push한 커밋 되돌리기

      📌 잘못된 내용을 커밋을 리모트 저장소에 Push 하였을때 히스토리를 남기지 않고 되돌리는 방법은 아래와 같다.

      $ git reset --hard HEAD^

       

      원하는 커밋 버전까지 반복 수행하여 되돌아 간다.

      $ git push --force

       

      되돌려진 커밋 상태를 리모트 저장소에 Push 한다. 위와 같은 방법으로 커밋을 되돌리면 수정된 파일들이 모두 되돌아 감으로 주의해야 한다.

       

       

      파일 상태를 Unstage로 변경하기

      📌 다음은 Staging Area와 워킹 디렉토리 사이를 넘나드는 방법을 설명한다.

      예를 들어 파일을 두 개 수정하고서 각각 커밋하려고 했지만, 실수로 git add *를 실행해 버렸다. 두 파일 모두 Staging Area에 들어있다. 둘 중 하나를 꺼내는 법에 대해서 설명한다.

       

       

      Changes to be commited 밑에git reset HEAD <file>... 메시지가 보인다.

      이 명령으로 Unstaged 상태로 변경할 수 있다. CONTRIBUTING.md 파일을 Unstaged 상태로 변경해보자.

       

       

      CONTRIBUTING.md 파일은 Unstaged 상태가 됐다.

       

      💡 git reset 명령은 매우 위험하다. --hard 옵션과 함께 사용하면 더욱 위험하다. 하지만 위에서 처럼 옵션 없이 사용하면 워킹 디렉토리의 파일은 건드리지 않는다.

       

       

       

      Modified 파일 되돌리기

      📌 CONTRIBUTING.md 파일을 수정하고 나서 다시 되돌리는 방법은git status 명령으로 출력되는 내용에 나와있다.

       

       

      위의 메시지는 수정한 파일을 되돌리는 방법을 정확하게 알려 준다.

       

       

      파일을 열어보면 정상적으로 복원된 것을 알 수 있다.

       

      💡 git checkout -- [file] 명령은 위험한 명령이다. 원래 파일로 덮어썼기 때문에 수정한 내용은 전부 사라진다.

       

      변경한 내용을 쉽게 버릴수는 없고 하지만 당장은 되돌려야만 하는 상황이라면 Stash와 Branch를 사용하자.

       

       

       

      리모트 저장소

      📌 리모트 저장소를 관리할 줄 알아야 다른 사람과 함께 협업할 수 있다. 리모트 저장소는 인터넷이나 네트워크 어딘가에 있는 저장소를 말한다.

       

      저장소는 여러 개가 있을 수 있는데 어떤 저장소는 읽고 쓰기 모두 할 수 있고 어떤 저장소는 읽기만 가능할 수 있다.

      다른 사람들과 함께 일한다는 것은 리모트 저장소를 관리하면서 데이터를 거기에 Push 하고 Pull 하는 것이다.

       

      리모트 저장소를 관리한다는 것은 저장소를 추가, 삭제하는 것뿐만 아니라 브랜치를 관리하고 추적할지 말지 등을 관리하는 것을 말한다.

       

       

      리모트 저장소 확인하기

      📌 git remote 명령으로 현재 프로젝트에 등록된 리모트 저장소를 확인할 수 있다. 이 명령은 리모트 자장소의 단축 이름을 보여준다.

       

      저장소를 Clone 하면 origin 이라는 리모트 저장소가 자동으로 등록되기 때문에 origin 이라는 이름을 볼 수 있다.

       

       

      -v 옵션을 주어 단축이름과 URL을 함께 볼 수 있다.

       

       

      리모트 저장소가 여러개 있다면 이 명령은 등록된 전부를 보여준다.

       

       

       

      리모트 저장소 추가하기

      📌 기존 워킹 디렉토리에 새 리모트 저장소를 쉽게 추가할 수 있는데 git remote add [단축이름] [url] 명령을 사용한다.

       

       

      이제 URL 대신에 pb 라는 이름을 사용할 수 있다.

      예를 들어 로컬 저장소에는 없지만 Paul의 저장소에 있는 것을 가져오려면 아래와 같이 실행한다.

       

       

      로컬에서 pb/master 가 Paul의 master 브랜치이다.

      이 브랜치를 로컬 브랜치중 하나에 Merge 하거나 Checkout 해서 브랜치 내용을 확인할 수 있다.

       

       

      리모트 저장소를 Pull 하거나 Fetch 하기

      📌 리모트 저장소에서 데이터를 가져오려면 아래와 같이 실행한다.

      $ git fetch [remote-name]

       

      이 명령은 로컬에는 없지만, 리모트 저장소에는 있는 데이터를 모두 가져온다.

      저장소를 Clone 하면 명령은 자동으로 리모트 저장소를 orgine 이라는 이름으로 추가한다.

       

      git fetch origin 명령을 실행하면 Clone 한 이후에 (혹은 마지막으로 가져온 이후에) 수정된 것을 모두 가져온다.

      git fetch 명령은 리모트 저장소의 데이터를 모두 로컬로 가져오지만, 자동으로 Merge 하지 않는다. 로컬에서 하던 작업을 정리하고 나서 수동으로 Merge 해야한다.

       

      git pull 명령으로 리모트 저장소 브랜치에서 데이터를 가져올 뿐만 아니라 자동으로 로컬 브랜치와 Merge 시킬 수 있다.

       

      git clone 명령은 자동으로 로컬의 master 브랜치가 리모트 저장소의 master 브랜치를 추적하도록 한다.

       

      그리고git pull 명령은 Clone 한 서버에서 데이터를 가져오고 그 데이터를 자동으로 현재 작업하는 코드와 Merge 시킨다.

       

       

      리모트 저장소에 Push 하기

      📌 프로젝트를 공유하고 싶을 때 Upstream 저장소에 push 할 수 있다. 

      이 명령은 git push [리모트 저장소 이름] [브랜치 이름] 으로 단순하다.

      $ git push origin master

       

      이 명령은 Clone 한 리모트 저장소에 쓰기 권한이 있고, Clone 하고 난 이후 아무도 Upstream 저장소에 Push 하지 않았을 때만 사용할 수 있다. 다른 사람이 작업한 것을 가져와서 Merge 한 후에 Push 할 수 있다.

       

       

       

      리모트 저장소 살펴보기

      📌 git remote show [리모트 저장소 이름] 명령으로 리모트 저장소의 구체적인 정보를 확인할 수 있다.

       

       

      리모트 저장소의 URL과 추적하는 브랜치를 출력한다.

      이 명령은git pull 명령을 실행할 때 master 브랜치와 Merge 할 브랜치가 무엇인지 보여준다.

      git pull 명령은 리모트 저장소 브랜치의 데이터를 모두 가져오고 나서 자동으로 Merge 할 것이다.

       

       

      리모트 저장소 이름을 변경하거나 리모트 저장소 삭제하기

      📌 git remote rename 명령으로 리모트 저장소의 이름을 변경할 수 있다.

       

      예를 들어 pb 를 paul로 변경하려면git remote rename 명령을 사용한다.

       

       

      로컬에서 관리하던 리모트 저장소의 브랜치 이름도 바뀐다는 점을 생각해두자.

       

      pb/master 로 리모트 저장소 브랜치를 사용했으면 이제는paul/master 라고 사용해야 한다.

       

      리모트 저장소를 삭제해야 한다면 git remote removegit remote rm 명령을 사용한다.

       

      서버정보가 바뀌었을 때, 더는 별도의 미러가 필요하지 않을 때, 더는 기여자가 활동하지 않을 때 필요하다.

       

       

       

       

      태그 조회하기

      📌 git tag  명령으로 이미 만들어진 태그가 있는지 확인할 수 있다.

      $ git tag

      v0.1

      v1.3

       

      이 명령은 알파벳 순서로 태그를 보여준다. 검색 패턴을 사용하여 태그를 검색할 수 있다. Git 소스 저장소는 500여 개의 태그가 있다고 가정하고, 만약 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

       

       

       

      태그 붙이기

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

       

      Lightweight 태그는 브랜치와 비슷한데 브랜치처럼 가리키는 지점을 최신 커밋으로 이동시키지 않는다. 단순히 특정 커밋에 대한 포인터일 뿐이다.

       

      한편 Annotated 태그는 Git 데이터베이스에 태그를 만든 사람의 이름, 이메일과 태그를 만든 날짜, 그리고 태그 메시지도 저장한다.

       

      GPG(GNU Privacy Guard)로 서명할 수도 있다. 일반적으로 Annotated 태그를 만들어 이 모든 정보를 사용할 수 있도록 하는 것이 좋다. 하지만 ,임시로 생성하는 태그거나 이러한 정보를 유지할 필요가 없는 경우에는 Lightweight 태그를 사용할 수도 있다.

       

       

      Annotated 태그

      📌 Annotated 태그를 만드는 방법은 tag 명령을 실행할 때 -a 옵션을 추가한다.

       

       

      -m 옵션으로 태그를 저장할 때 메시지를 함께 저장할 수 있다.

       

      명령을 실행할 때 메시지를 입력하지 않으면 Git는 편집기를 실행 시킨다.

       

      git show 명령으로 태그 정보와 커밋 정보를 모두 확인할 수 있다.

       

       

      커밋 정보를 보여주기 전에 먼저 태그를 만든 사람이 누구인지, 언제 태그를 만들었는지, 그리고 태그 메시지가 무엇인지 보여준다.

       

       

       

      Lightweight 태그

      📌 Lightweight 태그는 기본적으로 파일에 커밋 체크섬을 저장하는 것 뿐이다.

      Lightweight 태그를 만들 때는 -a, -s, -m 옵션을 사용하지 않는다.

       

       

      이 태그에  git show  를 실행하면 별도의 태그 정보를 확인할 수 없다.

       

       

       

      나중에 태그하기

      📌 "updated rakefile" 커밋을 v1.2 로 태그하지 못했다고 해도 나중에 태그를 붙일 수 있다.

      특정 커밋에 태그하기 위해서 명령의 끝에 커밋 체크섬을 명시한다.(긴 체크섬을 전부 사용할 필요는 없다.)

      $ git tag -a v1.2.9fceb02

       

       

       

      태그 공유하기

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

      태그를 만들었으면 서버에 별도로 Push 해야 한다.

      브랜치를 공유하는 것과 같은 방법으로 할 수 있다. 'git push origin [태그 이름]' 을 실행한다.

      $ git push origin v1.5

       

      만약 한 번에 태그를 여러개 Push 하고 싶으면 --tags 옵션을 추가하여 git push 명령을 실행한다. 이 명령으로 리모트 서버에 없는 태그를 모두 전송할 수 있다.

      $ git push origin --tags

       

       

      태그를 Checkout 하기

      📌 태그는 브랜치와는 달리 가리키는 커밋을 바꿀 수 없는 이름이기 때문에 Checkout 해서 사용할 수 없다.

      태그가 가리키는 특정 커밋 기반의 브랜치를 만들어 작업하려면 아래와 같이 새로 브랜치를 생성한다.

      $ git checokout -b version2 v2.0.0

       

       

       

      Git Alias

      📌 Git의 명령을 전부 입력하는 것이 귀찮다면 git config 를 사용하여 각 명령의 Alias을 쉽게 만들 수 있다.

       

       

      이미 있는 명령을 편리하고 새로운 명령으로 만들어 사용할 수 있다. 예를 들어 파일을 Unstaged 상태로 변경하는 명령을 만들어서 불편함을 덜 수 있다.

       

       

      아래 두 명령은 동일한 명령이다.

      $ git unstage fileA$ git reset HEAD --fileA

       

      추가로 last 명령을 만들어 보자.

       

       

      ! 를 제일 앞에 추가하면 외부 명령을 실행한다.

       

      커스텀 스크립트를 만들어서 사용할 때 매우 유용하다.

       

      아래 명령은 git visual 이라고 입력하면 gitk 가 실행된다.

       

       

       

       

       

       

      728x90
      반응형

      'Dev Ops > Git' 카테고리의 다른 글

      Git 사용법 V  (0) 2018.06.22
      Git 사용법 IV  (0) 2018.06.20
      Git 사용법 II  (0) 2018.06.19
      Git 사용법 I (저장소 생성/Clone/Status/Stage/.gitignore  (0) 2018.06.18
      git 설치 및 설정  (0) 2018.06.18
    상단으로