본문 바로가기

프로그래밍 독학/Git

Pro git 독학일지 4장 - Git의 기초(3)

반응형

Pro git 독학일지 4장 - Git의 기초(3)

 

되돌리기

 

일을 하다 보면 모든 단계에서 어떤 것은 되돌리고 싶을 때가 있다.

이번에는 우리가 한 일을 되돌리는 방법을 살펴본다.

한 번 되돌리면 복구할 수 없기에 주의해야 한다.

Git을 사용하면 우리가 저지른 실수는 대부분 복구할 수 있지만 되돌린 것은 복구할 수 없다.

 

종종 완료한 커밋을 수정해야 할 때가 있다.

너무 일찍 커밋했거나 어떤 파일을 빼먹었을 때, 그리고 커밋 메시지를 잘못 적었을 때 한다.

 

$ git commit --amend

 

이 명령은 Staging Area를 사용하여 커밋한다.

만약 마지막으로 커밋하고 나서 수정한 것이 없다면(커밋하자마자 바로 이 명령을 실행하는 경우)

조금 전에 한 커밋과 모든 것이 같다. 이 때는 커밋 메시지만 수정한다.

 

편집기가 실행되면 이전 커밋 메시지가 자동으로 포함된다.

메시지를 수정하지 않고 그대로 커밋해도 기존의 커밋을 덮어쓴다.

 

커밋을 했는데 Stage하는 것을 깜빡하고 빠트린 파일이 있으면 아래와 같이 고칠 수 있다.

 

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

 

 

파일 상태를 Unstaged로 변경하기

 

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

두 영역의 상태를 확인할 때마다 변경된 상태를 되돌리는 방법을 알려주기 때문에 매우 편리하다.

예를 들어 파일을 두 개 수정하고서 따로따로 커밋하려고 했지만,

실수로 git add * 라고 실행해버렸다. 

두 파일 모두 Staging Area에 들어있다.

이제 둘 중 하나를 어떻게 꺼낼까?

우선 git status 명령으로 확인해보자.

 

 

git reset HEAD <file>...  메시지가 보인다.

이 명령으로 Unstaged 상태로 변경할 수 있다.

 

CONTRIBUTING.md 파일을 Unstaged 상태로 변경해보자.

git reset HEAD CONTRIBUTING.md

 

 

git reset 명령은 매우 위험하다.

--hard 옵션과 함께 사용하면 더욱 위험하다.

하지만 위에서처럼 옵션 없이 사용하면 워킹 디렉토리의 파일은 건드리지 않는다.

 

reset 명령이 정확히 어떻게 동작하는지, 어떻게 전문적으로 활용하는지는 Reset 명확히 알고 가기 부분에서 자세히 살펴보기로 한다.

 

 

Modified 파일 되돌리기

 

어떻게 해야 CONTRIBUTING.md 파일을 수정하고 나서 다시 되돌릴 수 있을까?

그러니까 최근 커밋된 버전으로 되돌리는 방법이 무엇일까?

아니면 처음 Clone했을 때처럼 워킹 디렉토리에 처음 Checkout한 그 내용으로 되돌리는 방법은 무엇일까?

 

git checkout -- [file]

 

이 명령은 꽤 위험한 명령이라는 것을 알아야 한다.

원래 파일로 덮어썼기 때문에 수정한 내용은 전부 사라진다.

수정한 내용이 진짜 마음에 들지 않을 때만 사용하자.

 

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

Git으로 커밋한 모든 것은 언제나 복구할 수 있다. 삭제한 브랜치에 있었던 것도,

--amend 옵션으로 다시 커밋한 것도 복구할 수 있다. 

자세한 것은 데이터 복구에서 다룬다.

하지만 커밋하지 않고 잃어버린 것은 절대로 되돌릴 수 없다.

 

 

리모트 저장소

 

리모트 저장소를 관리할 줄 알아야 다른 사람과 함께 일할 수 있다.

리모트 저장소는 인터넷이나 네트워크 어딘가에 있는 저장소를 말한다.

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

