우리의 컴퓨터에 관리하던 프로젝트를 외부의 저장소에 업로드는 서비스에는 github, gitlab, bitbucket 등이 있다. 이는 문제가 발생했을 때 프로젝트 복구가 가능하고 협업과 동시에 버전 관리가 가능하다는 장점이 있다. 한이음에서는 gitlab을 사용하므로 gitlab 사용법에 대해 익혀볼 것이다.
URL이 가리키는 외부 서버의 프로젝트를 원격 저장소로 지정하기
👉 git remote add (name/origin) (URL)
❗ URL은 나의 깃랩 주소
내 컴퓨터의 프로젝트 디렉토리 내용을 전부 origin이 가리키는 원격 저장소의 프로젝트로 업로드
👉 git push -u origin master
❗ 깃랩의 아이디와 패스워드를 입력하는 절차를 거친 후 업로드가 진행된다.
❗ .git 디렉토리 내부엣 관리되던 Repository 영역을 업로드하기 때문에 history에 커밋을 한 기록이 모두 나타난다.
깃랩에 업로드 된 파일을 보면 README.md 파일은 내용이 바로 보이게 된다. 보통 깃랩이나 깃허브와 같은 서비스에서는 README를 해당 프로젝트에 대한 설명을 담고 있는 파일로 특수하게 인식한다. 따라서 README.md 파일에는 프로젝트의 설명을 작성한다.
깃랩 프로젝트에 새로운 커밋이 생기는 경우는 두 가지가 있다.
1. 누군가 깃랩 페이지에서 직접 커밋을 추가한 경우
2. 팀원이 깃랩 서버에서 프로젝트를 가져와서 개발을 한 후 커밋을 새로 만들고 이를 깃랩 서버에 푸시한 경우
실무에서 1번의 경우는 거의 발생하지 않는다.
origin은 근원, 기원이라는 뜻이며, 깃 세계에서 항상 근원과 기준이 되는 프로젝트는 gitlab에 존재하는 프로젝트라고 은연 중에 약속이 된다. 따라서 관습적으로 외부 저장소에 존재하는 프로젝트를 origin이라고 가리킨다. origin이라는 단어를 꼭 사용할 필요는 없지만 관습에 따라 origin으로 쓰는 것을 권장한다.
새로운 작업을 시작하기 전에는 자신의 컴퓨터에 있는 프로젝트와 깃랩 서버에 존재하는 프로젝트와 비교해서 최신의 커밋들이 지금 내가 가지고 있는 프로젝트에 포함되어 있는지 아닌지를 반드시 확인해야 한다. 이 작업을 거치지 않고 바로 자신만의 새로운 커밋을 추가하면 git push로 깃랩 서버 프로젝트에 업로드를 할 수 없게 된다. 왜냐하면, 깃랩 서버에 프로젝트가 가지고 있는 커밋 로그와 비교했을 때 그 히스토리가 다르게 생긴 커밋 로그는 충돌이 발생해서 업로드를 할 수 없게 되기 때문이다.
따라서 새로운 작업을 시작할 때, git pull을 이용해서 깃랩 서버의 커밋로그와 내 컴퓨터의 커밋 로그를 같게 한 다음 나의 작업을 수행한 뒤 git push하는 방법을 이용해야 한다.
📄출처 : ICT멘토링 git 기초강의 - 4강 Gitlab, 시작!