• 리포지터리 만들기
• 리포지터리에 파일 추가
  • UI에서 파일 추가
• 리포지터리의 변경 내용 커밋
• 리포지터리 복제
  • Apple Xcode에서 복제 및 열기
  • Visual Studio Code에서 복제 및 열기
  • IntelliJ IDEA에서 복제 및 열기
• 리포지터리의 코드 다운로드
• 리포지터리 언어
  • 리포지터리 언어 추가
  • 지원되는 마크업 언어
  • README 및 인덱스 파일
  • OpenAPI 뷰어
• 리포지터리 크기
• 리포지터리 기여자 분석
• 리포지터리 히스토리 그래프
• 리포지터리 경로 변경 시 발생하는 일
• 관련 주제
• 문제 해결
  • 리포지터리 언어: 과도한 CPU 사용
  • 리포지터리에 푸시된 순서 검색

리포지터리

리포지터리는 코드를 저장하고 수정하는 곳입니다. 여러분의 변경 사항은 버전 관리로 추적됩니다.

각 프로젝트에는 리포지터리가 포함되어 있습니다.

리포지터리 만들기

리포지터리를 만들려면 다음을 할 수 있습니다:

• 프로젝트 만들기 또는
• 기존 프로젝트 포크하기.

프로젝트가 없으면 리포지터리가 존재할 수 없습니다. 프로젝트에는 여러 가지가 있지만, 그 중 하나가 리포지터리입니다.

리포지터리에 파일 추가

파일을 리포지터리에 추가할 수 있습니다:

• 프로젝트를 만들 때.
• 프로젝트를 생성한 후, 다음을 사용하여:
  • 웹 에디터.
  • UI.
  • 명령줄.

UI에서 파일 추가

GitLab UI에서 파일을 업로드할 수 있습니다.

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 파일을 업로드하려는 디렉터리로 이동합니다.
3. 디렉터리 이름 옆에 있는 더하기 아이콘 () > 파일 업로드를 선택합니다.
4. 필드를 작성합니다. 변경 사항을 반영하는 Merge Request을 생성하려면, 리포지터리의 기본 브랜치가 아닌 브랜치 이름을 입력합니다.
5. 파일 업로드를 선택합니다.

리포지터리의 변경 내용 커밋

리포지터리의 브랜치에 변경 사항을 커밋할 수 있습니다. 명령줄을 사용할 때, 푸시하기 전에 여러 번 커밋할 수 있습니다.

• 커밋 메시지: 커밋 메시지는 무엇이 변경되었는지와 왜 변경되었는지를 식별합니다. GitLab에서는 커밋 메시지에 키워드를 추가하여 다음 작업을 수행할 수 있습니다:
  • GitLab CI/CD 파이프라인을 트리거하기: 프로젝트가 GitLab CI/CD로 구성된 경우, 커밋 당이 아닌 푸시 당으로 파이프라인을 트리거합니다.
  • 파이프라인 건너뛰기: 커밋 메시지에 ci skip 키워드를 추가하여 GitLab CI/CD에 파이프라인을 건너뛰도록 할 수 있습니다.
  • 이슈 및 Merge Request 상호 연결: 상호 연결을 사용하여 워크플로우의 관련 부분을 추적합니다. 커밋 메시지에서 이슈나 Merge Request을 언급하면 해당 스레드에 표시됩니다.
• 커밋 선택하기: GitLab에서는 UI에서 커밋을 선택할 수 있습니다.
• 커밋 되돌리기: UI에서 특정 브랜치로 커밋을 되돌릴 수 있습니다.
• 커밋에 서명하기: 커밋에 서명하여 추가 보안을 더할 수 있습니다.

리포지터리 복제

명령줄을 사용하여 리포지터리를 복제할 수 있습니다.

또는 코드 에디터에서 바로 복제할 수 있습니다.

Apple Xcode에서 복제 및 열기

.xcodeproj 또는 .xcworkspace 디렉터리를 포함하는 프로젝트는 macOS의 Xcode로 복제할 수 있습니다.

1. GitLab UI에서 프로젝트의 개요 페이지로 이동합니다.
2. 오른쪽 위 모서리에서 Code를 선택합니다.
3. Xcode를 선택합니다.

