GitLab이란: GitHub와의 차이, clone, push, 머지 리퀘스트, CI/CD 사용법

GitLab이란

GitLab은 Git 저장소를 보관하고, 그 주변에서 팀 작업이 이루어지도록 돕는 플랫폼입니다. 코드 보기, 머지 리퀘스트(변경 사항의 병합을 요청하는 기능), 이슈 관리, 위키, 컨테이너 레지스트리, 통합 CI/CD를 제공합니다. 간단히 말해, "자체 빌드 파이프라인이 있고 내 서버에 설치할 수 있는 GitHub"라고 할 수 있습니다. 많은 기업, 특히 국내외 기업들이 사내 네트워크에 구축한 GitLab에서 코드를 관리합니다.

이 프로젝트는 2011년에 코드 호스팅 오픈소스 애플리케이션으로 시작했고, 이를 중심으로 GitLab Inc.라는 회사가 생겼습니다. 플랫폼은 두 가지 형태로 제공됩니다. 무료로 자체 서버에 설치할 수 있는 오픈소스 버전인 Community Edition과, 유료 기능을 포함한 Enterprise Edition입니다. 클라우드 서비스 gitlab.com에는 Free, Premium, Ultimate 요금제가 있습니다.

용어를 혼동하지 마세요. Git은 버전 관리 시스템이며, 여러분의 컴퓨터에서 실행되는 프로그램입니다. GitLab은 원격 저장소를 보관하고, 팀을 위한 인터페이스와 도구를 덧붙이는 서비스입니다. GitLab이 없어도 Git은 쓸 수 있지만, Git 없이는 GitLab을 제대로 사용할 수 없습니다.

Git과 GitLab의 차이

"git과 gitlab은 무엇이 다른가요?"라는 질문은 채용 공고나 입사 첫날에 두 단어를 모두 보게 될 때 자주 생깁니다. 차이는 문서 편집기와 클라우드 저장 공간의 관계와 비슷합니다. Git은 파일의 변경 사항을 추적하고, 커밋 기록과 브랜치를 로컬에서 관리합니다. GitLab은 그 기록을 네트워크로 받아 브라우저에 보여 줍니다.

커밋, 브랜치, 병합 같은 코드 작업은 여전히 Git으로 합니다. GitLab은 git push로 결과를 받아 두고, 동료와 그 결과를 논의할 수 있게 해 줍니다.

GitLab과 GitHub의 차이

GitLab과 GitHub는 모두 Git 저장소를 보관하고 코드 리뷰를 지원합니다. 그래서 기본 기술은 그대로 옮겨 쓸 수 있습니다. 차이는 중점과 배포 모델에 있습니다.

실제로는 둘 다 쓰는 개발자도 많습니다. 개인 프로젝트와 포트폴리오는 GitHub에, 회사 업무 코드는 사내 GitLab에 두는 식입니다. Git 명령은 같고, 바뀌는 것은 원격 저장소의 주소뿐입니다.

gitlab.com 또는 자체 서버(self-hosted)

클라우드 서비스 gitlab.com은 개인 프로젝트나 소규모 팀에 적합합니다. 가입하면 바로 저장소를 만들 수 있습니다. 업데이트, 백업, 가용성은 GitLab이 관리합니다. 무료 요금제의 제한(멤버 수, CI 실행 시간, 저장 용량)은 가끔 바뀌므로, 최신 조건은 요금제 페이지에서 확인하세요.

Self-hosted GitLab은 기업이 자체 서버에 Linux 패키지, Docker, Kubernetes 중 하나의 방식으로 설치합니다. 코드가 사내 네트워크 밖으로 나가지 않고, LDAP로 사내 로그인을 연동할 수 있으며, 빌드용 러너도 직접 구성할 수 있습니다. 대신 업데이트와 백업은 관리자가 책임져야 합니다. 개발자에게 체감되는 차이는 거의 없습니다. 주소가 gitlab.com이 아니라 예를 들어 gitlab.company.ru 같은 형태가 될 뿐입니다.

GitLab 사용을 위한 Git 설정

첫 커밋 전에 이름과 이메일을 설정하세요. 이 값은 기록에 남고, GitLab은 이메일을 기준으로 커밋을 여러분의 프로필과 연결합니다.

git config --global user.name "Ivan Petrov"
git config --global user.email "ivan@example.com"

Windows에서는 Git for Windows에 포함된 Git Bash를 쓰면 편리합니다. ssh-keygen도 함께 설치되므로, 이 글의 명령은 Git Bash에서 그대로 실행됩니다. 다음으로 로그인 방법을 고르세요. 토큰을 쓰는 HTTPS 방식이나 SSH 키 방식 중 하나입니다.

