원격(서버) 저장소는 로컬 저장소의 코드를 복제한 복사본이라고 할 수 있다. 서버를 이용하면 코드를 안전하게 보관할 수 있고, 또 서버에 있는 소스 코드는 다른 사람들과 공유하고 협업하여 개발을 진행할 수도 있다. 원격 저장소가 있다면 언제 어디에서든지 개발을 이어 할 수 있다. 사무실에서 개발 중인 코드를 서버에 저장하고, 집에 와서는 사무실에서 작업하고 서버에 올린 코드를 자신의 컴퓨터에 동기화할 수 있다. 이처럼 사무실, 집, 다른 여러 컴퓨터에 코드를 동기화하고 연속된 작업을 이어 갈 수 있다. 깃은 분산된 저장소 여러 개를 하나로 통합하고, 최신 코드를 배포할 수 있다. 서버 저장소는 여러 컴퓨터에 동일한 깃 저장소를 복제하고, 작업한 결과물을 다시 서버로 통합한다.
원격 저장소로는 깃허브를 골랐다. 우선 깃허브에서 repository를 선택해서 생성한다.
원격 저장소에 연결하려면 먼저 로컬 저장소가 있어야 한다. 로컬 저장소를 원격 저장소에 연결하는 방법은 크게 두 가지다.
- 새로운 로컬 저장소를 생성하고 원격 저장소를 연결하는 방법
- 기존 저장소를 연결하는 방법
1번으로 진행하자. 먼저 폴더를 만들고 git init명령어로 저장소를 깃으로 초기화한다. 그럼 로컬 저장소가 생겼다. 그리고 파일을 만들어서 스테이지에 등록하고 첫 번째 커밋을 만든다. 이제 로컬 저장소와 원격 저장소를 연결해보겠다.
서버와 통신하려면 프로토콜을 사용해야 한다. 깃은 서버와 통신할 수 있는 다양한 프로토콜을 지원한다. 깃은 기본적으로 HTTP, Local, SSH, Git 네 종류의 전송 방식을 지원한다.
- Local - 로컬 컴퓨터에 원격 저장소를 생성하는 것을 의미한다. 이 방식은 자신의 컴퓨터를 NFS 등 서버로 이용할 때 편리하다. 로컬 저장소를 서버로 이용할 때는 폴더 경로만 입력하면 된다. git remote add 원격 저장소 별칭 폴더 경로 로컬은 간단하게 원격 서버를 구축할 수 있을 뿐만 아니라 빠른 동작이 가능하다. 하지만 모든 자료가 자신의 컴퓨터에 집중되는 위험도 있다.
- HTTP - HTTP는 SSH처럼 많이 사용하는 프로토콜 중 하나이다. 서버에 접속하려면 로그인 절차를 거쳐야 한다. HTTP는 기존 아이디와 비밀번호만으로 접속자를 인증하여 처리할 수 있다. HTTP는 익명으로도 처리할 수 있으며, 계정을 이용하여 처리할 수도 있다.
- SSH - 깃에서 권장하는 프로토콜로, 높은 수준의 보안 통신으로 처리하기 때문에 깃 서버를 좀 더 안전하게 운영할 수 있다. SSH 프로토콜을 사용하려면 주소 안에 'ssh://계정@주소'처럼 프로토콜 타입을 지정해야 한다. 계정을 생략하여 현재 로그인된 사용자로 대체할 수도 있다. SSH 접속을 할 때는 인증서를 만들어 사용한다. 인증서를 만들어 접속하면 별도의 회원 로그인 절차를 거치지 않아도 된다. 인증서는 공개키와 개인키로 구분하는데 공개키는 서버에 등록하며, 개인키는 로컬에 저장한다.
- Git - Git 프로토콜은 깃의 데몬 서비스를 위한 전용 프로토콜 방식을 의미한다. SSH와 유사하지만 인증 시스템이 없어 보안에 취약할 수 있다. 실제로 이 프로토콜은 잘 사용하지 않는 편이다.
깃은 원격 저장소(서버)를 관리하는데 remote 명령어를 사용한다. remote 명령어를 사용하면 현재 연결된 원격 저장소 목록을 확인할 수 있고, 등록과 취소 등 작업도 진행할 수 있다. remote 명령어는 원격 저장소의 이름(별칭)을 출력한다.
-v 옵션을 같이 사용하면 원격 저장소의 별칭 이름과 URL을 확인할 수 있다.
git remote -v
로컬 저장소에 원격 저장소(서버)를 등록하려면 서버 주소가 필요하다. 깃허브 같은 저장소를 이용해 보면 프로토콜 + 도메인 주소 형태로 된 것을 알 수 있다. 로컬에 서버 저장소를 생성할 때는 폴더 경로를 사용할 수 있다.
별칭은 간략하게 긴 서버 URL 문자열을 별칭으로 만들어 사용. (origin이 많이 사용하는 별칭)
이제 원격 저장소와 연결해보겠다. 원격 저장소와 연결하려면 add 옵션을 사용한다.
git remote add 원격저장소 별칭 원격저장소 URL
원격 저장소에 연결되면 fetch와 push 두 주소를 출력한다. push는 서버로 전송하는 동작을 의미하고, fetch는 반대로 서버에서 가지고 오는 동작을 의미한다. (원격 저장소를 등록하면 원격 브랜치가 자동 생성된다)
별칭은 긴 문자열의 서버 주소를 대체한다. 등록된 서버의 별칭 이름은 다시 변경할 수 있다. rename 옵션을 사용.
remote 명령어는 간략한 원격 저장소 정보만 출력한다. 원격 저장소의 좀 더 상세한 정보를 확인하고 싶다면 show 옵션을 같이 사용한다. 등록된 원격 저장소는 rm 옵션으로 삭제가 가능하다
git remote rename 변경전 변경후
git remote show 원격저장소별칭
git remote rm 원격저장소별칭
push는 원격 저장소로 커밋된 파일들을 업로드하는 동작이다.
git push 원격저장소별칭 브랜치이름별칭 이름을 가지는 서버의 master 브랜치에 현재 브랜치를 업로드한다. 브랜치는 다음에 알아보겠다.
이번에는 반대로 원격 저장소에서 커밋된 코드를 내려받는 방법을 알아보자.
복제는 기존 저장소를 이용하여 새로운 저장소를 생성하는 방법 중 하나이다. 하지만 일반적인 복제와 원격 저장소를 복제하는 방법은 조금 차이가 있다. 몇 가지 추가 정보를 같이 설정해야 한다. 복제할 때는 clone 명령어를 사용한다. clone 명령어는 초기화 init 명령어 외에 원격 서버 접속에 필요한 추가 설정을 자동으로 수행한다. 서버의 연결 설정을 마친 후 서버 안에 있는 모든 커밋된 코드 이력들을 한 번에 내려받는다.
git clone 원격저장소 URL
복제는 원격 저장소에서 모든 내용을 한 번에 내려받는다. 복제 후 원격 저장소의 갱신된 내용을 추가로 내려받으려면 pull 명령어를 사용해야 한다.
pull 명령어는 로컬 저장소보다 최신인 갱신된 원격 저장소의 커밋 정보를 현재 로컬 저장소로 내려받는다. pull 명령어를 주기적으로 사용하면 최신 커밋 정보로 로컬 저장소를 유지할 수 있다.
git pull 원격저장소별칭 가져올 브랜치 이름
pull 명령어 말고 fetch로 원격 저장소 내용을 가져올 수 있다. 이 두 방법의 차이는 병합을 자동 처리하는지 여부다. 병합에 대해서는 이후에 다루겠다.
풀은 원격 서버에서 현재 커밋보다 더 최신 커밋 정보가 있을 때 내려받는다. 내려받은 커밋 정보는 임시 영역에 저장한다. 스테이지 영역이 아닌 원격 저장소를 위한 전용 임시 브랜치가 따로 있다. 내려받은 최신 커밋들을 현재 브랜치로 자동으로 병합 처리한다. 여기서 병합은 원격 서버 파일과 로컬 파일을 합치는 과정이다. 이때 여러 개발자와 협업하면 코드를 작성할 때 pull 명령어를 사용하면 충돌이 발생할 수 있다. 이처럼 pull 명령어를 못 쓸 때 fetch 방식을 사용한다.
git fetch
fetch는 원격 저장소에서 코드를 수동으로 내려받는 작업이다. fetch는 원격 저장소에서 커밋된 코드를 임시 브랜치로 받는다. 내려받은 후 현재 브랜치와 자동 병합하지 않는다.
fetch로 가져온 데이터들을 병합하려면 merge 명령어로 수동 병합해야 한다. 아래 명령어를 입력하면 수동 병합된 코드들을 확인할 수 있다.
git merge 원격저장소별칭/브랜치이름
(ex git merge origin/master)
먼저 원격 저장소에 푸시하려면 자신의 로컬 저장소를 최신 상태로 유지해야 한다. 즉, 자신의 저장소가 원격 저장소의 커밋보다 최신이어야 한다. 더 자세히 알아보자. 누군가 내 저장소보다 먼저 커밋하여 새로운 커밋으로 서버를 갱신했다. 하지만 본인은 간발의 차이로 갱신된 서버 정보를 가지고 있지 않다. 이러면 내 커밋은 서버의 최신 커밋보다 늦은 커밋으로 밀리게 된다. 커밋이 순차적이지 않을 때 깃은 푸시 동작을 거부한다. 이는 충돌을 방지하기 위해서다. 원격 저장소의 커밋을 내려받는 풀 작업은 내려받은 커밋들을 현재 브랜치로 자동 병합한다. 이때 커밋 내용이 순차적이지 않으면 병합 과정에서 충돌이 발생한다. 앞서 누가 먼저 간발의 차이로 푸시를 했다면 나는 pull 명령어로 업데이트한 후 푸시를 할 수 있다.
풀과 푸시를 자주하여 충돌을 최소한으로 줄여 나가면서 작업을 유지해야 한다.
권장 순서
pull -> coding -> commit -> pull -> push
댓글