프로젝트가 컴퓨터에 복제되고 Xcode를 열 것을 확인합니다.

Visual Studio Code에서 복제 및 열기

모든 프로젝트는 GitLab 사용자 인터페이스에서 Visual Studio Code로 복제할 수 있지만 GitLab Workflow VS Code 확장 프로그램을 설치하여 Visual Studio Code에서 복제할 수도 있습니다:

• GitLab 인터페이스에서:
  1. 프로젝트의 개요 페이지로 이동합니다.
  2. 오른쪽 위 모서리에서 Code를 선택합니다.
  3. IDE에서 열기 아래에서 Visual Studio Code (SSH) 또는 Visual Studio Code (HTTPS)를 선택합니다.
  4. 프로젝트를 복제할 폴더를 선택합니다.

  Visual Studio Code가 프로젝트를 복제하면 해당 폴더가 열립니다.

• 확장 프로그램이 설치된 Visual Studio Code에서 확장의 Git: Clone 명령을 사용합니다.

IntelliJ IDEA에서 복제 및 열기

모든 프로젝트는 GitLab 사용자 인터페이스에서 IntelliJ IDEA로 복제할 수 있습니다.

사전 준비 사항:

• JetBrains Toolbox 앱이 설치되어 있어야 합니다.

다음을 수행합니다:

1. 프로젝트의 개요 페이지로 이동합니다.
2. 오른쪽 위 모서리에서 Code를 선택합니다.
3. IDE에서 열기 아래에서 IntelliJ IDEA (SSH) 또는 IntelliJ IDEA (HTTPS)를 선택합니다.

리포지터리의 코드 다운로드

저장된 소스 코드를 다운로드할 수 있습니다.

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 파일 디렉터리 위에서 Code를 선택합니다.

3. 옵션에서 다운로드하려는 파일을 선택합니다.

   • 소스 코드: 보고 있는 현재 브랜치에서 소스 코드를 다운로드합니다. 가능한 확장자: zip, tar, tar.gz, 및 tar.bz2.
   • 디렉터리: 특정 디렉터리를 다운로드합니다. 하위 디렉터리를 보고 있을 때에만 표시됩니다. 가능한 확장자: zip, tar, tar.gz, 및 tar.bz2.
   • 아티팩트: 최신 CI 작업에서 아티팩트를 다운로드합니다.

생성된 아카이브의 체크섬은 리포지터리 자체가 변경되지 않아도 변경될 수 있습니다. 예를 들어, Git이나 GitLab이 사용하는 써드파티 라이브러리가 변경되면 발생할 수 있습니다.

리포지터리 언어

GitLab은 각 리포지터리의 기본 브랜치에 대해 사용된 프로그래밍 언어를 결정합니다. 이 정보는 프로젝트 개요 페이지에 표시됩니다.

새 파일이 추가되면 이 정보는 최대 다섯 분이 소요될 수 있습니다.

리포지터리 언어 추가

모든 파일이 프로젝트 개요 페이지에서 감지되고 나열되지는 않습니다. 문서, 벤더 코드, 대부분의 마크업 언어는 제외됩니다.

이 동작을 변경하여 기본 설정을 무시할 수 있습니다.

1. 리포지터리의 루트 디렉터리에 .gitattributes라는 파일을 만듭니다.

2. GitLab에게 이 유형의 파일을 포함하도록 알리는 줄을 추가합니다. 예를 들어, .proto 파일을 가능하게 하려면 다음 코드를 추가합니다:

   *.proto linguist-detectable=true
   

지원되는 데이터 유형의 디렉터리을 보려면 지원되는 데이터 유형을 참조하세요.

이 기능은 과도한 CPU를 사용할 수 있습니다. 자세한 내용은 문제 해결 섹션을 참조하세요.

지원되는 마크업 언어

파일의 확장자 중 하나를 가지고 있는 경우, GitLab은 파일의 마크업 언어 내용을 UI에서 렌더링합니다.

README 및 인덱스 파일

리포지터리에 README 또는 index 파일이 있는 경우, GitLab은 해당 파일의 내용을 렌더링합니다. 이 파일들은 일반 텍스트일 수도 있고 지원되는 마크업 언어의 확장자를 가질 수도 있습니다.