HTTPS로 로그인하기: personal access token

HTTPS로 Git을 쓸 때는 계정 비밀번호를 쓰지 마세요. 2단계 인증을 켜 두었다면 비밀번호는 동작하지 않습니다. 대신 GitLab의 프로필 설정(Access tokens 섹션)에서 personal access token을 만듭니다. 코드 작업에는 read_repository와 write_repository 권한이면 충분합니다. 만료 기간을 정하고, 토큰은 바로 저장하세요. 다시 보여 주지 않습니다.

처음 push나 clone을 할 때 Git이 아이디와 비밀번호를 묻습니다. 아이디에는 GitLab 사용자 이름을, 비밀번호 자리에는 토큰을 입력하세요. Git for Windows에 포함된 자격 증명 관리자가 이를 기억하므로, 다시 입력할 필요가 없습니다.

SSH 키로 로그인하기

SSH는 일상적인 작업에 더 편리합니다. 키를 한 번 등록하면 더 이상 아무것도 입력할 필요가 없습니다.

ssh-keygen -t ed25519 -C "ivan@example.com"
cat ~/.ssh/id_ed25519.pub

공개 키(.pub 파일)의 내용을 GitLab 프로필 설정의 SSH Keys 입력란에 붙여 넣으세요. 연결을 확인하려면 다음 명령을 씁니다.

ssh -T git@gitlab.com
Welcome to GitLab, @ivan.petrov!

GitLab에서 git clone하는 방법

프로젝트 페이지에는 SSH와 HTTPS 주소가 함께 보이는 Code 버튼이 있습니다. 원하는 주소를 복사해서 git clone을 실행하세요.

# HTTPS로
git clone https://gitlab.com/my-group/my-project.git

# SSH로
git clone git@gitlab.com:my-group/my-project.git

GitLab의 프로젝트 경로에는 하위 그룹이 포함될 수 있습니다. 예를 들어 gitlab.com/company/backend/api.git처럼요. 이는 정상이니 주소를 통째로 복사하세요.

토큰으로 GitLab git clone하기

비밀번호를 입력해 줄 사람이 없는 스크립트나 서버에서는 토큰을 주소에 직접 넣습니다. 사용자 이름에는 본인의 사용자 이름이나 서비스용 oauth2를 쓸 수 있습니다.

git clone https://oauth2:YOUR_TOKEN@gitlab.com/my-group/my-project.git

주의하세요. 이런 주소는 .git/config에 저장되고, 셸 명령 기록에 남을 수 있습니다. 자동화에는 최소 권한과 기한을 가진 deploy token이나 project access token을 쓰세요. CI 안에서는 내장 변수 CI_JOB_TOKEN을 쓰는 것이 알맞습니다.

GitLab에 git push하기: 코드 보내기

프로젝트가 이미 로컬에 있다면, GitLab에 빈 프로젝트를 만든 뒤(불필요한 커밋이 생기지 않도록 README는 추가하지 마세요) 원격 저장소를 연결합니다.

git remote add origin git@gitlab.com:my-group/my-project.git
git branch -M main
git push -u origin main

-u 옵션은 로컬 브랜치와 원격 브랜치를 연결합니다. 이후에는 git push와 git pull만 입력하면 됩니다. 일반적인 작업 흐름은 다른 서비스와 같습니다.

git switch -c feature/login
git add .
git commit -m "로그인 폼 추가"
git push -u origin feature/login
git pull

태그는 따로 보냅니다. git push origin v1.2.0처럼 하나씩 보내거나, git push --tags로 한꺼번에 보냅니다. GitLab에서는 Tags 섹션에 태그가 보이며, 릴리스 파이프라인을 실행하는 경우가 많습니다.

GitLab에서 git push할 때 자주 생기는 오류

• HTTP Basic: Access denied: 아이디가 틀렸거나, 토큰 대신 비밀번호를 입력했습니다. write_repository 권한이 있는 토큰을 새로 만들고, 자격 증명 관리자의 옛 기록을 지우세요.
• Permission denied (publickey): GitLab이 SSH 키를 인식하지 못합니다. 공개 키가 프로필에 등록되어 있는지 확인하고, ssh -T git@gitlab.com을 실행하세요.
• You are not allowed to push code to protected branches: 브랜치(보통 main)가 보호되어 있습니다. 내 브랜치에 보내고, 머지 리퀘스트를 만드세요.
• rejected ... (fetch first): 서버에 내 쪽에 없는 커밋이 있습니다. git pull --rebase를 실행한 뒤 다시 push하세요.
• remote: Project not found: 주소에 오타가 있거나, 이 프로젝트에 접근 권한이 없습니다. 소유자에게 권한을 확인하세요.