어떤 저장소는 읽기만 가능할 수 있다.

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

 

리모트 저장소를 관리한다는 것은

1. 저장소를 추가, 삭제하는 것 뿐만 아니라

2. 브랜치를 관리하고 추적할지 말지 등을 관리하는 것을 말한다.

 

 

리모트 저장소 확인하기

 

git remote 명령으로 현재 프로젝트에 등록된 리모트 저장소를 확인할 수 있다.

이 명령은 리모트 저장소의 단축 이름을 보여준다.

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

 

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

 

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

여러 사람과 함께 작업하는 리모트 저장소가 여러 개라면 아래와 같은 결과를 얻을 수도 있다.

 

 

 

이렇게 리모트 저장소가 여러 개 등록되어 있으면 다른 사람이 기여한 내용(Contributions)을 쉽게 가져올 수 있다.

어떤 저장소에는 Push 권한까지 제공하기도 하지만 일단 이 화면에서 Push 가능 권한까지는 확인할 수 없다.

 

리모트 저장소와 데이터를 주고받는데 사용하는 다양한 프로토콜에 대해서는 서버에 Git 설치하기에서 자세히 살펴보기로 한다.

 

 

리모트 저장소 추가하기

 

이정 절에서도 clone 명령을 묵시적으로 origin 리모트 저장소가 어떻게 추가되는지 설명했었지만 수박 겉핥기였다.

여기에서는 리모트 저장소를 추가하는 방법을 자세하게 설명한다. 

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

 

 

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

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

 

 

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

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

 

 

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

 

앞서 설명했듯이 리모트 저장소에서 데이터를 가져오려면 간단히 아래와 같이 실행한다.

 

$ git fetch [remote-name]

 

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

그러면 리모트 저장소의 모든 브랜치를 로컬에서 접근할 수 있어서 언제든지 Merge를 하거나 내용을 살펴볼 수 있다.

 

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

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

git fetch 명령은 리모트 저장소의 데이터를 모두 로컬로 가져오지만, 자동으로 Merge 하지 않는다. 

그래서 당신이 로컬에서 하던 작업을 정리하고 나서 수동으로 Merge 해야 한다.

 

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

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

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

 

 

리모트 저장소에 push하기

 

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

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

master 브랜치를 origin 서버에 Push하려면 아래와 같이 서버에 Push한다.

 

$ git push origin master

 

이 명령은 Clone한 리모트 저장소에 쓰기 권한이 있고,

Clone하고 난 이후 아무도 Upstream 저장소에 Push하지 않았을 때만 사용할 수 있다.

다시 말해서 Clone한 사람이 여러 명 있을 때, 다른 사람이 Push한 후에 Push하려고 하면 Push할 수 없다.

먼저 다른 사람이 작업한 것을 가져와서 Merge한 후에 Push할 수 있다.

Git 브랜치에서 서버에 Push하는 방법에 대해 자세히 설명할 것이다.

 

 

리모트 저장소 살펴보기

 

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

origin 같은 단축이름으로 이 명령을 실행하면 아래와 같은 정보를 볼 수 있다.

 

 

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

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

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

그리고 가져온 모든 리모트 저장소 정보도 출력한다.

좀 더 Git을 열심히 사용하다 보면 git remote show 명령으로 더 많은 정보를 보는 날이 온다.

 

 

리모트 저장소 이름을 바꾸거나 리모트 저장소를 삭제하기

 

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

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

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

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

 

 

 

태그

 

다른 VCS 처럼 Git도 태그를 지원한다.

사람들은 보통 릴리즈할 때 사용한다.(v1.0, 등등)

 

 

Git Alias

 

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

 

 

요약

 

이제 우리는 로컬에서 사용할 수 있는 Git 명령에 대한 기본 지식은 갖추었다.

저장소를 만들고 Clone하는 방법, 수정하고 나서 Stage하고 커밋하는 방법, 저장소의 히스토리를 조회하는 방법 등을 살펴보았다.

이어지는 장에서는 Git의 가장 강력한 기능인 Branch 모델을 살펴볼 것이다.

반응형