• README와 index 파일이 모두 있는 경우 README가 항상 우선권을 갖습니다.
• 동일한 이름을 가진 여러 파일이지만 다른 확장자를 가지고 있는 경우, 파일은 알파벳 순으로 정렬됩니다. 확장자가 없는 파일은 마지막에 정렬됩니다. 예를 들어, README.adoc는 README.md보다 우선권을 갖고 README.rst는 README보다 우선권을 갑니다.

OpenAPI 뷰어

GitLab은 OpenAPI 명세 파일을 렌더링할 수 있습니다. 파일 이름은 반드시 openapi 또는 swagger를 포함하고 확장자는 yaml, yml, 또는 json이어야 합니다. 다음 예시는 모두 올바릅니다:

• openapi.yml
• openapi.yaml
• openapi.json
• swagger.yml
• swagger.yaml
• swagger.json
• gitlab_swagger.yml
• openapi_gitlab.yml
• OpenAPI.YML
• openapi.Yaml
• openapi.JSON
• openapi.gitlab.yml
• gitlab.openapi.yml

OpenAPI 파일을 렌더링하려면:

1. 리포지터리의 OpenAPI 파일로 이동합니다.
2. 렌더링된 파일 표시를 선택합니다.
3. 작업 디렉터리에서 operationId를 표시하려면 쿼리 문자열에 displayOperationId=true를 추가합니다.

리포지터리 크기

• GitLab 15.3에서 소개, 대체 리포지터리 크기 계산을 위한 피처 플래그 gitaly_revlist_for_repo_size 및 gitaly_catfile_repo_size.

플래그: Self-Managed형 GitLab에서 기본적으로 GitLab은 리포지터리 크기를 결정하기 위해 du -sk 명령어를 사용합니다. GitLab은 대신 git-rev-list (피처 플래그 gitaly_revlist_for_repo_size로 활성화) 또는 git-cat-file (피처 플래그 gitaly_catfile_repo_size로 활성화)를 사용할 수 있습니다. 다른 계산 방법으로 전환하려면 관리자가 이러한 피처 플래그를 활성화 또는 비활성화할 수 있습니다.

프로젝트 개요 페이지에는 리포지터리의 모든 파일 크기가 표시됩니다. 파일 크기는 최대 15분마다 업데이트됩니다. 파일 크기에는 리포지터리 파일, 아티팩트, 그리고 LFS가 포함됩니다.

압축, 정리 및 기타 요소로 인해 한 인스턴스에서 다른 인스턴스로 크기가 약간 다를 수 있습니다.

관리자는 리포지터리 크기 제한을 설정할 수 있습니다. GitLab은 GitLab.com의 크기 제한을 설정합니다.

리포지터리 기여자 분석

Contributor analytics에서 프로젝트 멤버가 한 커밋 디렉터리과 차트를 볼 수 있습니다.

리포지터리 히스토리 그래프

리포지터리 그래프는 브랜치와 머지를 포함한 리포지터리 네트워크의 시각적인 히스토리를 표시합니다. 이 그래프는 리포지터리에서 사용된 Git 플로우 전략을 시각적으로 돕습니다.

프로젝트의 Code > Repository graph로 이동하세요.

리포지터리 경로 변경 시 발생하는 일

리포지터리 경로가 변경되면 GitLab은 이전 위치에서 새 위치로의 전환을 처리합니다.

사용자를 이름 바꿈, 그룹 경로를 변경, 또는 리포지터리를 이름 바꿈할 때:

• 네임스페이스 및 해당 하위 프로젝트와 같은 모든 URL은 새 URL로 리디렉션됩니다.
• 네임스페이스 내 프로젝트의 Git 리모트 URL은 새 리모트 URL로 리디렉션됩니다. 위치가 변경된 리포지터리에 push 또는 pull할 때, 원격을 업데이트하라는 경고 메시지가 표시됩니다. 자동화 스크립트 또는 Git 클라이언트는 이름 변경 후에도 계속 작동합니다.
• 리디렉션은 원래 경로가 다른 그룹, 사용자, 또는 프로젝트에 의해 차지되지 않는 한 사용할 수 있습니다.
• 명시적으로 API 리디렉션을 따라야 할 수 있습니다.

경로를 바꾼 후에는 다음 리소스에서 기존 URL을 업데이트해야 합니다. 리디렉션을 따를 수 없기 때문입니다:

