<13> 생활코딩 - GIT

Git - 원격 저장소의 원리

 지역 저장소와 원격 저장소가 상호 작용할 때 내부적으로 git에서는 어떤 일이 일어나는가 

 

 

git에서 파일을 만들고 내용 입력 후 add, commit하고  github에서 저장소를 만들어 준 뒤 ssh 링크를 복사한다.

다시 지역 저장소로 돌아와 원격저장소 주소를 붙여 넣기 해야하는데 그때 사용하는 명령이 remote이다. 지역 저장소 관련 기능이 모여있다. 그 뒤에 add라고 적으면 원격 저장소를 연결하겠다라는 뜻. 그 뒤의 파일이름은 연결하고자 하는 원격 저장소의 이름이고 그 이름은 뒤의 링크(ssh주소)이다.

git remote add origin [ssh주소]

이렇게 입력했을 때 내부적으로는 어떤 일이 일어나는가 살펴보자.

 

config라는 파일 하나만 수정되었다. 파일의 내용을 보면 remote "origin"이라고 적혔있는데 remote가 origin. 즉, origin이라는 remote에 대한 정보가 바로 .git의 config라는 파일에 저장되어있다.

그리고 origin의 주소는 url이다. fetch는 정보를 가져 올 때 원격 저장소 어디에서 지역저장소 어디로 가져올 것인가 이 정도로 일단을 알아두자.

 

이번에는 지역 저장소에서 지금까지 작업했던 내용을 원격저장소로 push를 해볼 것이다.

내부적으로 두 가지 일이 일어나는데 

첫번째는 지역 저장소의 마스터 브랜치를 원격 저장소 마스터 브랜치와 연결시키는 작업이 일어나고

두번째는 업로드 작업이다.

 

config파일에는 아까 없었던 내용이 또 추가 되었고 master 브랜치에 대한 정보고 지정 되었고 master브랜치는 origin에 연결된다.

origin은 위의 내용이고 그것의 주소는 url.

그리고 merge는 마스터 브랜치와 지역 저장소의 마스터 브랜치가 서로 연결 된다 라는 뜻으로 해석.

 

그리고 아까 없었던 파일이 생성. origin 이라고 하는 저장소의 마스터를 지역 저장소 마스터 브랜치와 연결시켰고 그렇게 하고 push를 했다. 그렇게 되면 위의 사진의 첫번째 박스의 정보가 추가가 되고 그 곳에는 어떤 내용이 있냐면 내가 origin으로 push한 commit이 누구인가 가 적혀있다.

 

 

다시 git으로 넘어와 log를 해보면 지역 저장소의 마스터와 그 마스터와 연결되어 있는 origin의 마스터가 같은 commit을 가리키고 있다라는 것을 보여준다.

두개의 커밋을 한 뒤 다시 log를 해보면 origin/master는 아직 커밋1 에 머물러 있다.

log를 했을 때 깃이 우리에게 이 정보를 알려 줄 수 있는 것은 

Gistory에서 refs/heads/master 에는 커밋 3의 정보가, refs/remotes/origin/master 에는 커밋1의 정보가 있기 떄문에

깃은 내부적으로 refs 밑에 있는 파일들을 통해서 origin과 지역 저장소의 차이를 우리에게 알려 줄 수 있다.

 

다시 깃으로 돌아와 git push를 해주면 Gistory에서 달라진 내용은 두 개의 파일이다.

그 중 refs/remotes/origin/master 의 내용이 이제 커밋 3의 정보를 보여주고 있다.

 

---

Git - pull VS fetch 원리

깃에서 원격 저장소에 있는 내용을 지역 저장소로 두가지의 방식이 있다.

git pull, git fetch가 있다.

 

home , office라는 저장소를 만들고 둘다 똑같은 원격 저장소와 연결되게 만든다.

그리고 office 디렉토리에 있는 부분에서 원격 저장소로 push를 계속 입력하면서 그때마다 home에서 원격 저장소에 있는 내용을 가져올 때 pull과 fetch를 둘다 사용해보면서 차이점을 알아보자.

 

먼저 office에서 f1.txt라는 파일을 만들고 내용을 입력하고 add, commit 후 push까지 처리한다.

그리고는 home에서 git pull을 하고 내부적으로 어떤 일이 일어나는지 확인해보자.

git log --decorate --all : 모든 브랜치에 대한 로그를 보여준다.

 

마스터 브랜치와 origin 마스터브랜치가 같은 커밋을 가리키는 것을 볼 수 있다.

 

Gistory에서 보면 우선 refs/heads/master  이 파일이 변경됐다.

지역저장소 마스터 브랜치가 어떤 커밋을 가리키는가를 적어놓은 이 파일이 커밋6을 정보로 갖고있고,

동시에 refs/remotes/origin/master 지역 저장소와 연결되어있는 origin 원격 저장소의 마스터 브랜치 역시 커밋6을 가르키고 있다.

( git pull을 했을 때 이렇게 됨)

 

 

다시 git으로 돌아와 office 디렉토리에 파일 내용을 수정하고 add,commit push까지 하고

home에서 pull이 아닌 git fetch를 입력하였다.

그리고는 log를 해서 보면 밑의 사진과 같은 결과가 나온다.

 

지역 저장소의 마스터 브랜치는 아까와 같이 커밋1을 가리키는데 원격저장소의 origin의 마스터는 커밋2을 가리킨다.

즉, origin 마스터가 로컬 마스터를 앞서고 있는 상황이다.

 

Gistory에서 내부적으로 어떤 일이 생겼는지 확인하면

refs/remotes/origin/master에서는 커밋7을 가리키고 

refs/heads/master에서는 커밋6을 가리킨다.

 

즉, 다운로드를 받았고 다운로드 받은 최신 커밋이 원격 저장소 몇 번인지는 기록해 놓았지만 지역 저장소 마스터 브랜치에는 어떠한 변화도 가지 않은 것이 바로 git fetch 이다.

이렇게 했을 때 좋은 점과 나쁜 점은 내가 원격 저장소로부터 지역 저장소로 가져온 다음 병합을 시키지 않고 가져오기만 하기 때문에 

원격 저장소의 내용과 지역 저장소의 마스터에 있는 내용 사이의 차이점을 비교해 볼 수가 있다.

또 코드를 확인하고 싶으면 diff를 통해서 하면 되고 지역 저장소의 HEAD(=현재마스터)의 최신커밋과 origin/master 사이의 차이점을 비교해볼 수 있다.

git diff HEAD origin/master

이상이 없는 것을 확인하고 git merge origin/master을 하고

log를 해보면

같은 커밋을 가리키고 있다.

 

 

git fetch

원격 저장소로부터 필요한 파일들을 다운로드 받는다. 여기서 끝나기 때문에 git merge를 해줘야 한다.

git pull

필요한 파일 다운로드 받고 병합까지 해준다.