깃허브 기본 사용 3 (Reset, Revert, Pull, Clone, Hub Branch)

이번에 알아볼 것은 Reset, Revert 와 Pull, Clone, 그리고 Git Hub의 브런치이다.

Reset 과 Revert 는 시점 되돌리기에 관한 내용이고,

Pull 과 Clone 은 자료 내려받기에 관한 내용,

Git Hub 의 브런치는 프로젝트를 진행하려면 반드시 알아야 할 구조에 관한 내용 정도가 되겠다.

---

그럼 먼저 Reset 에 대해 알아보겠다.

Reset 을 좀 더 쉽게 알 수 있도록 한 가지 상황을 만들어보겠다.

 

test.txt 라는 빈 파일을 하나 만들었고,

그 안에 111 이라는 내용을 적고 'test 111 저장' 로그,

222 라는 내용을 추가로 적고 'test 222 저장' 로그,

333 이라는 내용을 추가로 적고 'test 333 저장' 로그를 남겼다.

그렇다면 현재 test.txt에는 333까지 적혀져 있을 텐데, 이 파일을 111만 적혀져 있던 시점으로 돌리려고 한다.

git reset --hard 커밋ID

: 기록된 로그의 시점으로 리셋을 시켜주는 명령어

 

명령어를 사용하고 난 뒤, test.txt 내용을 확인해봤더니 111이 적혀있는 시점으로 돌아간 것을 확인할 수 있다.

단, 위에 명령어를 사용하고 난 뒤에 로그를 확인해보면 알겠지만, 기존의 222와 333의 로그는 완전히 사라진 것을 볼 수 있다. 이 명령어는 말 그대로 리셋시키는 것이기 때문에, 되돌려진 시점 이후의 로그들은 사라진다. 단순히 로그만 사라지는 것이 아니라 그 로그를 남기면서 썼던 파일의 내용이나, 파일 그 자체가 사라진다. 그래서 정말 필요하지 않는 이상 일반적으로 잘 쓰이진 않는다.

 

 

Revert에 대해 알아보겠다.

 

이번에도 상황을 만들어보겠다.

아까와 마찬가지로 test.txt에 111, 222, 333 로그들이 남겨져 있는데,

현재 333인 상태에서 로그들을 남긴 채로 222 파일로 돌아가려고 한다.

git revert 커밋ID

: 그 로그의 시점으로 되돌아가는 명령어

 

이 명령어의 중요한 점은, 돌아가고 싶은 로그 이후의 커밋ID를 적어야 한다는 점이다. 그래야 내가 원하는 시점으로 돌아갈 수 있다. 내가 원하는건 222 때의 로그이니, 222 이후의 333 커밋ID를 명령어에 적어야 한다. 헷갈리면 위의 사진에 나온 화살표를 확인해보면 되겠다.

 

그렇게 하고 파일의 내용을 확인해봤더니 내가 원했던 222 까지만 적혀져있는 것을 볼 수 있다. 그러면서도 리셋과는 달리 로그들도 남겨져있다.

그러나 이 명령어는 한 단계 전의 로그로 되돌아가는 것만 가능하다. 두 단계 이상의 로그로 돌아가려고 하면 충돌이 일어난다(내용 수정을 하면 되긴 하다). 현재 내가 333 인데, 111 로 가려고 하면 그건 안된다는 것이다. 333 이면 222 까지만 갈 수 있다.

---

이번엔 Clone에 대해서 알아보자.

Clone이란, 디렉터리 자체를 복사해서 불러오는 것이다.

현재 Git Hub에 test.txt, test1.txt, test2.txt 파일 세 개가 로그와 함께 올려져있다.

이전까진 Hub에 자료들을 올리기만 했는데, 이제 그 자료들을 로컬로 받는 법을 알아볼 것이다.

 

git clone GitHub경로

: Hub 디렉터리 자체를 내 로컬에 받아올 수 있는 명령어

 

Clone 명령어를 입력하고 나니, exam02(Hub에 있는 디렉터리)라는 디렉터리가 하나 생겼다.

 

그 디렉터리를 들어가보니, git init을 하지도 않았는데 자동적으로 Master 브런치로 잡혀져있고, test.txt, test1.txt, test2.txt 파일이 있는 것은 물론 로그까지도 내 로컬에 저장된 것을 확인할 수 있다.

 

무엇보다 중요한 것은, git remote 설정을 따로 하지 않아도 된다는 점이다. Clone으로 불러온 순간 이미 잡혀져있기 때문에 내가 연결할 필요 없이 바로 Push만 하면 된다.

 

 

다음은 Pull 명령어를 볼 차롄데,

Clone과는 명백하게 다른 차이가 있다. 그걸 확인하기 위해 위의 상태에서 Reset 명령어를 사용해 test.txt만 남긴 채 파일과 로그를 다 없애버리도록 하겠다.

위를 보면 test.txt만 남은 것을 확인할 수 있다.