GitLab의 머지 리퀘스트

머지 리퀘스트는 GitHub의 풀 리퀘스트에 해당합니다. 내 브랜치를 기본 브랜치에 합쳐 달라는 요청입니다. MR에서 동료는 코드의 특정 줄에 댓글을 달고, CI 검사가 실행되며, 병합 여부가 결정됩니다. 새 브랜치를 push하면 GitLab은 터미널에 MR을 만드는 링크를 보여 주고, 웹 화면에서도 생성을 제안합니다.

push 옵션을 쓰면 명령줄에서 바로 MR을 만들 수도 있습니다.

git push -o merge_request.create -o merge_request.target=main origin feature/login

전형적인 흐름은 작업별 브랜치, 커밋, push, MR, 리뷰와 초록색 파이프라인, 병합입니다. 병합할 때 GitLab은 커밋을 하나로 합치고(squash), 원래 브랜치를 삭제할 수 있습니다. MR에 충돌이 있으면 로컬에서 브랜치를 갱신하는 것이 가장 쉽습니다. git pull --rebase origin main이나 git merge main을 실행하고, 충돌을 해결한 뒤 다시 push하세요.

완성되지 않은 작업은 Draft로 표시하세요. 초안 MR은 실수로 병합되지 않지만, 동료들은 변경 사항을 보고 논의할 수 있습니다.

GitLab CI/CD: .gitlab-ci.yml

GitLab의 큰 특징은 CI/CD가 내장되어 있다는 점입니다. 저장소 루트에 .gitlab-ci.yml 파일을 두기만 하면, push할 때마다 GitLab이 파이프라인을 실행합니다. 파이프라인은 단계(stages)와 작업(jobs)으로 구성되며, 작업은 러너(Runner)가 실행합니다. gitlab.com에는 공용 러너가 있고, 자체 서버에서는 러너를 따로 설치합니다.

stages:
  - test
  - deploy

test:
  stage: test
  image: python:3.12
  script:
    - pip install -r requirements.txt
    - pytest

deploy:
  stage: deploy
  script:
    - ./deploy.sh
  rules:
    - if: $CI_COMMIT_TAG

이 예시에서 테스트는 push할 때마다 실행되고, deploy 작업은 태그가 올라왔을 때만 실행됩니다. git tag v1.0.0과 git push origin v1.0.0을 실행하면 배포가 시작됩니다. 파이프라인 결과는 머지 리퀘스트에 바로 표시되며, 검사를 통과하기 전에는 병합을 막을 수도 있습니다.

GitLab 저장소를 삭제하는 방법

Git 명령으로는 서버의 프로젝트를 삭제할 수 없습니다. git push가 바꾸는 것은 브랜치와 태그뿐입니다. 프로젝트 삭제는 웹 화면에서 합니다. 프로젝트 설정에서 General을 열고, Advanced 블록의 삭제 버튼을 눌러 프로젝트 이름을 입력해 확인합니다. Owner(소유자) 역할이 필요합니다. 로컬 사본은 그대로 남습니다. 그것은 .git이 들어 있는 평범한 폴더일 뿐입니다.

서버에는 아무 변화를 주지 않고 로컬 저장소만 GitLab과 분리하고 싶다면, git remote remove origin이면 충분합니다.

GitLab을 고르는 경우

• 코드를 외부 클라우드에 올릴 수 없어서 자체 서버가 필요한 경우.
• 외부 서비스 없이 CI/CD를 기본으로 쓰고 싶은 경우.
• 하위 그룹과 세밀한 역할이 필요한 큰 조직인 경우.
• 이미 GitLab을 쓰는 회사에 입사하는 경우. 이때는 선택의 여지가 없지만, Git 기술은 그대로 살릴 수 있습니다.

포트폴리오와 오픈소스에는 대개 GitHub를 고릅니다. 커뮤니티가 크고 프로젝트가 더 많이 노출되기 때문입니다. 같은 프로젝트를 두 서비스에 함께 둘 수도 있습니다. 저장소에는 여러 개의 remote를 설정할 수 있습니다.

정리

GitLab은 머지 리퀘스트를 통한 리뷰, 이슈, 내장 CI/CD를 갖춘 Git 저장소 플랫폼이며, 클라우드와 자체 서버 모두에서 쓸 수 있습니다. 작업은 익숙한 명령으로 진행됩니다. 토큰이나 SSH 키로 로그인을 설정하고, clone, commit, push, 머지 리퀘스트 순서로 진행하세요. 원격 저장소와 팀 워크플로는 Git 강의에서 실습으로 자세히 다룹니다.