Github(원격저장소 remote repository) : remote, push, fetch, pull, pr

github : 원격 저장소(remote repository) : remote, push, fetch, pull, pull request

 이제는 가장 처음의 Git 의 전반적인 구성에서 그렸던 그림이 변화될 시점이다. 합류하게 될 프로젝트는 어떤 remote repository에 기록되어 있을텐데, 작업할 컴퓨터에는 프로젝트에 대한 어떤 정보도 없을 것이다. 물론 개발한 내용을 올리고 merge도 해야하는 입장이기 때문에 함께 프로젝트에 참여할 수 있어야한다. 이럴 때 remote repository를 작업 컴퓨터에 clone (복사) 한다. 변경된 내용이 있다면 repository를 또다시 clone하는 것이 아니라 local로 pull 해올 수 있고, 반대로 작업한 내용을 remote repository쪽으로 push 할 수도 있다. pull은 fetch와 merge 작업을 동시에 한다고 생각하면 되는데, fetch는 업데이트 된 내용을 받아오는 작업이고 merge는 그것들을 합치는 작업이다.

 

>>> git clone repository-주소

 작업 컴퓨터로 clone해오는 방법은 간단하다. 우선 clone하고 싶은 repository를 github에서 찾아 들어간 후, 위 이미지와 같은 화면에서 빨간색 box로 표시된 'Code' 를 클릭한다. 첫 번째로 해당 repository의 주소를 복사해서 clone 명령어를 이용하는 방법이 있고, 두 번째로 현재 상태 그대로의 파일을 직접 다운받는 방법이 있다. 첫 번째 방법은 저장소 째로 복사되기 때문에 버전관리가 되지만, 두 번째 방법은 파일만 가져오는 것이기 때문에 따로 버전관리가 되지 않는다는 점을 기억하자.

 

>>> git remote add origin 저장소 링크

>>> git push -u origin main(master)

 하지만 repository를 새로 만들었다면 이런 화면을 보게 된다. 권장하는대로 그대로 진행하면 된다. 중요한 부분은 code block으로 작성한 두 가지이다. 이때 'origin' 으로 표기한 곳은 저장소 master branch의 이름이니까 마음대로 하면 된다고 하며, 보통 최초이면 origin이라고 명명한다고 한다. 그리고 main과 병기한 master는 local의 branch 위치이며, origin에 main(master) branch를 올리겠다는 명령어가 push이다. 때문에 local의 branch의 이름을 명확하게 알고 작성한다.

 

 직접 수행해보면 파일을 올리는 작업을 수행했음을 보여주는 과정이 terminal에 나오고, github repository에서 확인해보면 기존에 설명이 나와있던 페이지 대신에 local에서 작업하던 repository가 올라가있음을 볼 수 있다. 이 push는 local repository가 앞서있는 경우 remote repository에 내용을 올리는 명령어였다. 그렇다면 반대로 local보다 remote가 앞서있는 경우는 어떻게 할까?

 

>>> git fetch origin

 local 보다 remote가 앞설 때는 fetch 명령어를 사용해서 remote에서 local로 변경사항을 받아오는데, history를 확인했을 때 local의 master와 origin의 master가 서로 다른 것을 확인할 수 있다. 받아와서 history를 살펴보면 원래는 없던 commit이 추가되어 있는 것을 확인할 수 있다.

 

 fetch 후 local의 master branch로 checkout해서 origin/master를 merge하게 되면 local과 remote의 master가 일치된 것을 history를 통해 확인할 수 있다. 그리고 이 fetch와 merge 작업을 동시에 수행하는 것이 pull이다.

 

>>> git pull

 하지만 pull 명령어로 양측의 작업 단계를 일치시키려고 하더라도 merge 중에 오류가 날 수 있다. 이럴 때는 충돌을 해결하고 난 후, add와 commit의 단계를 거치면 된다고 한다.

 

 local과 remote의 작업 단계가 일치한다면 fetch나 pull 명령어를 사용했을 때 별다른 메시지를 볼 수 없다. 체크된 것처럼 up to date, 최신 상태라는 메시지를 확인할 수 있다.

 

 이렇게 push와 pull을 하면서 작업 단계를 일치시켜나가는데, 이때 주의해야할 점이 있다. 우선 둘 다 push를 하려고 한다면 충돌이 발생할 것이다. 한쪽이 push를 하는 바람에 작업 단계가 뒤쳐졌다면 일단 merge를 수행한 후에 push 해야한다.

 

 작업하는 내용이 업데이트 되는 repository가 작업자의 repository가 아니라면 어떨까? 다른 사람이 수행한 어떤 프로젝트에 대한 repository를 Github에서는 작업자의 컴퓨터로 clone 해오기 전에 나의 계정으로 fork 할 수 있다. 그리고 그 fork 해온 repository를 작업자의 컴퓨터에 clone 하는 것이다. 이 경우에는 기존 작업자의 repository에 대한 작업이 아니게 된다. 그런데 fork 해와서 작업하다보니 보다 좋은 아이디어가 생각나서 수정을 한 상황이라고 생각해보자. 그런데 이 경우는 작업자에게 원래 repository에 대한 접근 권한이 없다. 이럴 때 사용하는 것이 pull request이다.

 Github에서 pull request를 하게되면 repository에 권한이 있는 사람이 이를 검토할 수 있게되고, 그 승인 여부에 따라 적용되고 되지 않고가 갈리게 된다.

 

 혹은 애초부터 settings > Access > Collaborators > Manage access 를 통해 작업하는 repository에 대한 접근 권한을 설정하여 함께 협업할 사람을 추가할 수도 있다.

 

 혹시라도 remote repository로 push 작업 등이 정상적으로 되지 않는다면 '제어판 - 사용자 계정 - 자격 증명 관리 - Windows 자격증명' 부분을 참고한다. 아마도 github 계정 문제가 있을 것이다.

 

>>> git gui (&)

 GUI는 Graphic User Interface의 약자로, git으로 작업한 working tree를 terminal이 아닌 interface로 작업할 수 있도록 창을 열어준다. 그리고 상단 'Repository' tab에 'Visualize All Branch History' 를 클릭하면 그동안의 commit history를 볼 수 있다. 만약 바로 확인할 수 없다면 상단의 File tab에서 update를 눌러준다. 연두색은 master branch pointer, 파란색은 HEAD cursor이다.

 하지만 그냥 이렇게 작성하면 기존에 사용하고 있던 terminal을 쓸 수 없게 되는데, terminal에서 계속 작업하면서 이 GUI를 사용하고 싶다면 '&'를 붙여서 실행하면 된다. 이는 새로 process를 할당해주는 개념이라고 했다. 수업 중 따로 이 GUI에 대해 실습해보지는 않았다.

 

 GUI로 보는 방법도 있지만 visual studio code를 사용해서도 볼 수 있다. U는 untracked file, M은 modified file, A는 added file을 의미한다. 좌측 하단의 네모 박스로 표기한 것을 누르면 아래 이미지와 같이 terminal에서 보던 staging area를 시각적으로 볼 수 있고, 하단에서 어떤 commit들이 있는지, 파일의 변경 history는 어떤지, 어떤 branch들이 있는지 등등의 내용을 확인할 수 있다.

 

 

 이외에도 Sourcetree를 사용하는 방법도 있다. Sourcetree는 편리해서 많이 사용한다고 하는데, 물론 terminal에서 Git을 동작하는 것이 모든 기능을 제공하기 때문에 가장 강력하다고 할 수 있다.