이제, Pull 명령어를 사용해보겠다.

 

git pull

: Hub의 로그와 자료를 받아오는 명령어

 

방금 전 Reset으로 test.txt만 남긴 상태였는데, Pull 명령어를 사용해서 Hub에 있는 자료들과 로그들을 다시 다 받아온 것을 확인할 수 있다.

 

 

그럼 여기서 하나 의문점이 드는게, 아니 그냥 Pull로 계속 받아오면 되지 왜 Clone 명령어를 쓰는거냐고 생각할 수 있다.

이건 명백하게 차이가 있다.

 

Clone 명령어는, Hub의 디렉터리 자체를 받아오는 것이다. 그렇기 때문에 내가 로컬에서 git remote를 하지 않았는데도 이미 Hub로 연결이 되어있었던 것이다.(맨 처음 Hub로 디렉터리를 Push할 때 git remote 설정을 해두니까)

그래서 실제로 Clone 명령어를 사용하면 디렉터리가 생성이 된다.

 

Pull 명령어는, 내 로컬 폴더에 Hub의 자료와 로그들만 받아오는 것이다.

 

처음엔 나도 헷갈렸는데, 어려우면 그냥 이렇게 생각하면 될 것 같다.

처음 프로젝트 시작할 땐 무조건 Clone 명령어로 디렉터리를 받아온다. 그리고 그 이후부터는 그냥 Pull 명령어로 자료를 받아오면 된다.

처음에 무조건 Clone으로 받아와야 하는 이유가 또 있는데, 이는 다음에 설명할 브런치와 연결된다.

---

지금까지는 내 로컬에만 브런치를 만들었었는데, 사실 Hub에도 브런치를 만들 수 있다. 앞으로는 계속 그렇게 진행할 것이다.

 

들어가기에 앞서 Hub의 브런치를 확인하는 기본 명령어들을 알아보자.

git branch -r

: Git Hub의 브런치를 보여주는 명령어

(현재는 Hub에 따로 브런치를 만들지 않았기에 Master만 있다)

 

git branch -a

: 로컬과 Git Hub에 있는 모든 브런치를 보여주는 명령어

(로컬도 마찬가지로 따로 브런치를 만들지 않았기 때문에 Master만 있다.)

 

 

Hub에 브런치를 만드려면 우선 로컬에 브런치를 만든 후, 그걸 Hub에 올려야 한다.

git push origin(이름) 브런치이름

: Hub에 브런치 올리는 명령어

 

a-branch를 로컬에서 만들고, 그걸 Hub로 올렸더니 Hub에 Master 말고도 a-branch가 생긴 걸 볼 수 있다.

 

근데 왜 Hub에 브런치가 있어야 할까?

한 프로젝트를 진행하고 있는 A, B, C라는 팀원이 있다.

각자 맡은 작업을 끝내고 이제 Hub에 작업물을 올려야 하는데, 그냥 Hub에 올리는게 아니라 Hub에 있는 각자의 브런치에 올리는 것이다.

 

그리고 그렇게 각자 올린 작업물들은 최종적으로 Hub의 Master 브런치에서 Merge 하게 된다.

 

여기서 앞서 말했던 Clone의 중요성이 또 다시 부각된다.

팀원들이 각각의 브런치를 로컬로 받아와서 작업 한다는건 결국 Hub 디렉터리를 Clone으로 받아와야 작업하기 수월해진다는 소리다. 브런치부터 Hub로의 연결까지 미리 설정이 다 되어있으니까.

 

Git Hub를 이용한 프로젝트는 이런 식으로 이루어진다고 보면 된다.

 

 

잘 사용하지는 않지만 Hub의 브런치를 삭제하는 명령어도 있다.

 

Hub의 브런치를 삭제할 때도 생성할 때와 마찬가지로 로컬의 브런치 먼저 삭제한 뒤에 Hub 브런치를 삭제해야한다.

git push origin --delete 브런치이름

: Hub의 브런치를 삭제하는 명령어

---

※ 추가

맨 처음 Hub 디렉터리를 Clone으로 받아와야 하는 이유가 또 한 가지 있는데,

이 사진은 맨 처음 Clone 명령어로 Hub 디렉터리를 받아온 것이다.

 

git branch -a 로 로컬과 Hub에 있는 브런치 모두를 확인해봤더니,

로컬에는 Master만, Hub에는 Master와 a-branch가 있다.

다시 확인해보자. 로컬에는 현재 Master 브런치만 있다.

 

그 상태로 git checkout a-branch를 했더니, Hub에만 있었던 a-branch로 변경이 됐다.

Clone으로 디렉터리를 받아오면 이런 점이 좋은 것이다. 원래 Hub 디렉터리에 있었던 a-branch를 Clone으로 받아오니, 따로 만들지 않아도 자동으로 a-branch를 생성시켜주는 것이다. 이래서 첫 디렉터리를 받아올 때는 Clone으로 받아와야 작업하기 수월해진다.