레슨 1
GitLab v19.4요약
이 레슨에서는 한 글자짜리 텍스트 변경이라는 가장 작은 문제를 다룹니다. 이 세 가지를 학습한 뒤에는 GitLab 팀원이 라이브 코딩 데모를 진행합니다. 라이브 코딩에서 다룰 것과 매우 비슷한 이슈 목록이 "Linked items" 섹션에 있으며, 지금 그중 하나에 댓글을 달아 자신에게 할당해 두면 함께 따라가기 좋습니다.
이 레슨에서는 한 글자짜리 텍스트 변경이라는 가장 작은 문제를 다룹니다. 이를 위해 다음을 학습합니다.
- GitLab 개발 환경을 설정하는 방법.
- GitLab 코드베이스를 탐색하는 방법.
- GitLab 프로젝트에서 머지 리퀘스트를 만드는 방법.
이 세 가지를 학습한 뒤에는 GitLab 팀원이 라이브 코딩 데모를 진행합니다. 데모에서는 이러한 작은 이슈 중 하나를 완료하면서 학습한 내용을 하나씩 활용하므로, 이후 직접 이슈를 완료할 수 있습니다.
라이브 코딩에서 다룰 것과 매우 비슷한 이슈 목록이 "Linked items" 섹션에 있으며, 지금 그중 하나에 댓글을 달아 자신에게 할당해 두면 함께 따라가기 좋습니다.
GDK 개요#
GDK(GitLab Development Kit)는 개발자가 자신의 컴퓨터에서 GitLab을 실행하고 테스트할 수 있게 해 주는 로컬 GitLab 인스턴스입니다. 프론트엔드 전용 애플리케이션과 달리 GDK는 백엔드 서비스, API, 로컬 데이터베이스를 포함한 GitLab 애플리케이션 전체를 실행합니다. 덕분에 개발자는 변경 사항을 적용하고 실시간으로 테스트하며 수정 내용을 검증할 수 있습니다.
GDK 사용 시 참고할 점은 다음과 같습니다.
- 문제 해결 문서: GDK에서 문제가 발생하면 GDK 리포지터리의 문제 해결 문서를 참고합니다. 이 자료는 흔히 발생하는 문제를 해결하는 데 유용한 명령과 요령을 제공합니다.
- Rails 콘솔 사용: Rails 콘솔은 로컬 GitLab 인스턴스와 상호작용하는 데 꼭 필요한 도구입니다.
gdk rails c를 실행해 접근할 수 있으며, 기능 플래그를 켜고 끄거나 백엔드 작업을 수행하는 등에 사용합니다. - 최신 상태 유지:
gdk update를 주기적으로 실행해 GDK를 업데이트합니다. 이 명령은 GitLab 프로젝트의 최신 브랜치와 함께 GDK 및 그 의존성의 최신 브랜치를 가져옵니다. GDK를 최신 상태로 유지하면 최신 버전의 GitLab으로 작업하고 최신 버그 수정을 적용받을 수 있습니다.
추가 도움이 필요하거나 구체적인 질문이 있다면 Discord나 그 밖의 지원 채널을 통해 GitLab 커뮤니티에 문의할 수 있습니다.
GDK 로컬 설치 및 사용#
최신 설치 안내는 GitLab Development Kit 문서를 참고합니다.
단계별 요약은 다음과 같습니다.
- 사전 요구 사항:
- 설치:
-
GitLab Development Kit(GDK)을 설치할 디렉터리를 선택합니다.
-
터미널을 열고 선택한 디렉터리로 이동합니다.
-
터미널에서 설치 스크립트를 내려받아 실행합니다:
curl "https://gitlab.com/gitlab-org/gitlab-development-kit/-/raw/main/support/install" | bash -
안전을 위해 신뢰할 수 있는 출처의 스크립트만 실행합니다.
-
설치 과정에는 20분 이상 걸릴 수 있습니다.
-
- 리포지터리 선택:
- GitLab 메인 리포지터리를 클론하는 대신, 폭넓은 커뮤니티 구성원에게 권장되는 커뮤니티 포크를 사용합니다.
- 안내에 따라 커뮤니티 포크를 설치합니다.
- GDK 구조:
- 설치가 끝나면 GDK 디렉터리가 생성됩니다.
- GDK 디렉터리 안에는 GitLab 프로젝트 폴더가 있습니다.
- GDK 사용:
- GDK는 설치본과 상호작용하는 데 쓰는 여러 명령을 제공합니다. 이러한 명령을 실행하려면 GDK 또는 GitLab 폴더 안에 있어야 합니다.
- GDK를 시작하려면 터미널에서
gdk start명령을 실행합니다. - 터미널에서
gdk help를 실행하면 사용할 수 있는 명령과 옵션을 확인할 수 있습니다.
추가 질문이나 문제가 있다면 문서를 참고하거나 커뮤니티 지원을 요청합니다.
GitLab 코드베이스 탐색#
GitLab 코드베이스를 탐색하는 방법을 이해하는 일은 기여자에게 필수입니다. 코드베이스를 탐색하고 특정 파일을 찾는 일은 쉽지 않지만, 변경을 적용하고 이슈를 효과적으로 해결하는 데 중요합니다. 여기서는 파일을 찾고 그 파일이 GitLab 어디에서 렌더링되는지 확인하는 단계별 방법을 살펴봅니다.
작업할 파일은 이미 알고 있고 그 파일이 어디에서 렌더링되는지 찾고 싶다면 다음과 같이 합니다.
- 먼저 파일의 용도를 파악할 단서를 모읍니다. 컨텍스트를 알려 줄 키워드나 특정 콘텐츠처럼 파일 안에 있는 관련 정보를 찾습니다.
- 파일 경로(또는 폴더 구조)를 살펴 그 파일이 어디에서 렌더링되는지 짐작할 수도 있습니다. GitLab의 라우팅은 상당 부분 폴더 구조와 매우 비슷합니다.
- 이 컴포넌트가 사용되는 기능(또는 그중 하나)을 알아낼 수 있다면, GitLab 사용자 문서를 활용해 해당 기능 페이지로 이동하는 방법을 확인할 수 있습니다.
- 컴포넌트 계층을 따라갑니다. 파일 이름으로 전역 검색해 해당 컴포넌트를 렌더링하는 상위 컴포넌트를 찾습니다. 계속 컴포넌트 계층을 따라 올라가 익숙한 기능이나 GitLab 사용자 문서에서 검색할 수 있는 기능까지 거슬러 올라갑니다.
- GitLens 같은 확장 기능과 함께
git blame을 사용해 이 파일이 변경된 최근 MR을 찾을 수 있습니다. 대부분의 MR에는 따라 해 볼 수 있는 "How to validate" 섹션이 있습니다. 해당 MR에 없다면 검증 단계가 있는 MR을 찾을 때까지 이전 변경을 살펴봅니다.
수정할 페이지는 알고 있고 파일 경로를 찾고 싶다면 다음을 시도할 수 있습니다.
- 번역 변수로 검색할 수 있도록, 변수를 포함하지 않는 고유한 콘텐츠를 찾습니다.
- Vue Dev Tools로 컴포넌트 이름을 찾아봅니다.
- 컴포넌트의 HTML에서
data-testid,id, 또는 고유해 보이는 CSS 클래스 같은 식별자를 찾은 다음, 해당 문자열로 코드베이스를 전역 검색합니다.
좋은 머지 리퀘스트 작성#
머지 리퀘스트를 작성할 때 유의할 점은 다음과 같습니다.
- 작성한 MR은 GitLab 프로젝트 문서의 영구적인 일부가 됩니다. 이후 어떤 코드가 왜 그렇게 동작하는지, 왜 다른 방식을 쓰지 않았는지 이해하는 데 쓰이기도 합니다.
- 최소 두 명의 다른 엔지니어가 코드를 리뷰합니다. 효율을 위해서는(작성한 코드와 마찬가지로) 시간을 조금 더 들여 MR을 다듬어 다른 사람이 더 빠르고 쉽게 읽도록 하는 편이 좋습니다.
- GitLab에서 만든 MR은 공개됩니다. 따라서 특히 만족스러운 MR의 링크를 구직 시 포트폴리오 페이지에 추가할 수 있습니다.
- MR은 기술 문서이므로 기술 문서 작성 문체를 적용하는 편이 좋습니다. 그 문체가 무엇인지 잘 모른다면 Google의 기술 문서 작성 단기 과정을 권장합니다. GitLab 문서에도 기여하고 있다면 GitLab 이 제공하는 Technical Writing Fundamentals 과정이 있습니다.
라이브 코딩#
이제 첫 MR을 완료할 차례입니다. 방금 마친 것과 매우 비슷하면서 완료가 필요한 이슈 목록이 "Linked items" 섹션에 있습니다. 기여해 주셔서 감사합니다. 남은 이슈가 없다면 Discord나 그 밖의 지원 채널로 알려 주시면 더 찾아 드립니다.