• include:component 외의 Include 문은 구문 오류로 인해 파이프라인에 실패합니다. CI/CD 컴포넌트 참조는 리디렉션을 따를 수 있습니다.
• 인코딩된 경로 대신 숫자 네임스페이스 및 프로젝트 ID를 사용하는 네임스페이스 API 호출.
• Docker 이미지 참조.
• 프로젝트 또는 네임스페이스를 지정하는 변수.

관련 주제

• GitLab Workflow VS Code 확장 프로그램
• 잠금 파일 및 변경 충돌 방지
• 리포지터리 API
• 파일 찾기
• 브랜치
• 디렉터리 생성
• 파일 히스토리 찾기
• 라인별 변경 식별 (Git blame)
• GitLab에서 Jupyter 노트북 사용

문제 해결

리포지터리 언어: 과도한 CPU 사용

리포지터리 파일에 포함된 언어를 결정하기 위해 GitLab은 Ruby gem을 사용합니다. 리포지터리가 어떤 유형인지 확인하려면 프로세스가 과도한 CPU를 사용할 수 있습니다. 이 gem에는 파일 확장자를 구문 분석하기 위해 정의된 휴리스틱 구성 파일이 포함되어 있습니다.

gem에 정의되지 않은 확장자를 가진 XML 파일 및 .txt 확장자를 가진 파일은 과도한 CPU를 사용할 수 있습니다.

해결책은 특정 파일 확장자에 할당할 언어를 지정하는 것입니다. 동일한 접근 방식을 사용하여 잘못 식별된 파일 유형을 수정할 수도 있습니다.

1. 지정할 언어를 식별합니다. gem에는 알려진 데이터 유형에 대한 구성 파일이 포함되어 있습니다. 예를 들어 텍스트 파일에 대한 항목을 추가하려면:

   Text:
     type: prose
     wrap: true
     aliases:
     - fundamental
     - plain text
     extensions:
     - ".txt"
   

2. 리포지터리 루트에 .gitattributes을 추가하거나 수정합니다:

   *.txt linguist-language=Text
   

   *.txt 파일에는 휴리스틱 파일에 항목이 있습니다. 이 예제는 이러한 파일의 구문 분석을 방지합니다.

리포지터리에 푸시된 순서 검색

커밋이 “실수로” 사라졌다고 생각된다면 리포지터리에 대한 푸시 순서를 검색하세요. 이 StackOverflow 기사에서 강제 푸시 없이 이 상태에 도달하는 방법에 대해 설명합니다. 다른 원인으로는 git reset 작업에서 HEAD ref를 변경하는 서버 후크가 잘못 구성된 경우도 있을 수 있습니다.

아래 샘플 코드의 출력 결과를 대상 브랜치에서 살펴보면 출력을 통해 각 푸시의 commit_from이 이전 푸시의 commit_to와 동일해야 한다는 것을 알 수 있습니다. 이러한 연속성의 중단은 한 개 이상의 커밋이 리포지터리의 이력에서 “잃어졌다”는 것을 나타냅니다.

다음 예제는 Rails 콘솔에서 마지막 100번의 푸시를 확인하고 commit_from 및 commit_to 항목을 출력하는 방법을 보여줍니다.

p = Project.find_by_full_path('project/path')
p.events.pushed_action.last(100).each do |e|
  puts "%-20.20s %8s...%8s (%s)", e.push_event_payload[:ref], e.push_event_payload[:commit_from], e.push_event_payload[:commit_to], e.author.try(:username)
end ; nil

중간의 연속성이 깨진 예시 출력:

master f21b07713251e04575908149bdc8ac1f105aabc3...6bc56c1f46244792222f6c85b11606933af171de root
master 6bc56c1f46244792222f6c85b11606933af171de...132da6064f5d3453d445fd7cb452b148705bdc1b root
master 132da6064f5d3453d445fd7cb452b148705bdc1b...a62e1e693150a2e46ace0ce696cd4a52856dfa65 root
master 58b07b719a4b0039fec810efa52f479ba1b84756...f05321a5b5728bd8a89b7bf530aa44043c951dce root
master f05321a5b5728bd8a89b7bf530aa44043c951dce...7d02e575fd790e76a3284ee435368279a5eb3773 root