레슨 1
이 레슨에서는 가장 작은 문제 - 한 글자의 텍스트 변경에 대처합니다. 이를 위해 다음을 배워야 합니다:
- GitLab 개발 환경 설정 방법.
- GitLab 코드 베이스 탐색 방법.
- GitLab 프로젝트에서 병합 요청 생성 방법.
이 3가지를 배운 후에는 GitLab 팀원이 라이브 코딩 데모를 진행할 것입니다. 데모에서는 배운 내용을 활용하여 이 작은 문제 중 하나를 완료하여 여러분이 직접 문제를 해결할 수 있도록 도와줄 것입니다.
“Linked items” 섹션에 라이브 코딩할 문제와 매우 유사한 문제 목록이 있습니다. 지금 이 중 하나에 주석을 달아 자신을 할당받게 해주세요. 그러면 따라갈 수 있습니다.
GDK란 무엇인가요?
GDK(GitLab Development Kit)는 개발자가 자신의 컴퓨터에서 GitLab를 실행하고 테스트할 수 있는 로컬 GitLab 인스턴스입니다. Frontend 전용 애플리케이션과 달리, 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 문서를 참조하십시오.
다음은 단계별 요약입니다:
- 전제 조건:
- 16GB RAM. RAM이 적은 경우 Gitpod 사용을 고려하십시오.
- 컴퓨터에 Git이 설치되어 있는지 확인합니다.
- Visual Studio Code와 같은 코드 편집기를 설치합니다.
- GitLab.com에 계정을 만들거나 로그인하고 커뮤니티 멤버 그룹에 참여하세요.
- 설치:
- 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 start
명령을 실행하여 GDK를 시작할 수 있습니다. - 터미널에서
gdk help
명령을 실행하여 사용 가능한 명령어와 옵션을 확인할 수 있습니다.
더 궁금한 사항이나 문제가 발생하면 문서를 참조하시거나 커뮤니티 지원을 요청하세요.
GDK를 로컬에서 실행하는 대신 Gitpod 사용하기
Gitpod는 개발자가 자신의 컴퓨터에서 GDK를 실행하는 대신 Gitpod 서버에서 가상 머신, 특히 GitLab Development Kit (GDK)를 실행할 수 있는 서비스입니다. 이 서비스는 웹 기반 통합 개발 환경(IDE)을 제공하여 코드를 편집하고 GDK를 사용하는 것과 같은 환경을 제공합니다. Gitpod는 GDK를 로컬에 설치하지 않고도 빠르게 GDK 환경을 구축하고 작은 병합 요청을 만드는 데 유용하며, 자원이 부족한 컴퓨터에서 GDK를 실행하는 데도 유용합니다.
Gitpod 사용 방법:
- GitLab 커뮤니티 포크에 대한 액세스 요청. 그렇지 않은 경우 자체 공개 포크를 만들 수 있지만 커뮤니티 포크의 이점을 놓치게 됩니다.
- GitLab 커뮤니티 포크 웹사이트로 이동한 다음 편집을 선택한 후 Gitpod을 선택하세요.
- 편집기(일반적으로
main
또는master
브랜치) 및 컨텍스트와 같은 설정을 구성하세요. - Gitpod 워크스페이스를 만드려면 열기를 선택하세요. 이 과정은 최대 20분이 소요될 수 있습니다. GitLab Development Kit (GDK)이 Gitpod 워크스페이스에 설치됩니다. 이 설치는 로컬에서 완전한 GDK를 다운로드하고 설치하는 것보다 더 빠릅니다.
워크스페이스가 만들어지면 선택한 IDE가 브라우저에서 실행됩니다. 또한 필요한 경우 데스크톱 IDE에 연결할 수도 있습니다.
워크스페이스가 비활성되지 않도록 주기적으로 코드를 푸시하여야 합니다. 비활성화된 워크스페이스는 결국 삭제됩니다.
필요한 경우 Gitpod 워크스페이스 설정을 사용자 정의하고, GitLab 프론트엔드를 공개적으로 사용할 수 있습니다.
분을 다 사용한 경우 Discord 서버의 지원팀에 문의하세요.
GDK 워크스페이스를 로컬에서 실행하는 것과 동일하게 명령어(예: gdk start
, gdk status
)를 사용하여 문제를 해결하세요.
이렇게 하면 로컬 설치 없이 GitLab Development Kit을 효율적으로 개발할 수 있습니다.
GitLab 코드베이스 탐색
GitLab 코드베이스를 탐색하는 방법을 이해하는 것은 기여자들에게 필수적입니다. 코드베이스를 탐색하고 특정 파일을 찾는 것은 변경 사항을 효과적으로 만들고 문제에 대처하는 데 중요하지만 어려울 수 있습니다. 여기에서는 GitLab에서 파일을 찾고 렌더링되는 위치를 찾는 단계별 프로세스를 살펴볼 것입니다.
이미 작업할 파일을 알고 있다면 그 파일이 렌더링되는 위치를 찾고 싶다면:
- 파일의 목적을 이해하기 위해 단서를 수집하는 것으로 시작합니다. 파일 자체에서 관련 정보를 찾아보세요. 이는 해당 파일의 맥락을 나타내는 키워드나 특정 콘텐츠와 같은 내용일 수 있습니다.
- 파일 경로(또는 폴더 구조)를 검토하여 해당 파일이 렌더링될 수 있는 위치에 대한 통찰을 얻을 수 있습니다. GitLab의 많은 라우팅은 폴더 구조와 매우 유사합니다.
- 이 구성 요소가 사용된 기능(또는 그 기능 중 하나)을 파악할 수 있다면 GitLab 사용자 설명서를 활용하여 해당 기능 페이지로 이동하는 방법을 찾을 수 있습니다.
- 부모 구성 요소를 식별하기 위해 파일 이름을 전역 검색하여 해당 구성 요소를 렌더링하는 부모 구성 요소를 식별합니다. 구성 요소의 계층 구조를 따르어 인식할 수 있는 기능으로 거슬러 올라가거나 GitLab 사용자 설명서에서 검색할 수 있습니다.
- 최근에 해당 파일이 변경된 MR을 찾기 위해
git blame
와 GitLens와 같은 확장을 사용할 수 있습니다. 대부분의 MR에는 따를 수 있는 “유효성 검사 방법” 섹션이 있습니다. 만약 MR에 없다면 이전 변경 사항을 찾아서 유효성 검사 단계가 포함된 MR을 찾을 때까지 계속합니다.
수정해야 할 페이지를 알고 있고 파일 경로를 찾고 싶으면 다음과 같은 방법들이 있습니다:
- 변수를 포함하지 않고 고유한 콘텐츠를 찾아 번역 변수를 검색할 수 있도록 합니다.
- Vue Dev Tools를 사용하여 구성 요소 이름을 찾아보세요.
- 구성 요소의 HTML에서
data-testid
,id
또는 고유한 CSS 클래스와 같은 고유 식별자를 찾은 후 해당 식별 문자열을 코드베이스 전체에서 전역으로 검색합니다.
좋은 병합 요청 작성
병합 요청을 작성할 때 중요한 점 몇 가지가 있습니다:
- 병합 요청(MR)은 GitLab 프로젝트의 영구적인 문서의 일부가 될 것입니다. 나중에 어떤 코드가 원래 코드가 작동하는 방식을 이해하고 대체 솔루션을 사용하지 않는 이유를 이해하는 데 도움을 줄 수 있습니다.
- 적어도 2명의 엔지니어가 귀하의 코드를 검토할 것입니다. 효율성을 위해(작성한 코드 자체처럼) 좀 더 오랜 시간을 들여 MR을 올바르게 만들어 다른 사람이 더 빨리 쉽게 읽을 수 있도록 하는 것이 좋습니다.
- GitLab에서 만든 MR은 공개적으로 이용할 수 있습니다. 이는 구직 시에 포트폴리오 페이지에 특히 자랑스럽다고 생각하는 MR에 링크를 추가할 수 있음을 의미합니다.
- MR은 기술 문서이므로 기술적인 글쓰기 스타일을 구현하려고 해야 합니다. 이에 대해 모르신다면 Google의 기술 글쓰기에 대한 강력 추천 단기 과정이 있습니다. 또한 GitLab에서 기여하고자 하는 경우 GitLab에서 제공하는 기술 글쓰기 기본과정도 구할 수 있습니다.
실시간 코딩
이제 여러분 차례입니다. 첫 번째 MR을 완료해 보세요. 방금 완료한 것과 매우 유사한 문제들의 목록이 여기 “연결된 항목” 섹션에 있습니다. 기여해주셔서 감사합니다! (남은 항목이 없다면 Discord나 기타 사용 가능한 지원 채널에서 알려주시면 더 찾아드리겠습니다)