서버 저장소는 다른 말로 원격(remote)저장소라고도 합니다. 서버 저장소는 로컬 저장소의 코드를 복제한 복사본이라고도 할 수 있습니다.
깃은 여러 개발자와 협업하려고 탄생한 도구입니다.
여러명이 같이 협업하여 개발한다면 적은 시간으로 좀 더 좋은 품질의 소프트웨어를 만들 수 있습니다.
깃은 이 두 가지 환경을 고려하여 분산형 모델을 선택했습니다.
깃은 분산된 저장소 여러 개를 하나로 통합하고, 최신 코드를 배포할 수 있습니다.
서버 저장소는 여러 컴퓨터에 동일한 깃 저장소를 복제하고, 작업한 결과물을 다시 서버로 통합합니다.
깃의 분산형 관리 체계는 다수의 사람과 협업하는 데 매력적입니다.
기존 프로젝트에 새로운 멤버가 참여할 때, 지금까지 작업한 소스 코드의 마지막 버전을 공유해야 합니다.
독립적인 깃 서버를 직접 운영하여 사용할 수 있습니다.
직접 서버를 운영하지 않아도 전문적인 깃 호스팅으로 서버를 대체할 수 있습니다.
호스팅을 받으면 직접 서버를 관리하지 않아도 쉽게 원격 저장소를 운영할 수 있습니다.
깃허브는 대표적인 깃호스팅 서비스입니다. 깃허브의 모든 서비스는 무료로 사용할 수 있습니다.
일반적으로 개별 깃허브 주소는 다음과 같이 표현합니다.
공개용 저장소는 무제한으로 생성해서 사용할 수 있습니다.
비공개용 저장소는 제약이 조금 있고, 일부는 유료 서비스입니다.
저장소 구성은 다음과 같이 URL을 이용하여 표기합니다.
한 소유자 안에서 같은 저장소 이름은 중복하여 생성할 수 없습니다.
저장소를 생성할 때 README 체크 여부에 따라 달라집니다. README를 체크하지 않으면 초기화 및 복제 방법을 안내합니다.
원격 저장소에 연결하려면 먼저 로컬 저장소가 있어야 합니다. 로컬 저장소를 원격 저장소에 연결하는 방법은 크게 두 가지입니다.
- 새로운 로컬 저장소를 생성하고 원격 저장소를 연결하는 방법
- 기존 저장소를 연결하는 방법
- 먼저 새 로컬 저장소를 생성하고 초기화합니다.
$ mkdir gitstudy05
$ cd gitstudy05
$ git init
Initialzed empty Git repository in E:/gitstudy05/.git/
- 파일을 생성합니다.
$ echo "# gitstudy05" >> README.md
- add를 이용해 스테이지에 등록하고 commit을 이용해 커밋합니다.
$ git add README.md
$ git commit -m "first commit"
Local(로컬)
로컬 컴퓨터에 원격 저장소를 생성하는 것을 의미합니다.
이 방식은 자신의 컴퓨터를 NFS(Network File System) 등 서버로 이용할 때 편리합니다.
로컬 저장소를 서버로 이용할 때는 폴더 경로만 입력하면 됩니다.
$ git remote add 원격저장소별칭 폴더경로
로컬은 간단하게 원격 서버를 구축할 수 있을 뿐만 아니라 빠른 동작이 가능합니다.
하지만 모든 자료가 자신의 컴퓨터에 집중되는 위험도 있습니다.
HTTP
깃은 HTTP 방식의 프로토콜을 지원합니다. HTTP는 SSH처럼 많이 사용하는 프로토콜 중 하나입니다.
깃허브, 비트버킷 같은 호스팅 서비스도 기본 HTTP 프로토콜을 지원합니다.
서버에 접속하려면 로그인 절차를 거쳐야 합니다. HTTP는 기존 아이디와 비밀번호만으로 접속자를 인증, 처리할 수 있습니다.
HTTP는 익명으로도 처리할 수 있으며, 계정을 이용하여 처리할 수도 있습니다.
SSH
SSH는 깃에서 권장하는 프로토콜로, 높은 수준의 보안 통신으로 처리하기 때문에 깃 서버를 좀 더 안전하게 운영할 수 있습니다.
SSH 프로토콜을 사용하려면 주소 앞에 'ssh://계정@주소'처럼 프로토콜 타입을 지정해야 합니다.
계정을 생략하여 현재 로그인된 사용자로 대체할 수도 있습니다.
SSH 접속을 할 때는 인증서를 만들어 사용합니다. 인증서를 만들어 접속하면 별도의 회원 로그인 절차를 거치지 않아도 됩니다.
인증서는 공개키와 개인키로 구분하는데 공개키는 서버에 등록하며, 개인키는 로컬에 저장합니다.
SSH는 HTTP와 달리 익명으로 접속할 수 없습니다. 이러한 점이 기업에서 깃 서버를 운영할 때 적합한 프로토콜이라고 할 수 있습니다.
Git
Git 프로토콜은 깃의 데몬 서비스를 위한 전용 프로토콜 방식을 의미합니다. SSH와 유사하지만 인증 시스템이 없어 보안에 취약할 수 있습니다.
실제로 이 프로토콜은 잘 사용하지 않는 편입니다.
remote 명령어를 독립적으로 사용하면 연결된 원격 저장소의 이름(별칭)을 출력합니다.
$ git remote
-v 옵션을 같이 사용하면 원격 저장소의 별칭 이름과 URL을 확인할 수 있습니다.
$ git remote -v
깃은 복수의 원격 저장소를 연결하여 사용할 수 있습니다. 리모트 저장소가 여러 개 있을 때는 목록을 모두 출력합니다.
하지만 저장소의 권한 정보까지는 알 수 없습니다.
로컬 저장소에 원격 저장소(서버)를 등록하려면 서버 주소가 필요합니다.
깃허브 같은 저장소를 이용해 보면 프로토콜 + 도메인 주소 형태로 된 것을 알 수 있습니다.
로컬에 서버 저장소를 생성할 때는 폴더 경로를 사용할 수 있습니다.
-
별칭: 원격 서버의 주소는 긴 문자열로 되어 있습니다. 간략하게 긴 서버 URL 문자열을 별칭으로 만들어 사용할 수 있습니다.
-
origin: origin은 대표적으로 사용하는 별칭입니다.
원격 저장소와 연결하려면 add 옵션을 사용합니다.
$ git remote add 원격저장소별칭 원격저장소URL
원격 저장소를 추가할 때는 인자 값으로 원격 저장소 별칭과 원격 저장소의 URL을 같이 입력합니다.
infoh@hojin MINGW64 /e/gitstudy05 (master)
$ git remote add origin https://github.com/jinygit/gitstudy05.git ---------- 자신의 서버 주소를 입력
infoh@hojin MINGW64 /e/gitstudy05 (master)
$ git remote -v ---------- 원격 저장소 목록 확인
origin https://github.com/jinygit/gitstudy05.git (fetch)
origin https://github.com/jinygit/gitstudy05.git (push)
원격 저장소가 연결되면 fetch와 push 두 주소를 출력합니다.
push는 서버로 전송하는 동작을 의미하고, fetch는 반대로 서버에서 가지고 오는 동작을 의미합니다.
별칭은 중복하여 선택할 수 없습니다.
원격 저장소를 등록하면 기존 master 브랜치와 달리 또 하나의 브랜치가 표시됩니다.
master는 현재 로컬 저장소를 의미합니다. 그리고 local/master 같은 별칭/브랜치는 원격 저장소의 브랜치를 의미합니다.
즉, 로컬 저장소와 서버 저장소를 구분하여 표시합니다. 이것으로 서로 동기화한 시점을 판별할 수 있습니다.
Note : 브랜치 개념은 나중에 다시 자세히 설명합니다. 원격 저장소를 등록하면 원격 브랜치가 자동 생성된다는 것만 알고 넘어갑시다.
별칭은 긴 문자열의 서버 주소를 대체합니다. 등록된 서버의 별칭 이름은 다시 변경할 수 있습니다.
rename 옵션을 같이 사용합니다.
$ git remote rename 변경전 변경후
remote 명령어는 간략한 원격 저장소 정보만 출력합니다.
$ git remote show 원격저장소별칭
다음과 같이 remote show 명령어를 실행하면 상세한 정보를 출력합니다.
infoh@hojin MINGW64 /e/gitstudy05 (master)
$ git remote show origin
* remote origin
Fetch URL: https://github.com/jinygit/gitstudy05.git
Push URL: https://github.com/jinygit/gitstudy05.git
HEAD branch: master
Remote branch:
master tracked
Local ref configured for 'git push':
master pushes to master (up to date)
로컬 저장소는 복수의 원격 저장소와 연결할 수 있습니다.
깃을 사용하다 보면 풀 리퀘스트(pull request), 테스트 등 목적으로 임시 등록된 원격 저장소들도 있습니다.
등록된 원격 저장소는 rm옵션으로 삭제할 수 있습니다.
$ git remote rm 원격저장소별칭
이처럼 등록, 변경, 삭제하여 다수의 원격 저장소를 관리할 수 있습니다.
push를 통하여 원격 저장소로 커밋된 파일을 업로드하여 봅시다.
푸시를 하기 전에 아래의 명령어로 원격 저장소와 연결된 서버 목록을 확인해 봅시다.
$ git remote -v
원격 저장소가 잘 연결되어 있다면 아래 명령어를 통해 푸시를 합니다.
$ git push origin main
origin --> 원격 저장소 별칭, main(내지는 master) --> 브랜치의 이름
그 후 푸시(push)가 성공적으로 완료되었다면 github에 접속하여 저장소에 업로드가 되었는지 확인해 봅시다.
이렇듯 git과 github을 활용하여 협업과 백업 용도 등으로 유용하게 사용할 수 있습니다.
clone 명령어는 원격 저장소에 있는 파일을 로컬 저장소로 복제하는 명령어입니다.
$ cd 메인 폴더
$ mkdir gitstudy05_clone // 복제할 새 폴더 만들기
$ cd gitstudy05_clone
$ git clone https://github.com/jinygit/gitstudy05.git // 복제할 저장소의 url 입력
위에서 클론할 때에 적은 주소는 예시용이며, 실제로는 자기가 클론하고자 하는 저장소의 url을 기입해야 합니다.
클론이 성공적으로 완료되었다면 아래 명령어로 파일과 원격 저장소 목록을 확인해 보세요.
$ ls -al
$ git remote -v
clone 통한 복제 말고도 해당 저장소로 가서 직접 zip 파일로 다운로드 받을 수도 있습니다.
pull 명령어는 원격 저장소의 갱신된 내용을 로컬 저장소로 내려받는 명령어입니다. 주기적으로 사용하여 최신 커밋 정보를 로컬 저장소로 유지할 수 있습니다.
$ git pull
pull이 성공적으로 완료되었다면 git log를 통해 갱신된 내용이 잘 반영되었는지 확인해보세요.
병합은 원격 서버 파일과 로컬 파일을 하나로 합치는 과정입니다. 혼자하는 프로젝트는 pull 명령어로도 편리하게 사용 가능합니다. 하지만 여러 사람이 같이 참여하는 프로젝트는 pull 명령어가 자동으로 병합하지 못하고 충돌이 발생하기도 합니다. 그럴 때에는 페치(fetch) 방식을 사용해야 합니다.
fetch는 원격 저장소에서 코드를 수동으로 내려받는 작업을 합니다. pull과 달리 fetch는 내려받은 후 현재 브랜치와 자동 병합하지 않습니다.
수정된 파일을 커밋 후 원격 저장소로 옮긴 다음 아래 명령어를 입력합니다.
$ git fetch 원격저장소url
fetch가 성공적으로 완료되었다면 git log를 통해 pull과의 차이점을 비교해 보세요. fetch는 pull 명령어와 달리 커밋이 추가된 것을 확인할 수 없습니다. 이것은 원격 저장소의 커밋들만 가지고 왔을 뿐 로컬 저장소에서 아무런 작업도 하지 않았다는 것을 의미합니다.
merge 명령어는 fetch로 자동 병합 되지않았던 브랜치를 수동으로 병합하는 명령어입니다.
$ git merge 원격저장소별칭/브랜치이름
예를 들어 원격 저장소별칭이 "origin"이고, 브랜치 이름이 "main" 이라면
$ git merge origin/main
위 명령어 형태로 사용하시면 됩니다. 그 후 git log를 통하여 로컬 저장소의 커밋 기록을 확인하면 fetch로 내려받은 커밋이 추가된 것을 확인할 수 있습니다.
원격 저장소에는 다수의 개발자가 동시에 커밋을 푸시할 수 없습니다. 여러 명이 협력해서 개발할 때는 순차적으로 푸시해야 합니다.
원격 저장소에 푸시하려면 자신의 로컬 저장소를 최신 상태로 유지해야 합니다. 커밋이 순차적이지 않을 때 깃은 푸시 동작을 거부합니다. 푸시 동작이 거부되면 풀 또는 페치 작업으로 자신의 로컬 저장소를 갱신해 주어야 합니다. 갱신 후에 다시 푸시합니다.
깃이 최신 상태에서만 푸시를 허용하는 것은 충돌을 방지하기 위해서입니다. 원격 저장소의 커밋을 내려받는 풀 작업은 내려받은 커밋들을 현재 브랜치로 자동 병합합니다. 이때 커밋 내용이 순차적이지 않으면 병합 과정에서 충돌이 발생합니다. 최대한 충돌을 피할 수 있는 방법은 자신의 저장소와 원격 저장소의 상태를 자주 최신으로 유지하는 것입니다. 다음의 순서와 같이 작업하면 충돌을 줄일 수 있습니다.
pull → coding → commit → pull → push
깃은 서버 역할을 수행하는 원격 저장소와 커밋 정보들을 주고받습니다. 원격 저장소에 커밋 코드를 전송하거나 추가된 커밋들을 내려받을 수 있고 불특정 다수를 대상으로 공유할 수도 있습니다. 또한 깃과 공개된 원격 저장소를 사용해 오픈 소스는 수많은 사람과 협업할 수 있는 장점들을 제공합니다. 그렇기 때문에 깃은 오픈 소스를 활성화하는 데 가장 많은 기여를 하는 협업 툴이 되었습니다.