버전 제어 사용 및 배포

이 페이지에서는 프로젝트가 이미 버전 제어를 사용하도록 설정되어 있다고 가정합니다. 이 페이지에 설명된 선택사항 대신 Git 구성 버튼이 표시되면 먼저 프로젝트에 Git을 설정해야 합니다.

버전 제어를 위한 Git 통합

Looker는 Git를 사용하여 변경사항을 기록하고 파일 버전을 관리합니다. 각 LookML 프로젝트는 Git 저장소에 상응하고 각 개발자 브랜치는 Git 브랜치와 연관됩니다. Git 저장소를 저장소라고 합니다.

Looker는 일반적으로 LookML 소스 파일 관리에 GitHub를 사용합니다. 그러나 Looker는 GitLab, Bitbucket 또는 인증에 SSH 키를 사용할 수 있는 Git 서버와 함께 작동하도록 구성할 수 있습니다.

GitHub에서는 github.com에서 Git 작업을 인증할 때 계정 비밀번호를 허용하지 않습니다. 자세한 내용은 GitHub 블로그 게시물을 참조하세요. HTTPS를 사용하여 Looker 프로젝트를 GitHub에 연결하려면 GitHub의 개발자 설정을 사용하여 개인 액세스 토큰을 만듭니다. HTTPS를 사용하여 GitHub에 연결하는 기존 Looker 프로젝트의 경우 GitHub의 개인 액세스 토큰을 사용하여 Git 연결을 재설정합니다.

Looker 프로젝트는 모든 Git 상호작용에 Git 제공업체와 함께 하나의 계정만 사용합니다. Git 설정에 대한 자세한 내용은 Git과 Looker 통합 문서 페이지를 참고하세요. 각 Looker 프로젝트에서 모든 Looker 개발자의 모든 개발이 하나의 Git 계정을 거칩니다. 즉, Looker 인스턴스가 추가 Git 통합 옵션 중 하나로 설정되어 있지 않는 한 Looker 개발자는 Git 제공업체를 통해 자체 계정을 보유할 필요가 없습니다. 이 경우 Looker 개발자는 Git 제공업체에 대한 외부 링크를 열거나 풀 요청을 만들기 위해 Git 계정이 필요합니다.

Git 분기를 사용하여 작업하기

Git의 주요 이점 중 하나는 Looker 개발자가 파일 저장소의 격리된 버전인 브랜치에서 작업할 수 있다는 것입니다. 다른 사용자에게 영향을 미치지 않고 앱을 개발하고 테스트할 수 있습니다. Looker의 개발자는 개발 모드에 있을 때마다 Git 브랜치를 사용합니다.

Git의 또 다른 주요 특징은 Git이 제공하는 다른 개발자와 쉽게 공동작업할 수 있다는 점입니다. 브랜치를 만들고 원하는 경우 변경할 수 있으며 이후 다른 개발자가 해당 브랜치로 전환하여 브랜치를 검토하거나 변경할 수 있습니다. 다른 개발자가 분기에 변경사항을 커밋한 경우 Looker에 Pull Remote Changes 버튼이 표시됩니다. 추가로 변경하기 전에 커밋된 변경사항을 분기로 가져와야 합니다.

마스터 브랜치, 현재 브랜치 또는 개발자의 개인 브랜치 이외의 브랜치를 삭제할 수도 있습니다.

개인 브랜치

처음 개발 모드로 전환하면 Looker에서 자동으로 개인 Git 분기를 만듭니다. 개인 분기는 dev-로 시작하며 내 이름을 포함합니다.

개인 분기는 나에게만 적용되며 삭제할 수 없습니다. 개인 분기는 다른 모든 개발자에게 읽기 전용입니다. 프로젝트에서 다른 개발자와 공동작업하는 경우 다른 브랜치로 전환하고 변경사항을 적용할 수 있도록 새 브랜치를 생성하는 것이 좋습니다.

팁: 다른 개발자의 개인 브랜치는 변경할 수 없습니다. 다른 사람의 개인 브랜치에서 작업을 확장하려면 브랜치에서 시작하는 새 브랜치를 생성합니다.

새 Git 브랜치 만들기

간단한 수정 작업을 진행 중이며 다른 개발자와의 공동작업은 하지 않는 경우, 일반적으로 개인 분기에 작업하는 것이 좋습니다. 개인 분기를 사용해 빠르게 업데이트한 다음 변경사항을 커밋하고 프로덕션으로 푸시할 수 있습니다.

그러나 개인 분기 외에 새로운 Git 분기를 만드는 것도 좋습니다. 다음과 같은 상황에서는 새 Git 브랜치가 적합합니다.

• 다른 개발자와 협업하고 있습니다. 개인 브랜치는 다른 개발자에게 읽기 전용이므로 다른 개발자와 공동작업하려면 다른 개발자가 브랜치에 쓸 수 있도록 새 Git 브랜치를 만들어야 합니다. 다른 사용자와 공동작업할 때 작업을 재개할 때마다 변경사항을 적용하세요. 이렇게 하면 작업을 계속하기 전에 모든 개발자의 최신 업데이트를 확인할 수 있습니다.
• 한 번에 여러 기능 세트를 작업하고 있습니다. 주요 프로젝트 중에 사소한 문제를 해결하거나 빠르게 문제를 해결하려는 경우가 있을 수 있습니다. 이 경우 변경사항을 현재 브랜치에 커밋한 다음 별도의 브랜치를 만들거나 다른 특성 세트에서 작동하도록 전환할 수 있습니다. 새 브랜치에서 수정한 다음 브랜치 변경사항을 프로덕션에 배포한 후에 원래 브랜치에서 작업을 재개할 수 있습니다.

새 브랜치를 만들기 전에 다음을 수행하세요.

• 현재 브랜치에서 병합 충돌이 있는 경우 브랜치를 해결해야 새 브랜치를 만들 수 있습니다.
• 현재 브랜치에 커밋되지 않은 변경사항이 있으면 새 브랜치를 만들기 전에 현재 브랜치에서 변경사항을 커밋해야 합니다.
• production 브랜치가 아닌 기존 개발 브랜치에서 시작하는 브랜치를 만들려면 먼저 해당 개발 브랜치로 전환하여 개발 브랜치의 최신 버전을 가져온 다음 원격 변경사항을 가져와서 해당 브랜치의 로컬 버전을 동기화하세요.

새 Git 브랜치를 만드는 방법은 다음과 같습니다.

1. 개발 모드가 사용 설정되어 있는지 확인합니다.

2. 개발 메뉴에서 프로젝트 파일로 이동합니다.

   

3. 왼쪽 아이콘 메뉴에서 Git 아이콘을 클릭하여 Git Actions 패널을 엽니다.

4. 브랜치 보기 드롭다운 메뉴를 클릭합니다.

5. 새 브랜치를 선택합니다.

   

6. New Branch(새 브랜치) 창에서 분기 이름을 입력합니다. Git 분기 이름에는 제한사항이 있습니다. 이름 지정 요구사항은 이 페이지의 Git 분기 이름 지정 규칙을 참조하세요.

7. Create from 드롭다운 메뉴를 클릭하고 새 브랜치의 시작점으로 사용할 기존 브랜치를 선택합니다.

8. 만들기를 클릭하여 브랜치를 만듭니다.

또는 프로젝트 설정 페이지의 분기 관리 탭에서 Git 분기를 만들 수 있습니다.

Git 브랜치 이름 지정 규칙

Looker는 Git에서 지정된 분기 이름 지정 규칙 요구사항을 사용합니다.

Git 분기 이름은 다음과 같으면 안 됩니다.

• 공백 문자 포함
• 이중 마침표를 포함합니다. ..
• 백슬래시 포함: \
• @{ 시퀀스를 포함합니다.
• 물음표(?)를 포함하세요.
• 여는 대괄호([)를 포함합니다.
• ASCII 제어 문자(~, \^ 또는 :)를 포함해야 합니다.
• 마침표로 시작: .
• 프리픽스(dev-)로 시작합니다(Looker 개발자의 개인 분기에 예약됨).
• 슬래시로 끝남: /
• 광고 확장으로 종료: .lock
  

또한 분기 이름은 전체 경로 구성요소 (예: foo/* 또는 bar/*/baz)를 나타내는 경우에만 별표 (*)를 포함할 수 있습니다. 이 경우 실제 브랜치 이름의 일부가 아닌 와일드 카드로 해석됩니다.

다른 Git 브랜치로 전환

현재 브랜치에서 병합 충돌이 있는 경우 다른 브랜치로 전환하기 전에 충돌을 해결해야 합니다.

또한 현재 브랜치에서 커밋되지 않은 변경사항이 있는 경우 현재 브랜치에서 변경사항을 커밋할 때까지 기존 브랜치로 전환할 수 없습니다.

다른 Git 분기로 전환하려면 다음 단계를 따르세요.

1. 프로젝트의 왼쪽 아이콘 메뉴에서 Git 아이콘을 클릭하여 Git Actions 패널로 이동합니다.
2. Git 작업 패널에서 현재 Git 브랜치 이름별로 Git 브랜치 드롭다운 메뉴를 클릭합니다.
3. 전환하려는 브랜치를 선택하거나 메뉴에서 브랜치 이름을 입력하여 검색합니다. 브랜치 이름 검색 시 대소문자를 구분하지 않습니다. 예를 들어 'DEV'를 검색하여 이름이 'dev', 'DEV', 'Dev' 등이 포함된 모든 브랜치를 볼 수 있습니다.

Git 분기 관리

Project Settings(프로젝트 설정) 페이지의 Branch Management(브랜치 관리) 탭에는 Looker 프로젝트의 모든 Git 브랜치가 포함된 표가 표시됩니다. Branch Management(브랜치 관리) 탭을 열려면 왼쪽 아이콘 메뉴에서 Settings(설정) 아이콘을 클릭하고 Branch Management(브랜치 관리) 탭을 선택하여 Project Settings(프로젝트 설정) 페이지로 이동합니다.

분기 관리 탭에서는 다음 작업을 할 수 있습니다.

1. New Branch(새 브랜치) 버튼을 클릭하여 새 브랜치를 만듭니다. 자세한 내용은 이 페이지의 새 Git 브랜치 만들기 섹션을 참조하세요.
2. 검색창에서 지점 이름을 검색합니다.
3. 새로고침 버튼을 클릭하여 표를 새로고침합니다.
4. 열 이름을 클릭하여 표를 정렬합니다.

표에는 다음 정보가 포함됩니다.

• Name(이름): Git 분기의 이름입니다. Looker 개발자 개인 분기는 dev-로 시작하고 개발자의 성과 이름을 포함합니다.
• 상태: 브랜치의 로컬 버전과 브랜치의 원격 버전이 다릅니다. 예를 들어, 상태가 3 commits behind인 경우 브랜치의 로컬 버전이 3개의 커밋에 의해 원격 버전의 브랜치 뒤에 있습니다. Looker는 항상 마스터의 원격 버전을 사용하므로 Branch Management 탭에 마스터 브랜치의 로컬 버전 상태가 표시되지 않습니다. 마스터 분기는 항상 최신 상태로 간주될 수 있습니다.
• 최종 업데이트: Looker 개발자가 분기에 커밋한 후 경과한 시간입니다.
• 작업: 브랜치를 삭제하는 버튼 또는 브랜치를 삭제할 수 없는 이유입니다.

Git 분기 삭제

분기 관리 탭에서 표에 삭제 버튼이 있는 분기를 삭제할 수 있습니다. 다음 분기는 삭제할 수 없습니다.

• 마스터 분기
• 현재 분기
• Looker 개발자 지점

테이블에서는 이러한 브랜치에 Delete 버튼이 없습니다. 대신 테이블의 작업 열에 분기를 삭제할 수 없는 이유가 표시됩니다.

브랜치를 삭제한 후에는 복원할 수 없습니다. 분기를 삭제하면 Looker에서 브랜치의 로컬 버전과 브랜치의 원격 버전이 모두 삭제됩니다.

그러나 다른 Looker 개발자가 분기를 만들었거나 다른 개발자가 분기를 체크아웃한 경우 이러한 개발자의 로컬 분기 버전은 계속 유지됩니다. Looker 개발자가 로컬 버전의 브랜치를 커밋하고 이를 프로덕션에 푸시하는 경우, 브랜치의 원격 버전이 다시 표시됩니다. 브랜치를 복원하려는 경우에는 이 방법이 편리합니다. 그렇지 않으면 브랜치를 삭제할 때 다른 모든 Looker 개발자가 실수로 브랜치를 원격으로 푸시하여 다른 사용자가 다시 표시되지 않도록 하는 것이 좋습니다.

프로젝트에서 하나 이상의 Git 분기를 삭제하려면 왼쪽 아이콘 메뉴에서 설정 아이콘을 클릭하고 분기 관리 탭을 선택하여 프로젝트 설정 페이지로 이동합니다. 분기 관리 탭에서 다음 두 가지 방법으로 분기를 삭제할 수 있습니다.

1. 브랜치 체크박스를 선택하고 선택한 브랜치 삭제를 클릭하여 여러 브랜치를 삭제합니다.
2. 분기 이름 옆에 있는 삭제를 클릭하여 단일 분기를 삭제합니다.

Looker에서 Git 명령어 실행

Looker에는 Git 서비스와 통합되는 내장 인터페이스가 있습니다. LookML IDE의 오른쪽 상단에 Git의 버튼이 표시됩니다.

Git 버튼은 변경 및 프로덕션 배포의 어느 단계에 있는지에 따라 다른 옵션을 표시합니다. 일반적으로 버튼에 표시된 옵션이 다음 작업을 위한 최적의 가이드입니다.

개발자 브랜치가 production 분기와 동기화되어 있으면 최신 메시지가 표시됩니다.

프로젝트가 Git용으로 구성되면 IDE에 추가 Git 명령어가 포함된 Git Actions 패널이 표시됩니다.

Git 작업 패널에서 사용할 수 있는 명령어는 변경 및 프로덕션에 배포 중인 단계에 따라 다릅니다.

프로덕션에 변경사항 적용

기본 Looker Git 통합을 사용하면 Looker에서 다음 Git 워크플로를 통해 개발자에게 메시지를 보냅니다.

• 개발자의 현재 개발 브랜치에 변경사항을 커밋합니다 (프로젝트가 배포 전에 테스트 필요로 설정된 경우 데이터 테스트 실행).
• 개발 브랜치를 기본적으로 프로덕션 브랜치로 병합하는 master라고 합니다.
• Looker 최종 사용자에게 표시될 Looker 프로덕션 환경에 프로덕션 브랜치 배포

즉, 기본 Git 통합을 사용하면 모든 개발자가 변경사항을 master 브랜치로 병합하며 master 브랜치의 최신 커밋이 Looker의 프로덕션 환경에 사용됩니다.

고급 Git 구현의 경우 이 워크플로를 맞춤설정할 수 있습니다.

• 개발자가 Looker IDE를 통해 변경사항을 병합하도록 허용하는 대신 Git 프로덕션 브랜치의 pull 요청을 제출하도록 할 수 있습니다. 자세한 내용은 프로젝트 버전 제어 설정 구성 문서 페이지를 참조하세요.
• Git Production Branch Name(Git 프로덕션 브랜치 이름) 필드를 사용하여 Looker 개발자 브랜치를 병합할 대상 브랜치로 Looker에서 분기를 사용해야 하는 경우를 지정할 수 있습니다. 자세한 내용은 프로젝트 버전 제어 설정 구성 문서 페이지를 참조하세요.
• production 분기에서 최신 커밋을 사용하는 대신 고급 배포 모드를 사용하여 Looker 프로덕션 환경에 배포할 다른 커밋 SHA 또는 태그 이름을 지정할 수 있습니다. 다른 분기에서 커밋을 배포하려면 고급 배포 모드 웹훅 또는 API 엔드포인트를 사용하면 됩니다. 자세한 내용은 고급 배포 모드 문서 페이지를 참고하세요.

이 섹션에 설명된 선택 항목 대신 Git 구성 버튼이 표시되면 먼저 프로젝트에 Git을 설정해야 합니다.

커밋되지 않은 변경사항 보기

LookML IDE에는 LookML 수정 및 유효성 검사 문서 페이지의 추가, 변경, 삭제 표시 섹션에 설명된 것처럼 개발 모드에서 커밋되지 않은 변경사항이 있는 경우 표시되는 몇 가지 표시기가 있습니다.

Git 작업 패널에서 View 커밋되지 않은 변경사항 보기 옵션을 사용하여 모든 파일에 대한 차이점 요약을 볼 수 있습니다.

프로젝트의 커밋되지 않은 변경사항 창에서 모든 프로젝트 파일에 커밋되지 않고 저장된 모든 변경사항의 요약을 볼 수 있습니다. 각 변경에 대해 Looker에 다음이 표시됩니다.

• 대체된 파일 이름 및 추가된 파일 이름
  • 대체된 파일 이름 (---으로 표시)과 추가된 파일 이름 (+++으로 표시됨)이 표시되는 경우가 많으며, 동일한 파일의 여러 버전이 표시될 수 있으며 버전은 --- a/ 및 +++ b/으로 식별됩니다.
  • 삭제된 파일은 null 파일(+++ /dev/null)을 대체하는 것으로 표시됩니다.
  • 추가된 파일은 null 파일 (--- /dev/null)을 대체하는 것으로 표시됩니다.
• 변경이 시작되는 줄 번호입니다.
  예를 들어 -101,4 +101,4은 파일의 101번째 줄에서 4줄이 삭제되고 4줄이 추가되었음을 나타냅니다. 줄이 20개인 삭제된 파일에는 -1,20 +0,0이 표시되어 파일의 첫 번째 줄에서 20줄이 삭제되고 0줄로 대체되었음을 나타냅니다.
• 업데이트된 텍스트:
  • 삭제된 줄은 빨간색으로 표시됩니다.
  • 추가된 줄이 녹색으로 표시됩니다.

파일 메뉴에서 변경사항 보기 옵션을 선택하여 단일 파일에 대한 차이점 요약을 볼 수도 있습니다.

변경사항 커밋

LookML 프로젝트를 변경하고 저장한 후 IDE에서 LookML의 유효성 검사를 요청할 수 있습니다.

이는 코드 품질 설정에 따라 다릅니다. 콘텐츠 검사기에 관한 자세한 내용은 LookML 검증 문서 페이지를 참고하세요.

내가 마지막으로 로컬 브랜치를 업데이트한 이후 다른 개발자가 production 분기에 변경사항을 적용한 경우, Looker에서는 production 분기에서 업데이트를 가져와야 합니다.

프로젝트에 고급 배포 모드가 사용 설정된 경우 이 버튼은 기본 분기에서 가져오기라고 표시됩니다.

변경사항을 저장하고 (필요한 경우 LookML 경고 또는 오류를 수정) 필요한 경우 프로덕션 환경에서 가져온 경우 (필요한 경우) Git 버튼에 다음 메시지가 표시됩니다.

원하는 경우 먼저 커밋되지 않은 변경사항을 검토한 후 커밋할 수 있습니다.

변경사항을 커밋할 준비가 되면 Commit Changes & Push 버튼을 사용하여 변경사항을 현재 분기에 커밋합니다. 추가, 변경 또는 삭제된 파일이 나열된 다음 창이 표시됩니다.

변경사항을 간략하게 설명하는 메시지를 입력하고 동기화에 포함하지 않을 파일을 선택 해제합니다. 그런 다음 커밋을 클릭하여 변경사항을 커밋합니다.

빌드되지 않은 PDT 확인

프로젝트의 PDT를 변경한 경우 프로덕션으로 배포할 때 테이블을 즉시 사용할 수 있도록 프로덕션에 배포할 때 모든 PDT를 빌드하는 것이 가장 좋습니다. 변경사항을 배포하기 전에 Project Health 패널에서 프로젝트에 빌드되지 않은 PDT가 있는지 확인할 수 있습니다. 프로젝트 상태 아이콘을 클릭한 다음 PDT 상태 확인 버튼을 클릭합니다.

LookML 프로젝트에서 빌드되지 않은 PDT를 확인하는 것과 개발 모드에서 파생된 테이블을 사용하는 방법에 대한 자세한 내용은 Looker의 파생 테이블 문서 페이지를 참조하세요.

데이터 테스트 실행

프로젝트에 LookML 모델의 로직을 확인하기 위한 데이터 테스트가 포함될 수 있습니다. 프로젝트의 데이터 테스트 설정에 대한 자세한 내용은 test 매개변수 문서 페이지를 참조하세요.

데이터 테스트를 실행하려면 개발 모드에 있어야 합니다. 개발 모드에서 여러 가지 방법으로 데이터 테스트를 시작할 수 있습니다.

1. 설정을 프로덕션에 배포하기 전에 데이터 테스트를 통과하도록 프로젝트 설정이 구성되어 있으면 프로젝트 변경사항을 커밋한 후 IDE에서 테스트 실행 버튼을 표시합니다. 이렇게 하면 테스트를 정의하는 파일에 관계없이 프로젝트의 모든 테스트가 실행됩니다. 데이터 테스트에 통과해야 변경사항을 프로덕션에 배포할 수 있습니다.
2. 프로젝트 상태 패널에서 데이터 테스트 실행 버튼을 클릭합니다. 이렇게 하면 테스트를 정의하는 파일에 관계없이 프로젝트의 모든 데이터 테스트가 실행됩니다.
3. 파일 메뉴에서 LookML 테스트 실행 옵션을 선택합니다. 현재 파일에 정의된 테스트만 실행됩니다.

데이터 테스트를 실행하면 Project Health 패널에 진행 상황과 결과가 표시됩니다.

• 테스트의 어설션이 테스트 쿼리의 모든 행에 참일 때 데이터 테스트가 통과됩니다. 테스트 어설션 및 쿼리 설정에 대한 자세한 내용은 test 매개변수 문서 페이지를 참조하세요.
• 데이터 테스트에 실패하면 프로젝트 상태 패널에 테스트 실패 원인, 모델 로직에서 테스트의 오류가 발견되었는지 여부 또는 테스트 자체가 잘못된 테스트인지에 대한 정보가 제공됩니다.
• 데이터 테스트 결과에서 데이터 테스트의 이름을 클릭하여 데이터 테스트용 LookML로 바로 이동하거나 쿼리 살펴보기 버튼을 클릭하여 데이터 테스트에 정의된 쿼리로 탐색을 열 수 있습니다.

프로덕션에 배포하기

브랜치에 변경사항을 커밋하면 Looker IDE에 변경사항을 기본 브랜치에 병합하라는 메시지가 표시됩니다. IDE에 표시되는 메시지 유형은 프로젝트의 구성에 따라 다릅니다.

• 프로젝트가 고급 배포 모드로 구성된 경우 변경사항을 기본 분기에 병합하라는 메시지가 IDE에 표시됩니다. 커밋을 병합하면 deploy 권한이 있는 Looker 개발자는 Looker IDE 배포 관리자를 사용하거나 웹훅 또는 API 엔드포인트를 사용하여 커밋을 프로덕션에 배포할 수 있습니다.
• 프로젝트가 풀 요청을 사용하여 Git 통합으로 구성된 경우 Git 제공업체의 인터페이스를 사용하여 pull 요청을 열라는 메시지가 표시됩니다.
• 그렇지 않으면 기본 Looker Git 통합에서 deploy 권한이 있는 경우 Looker IDE에 변경사항을 프로덕션 브랜치에 병합하고 Looker 인스턴스의 프로덕션 버전에 배포하라는 메시지가 표시됩니다.

고급 배포 모드

기본 Looker Git 통합을 사용하면 Looker 개발자가 개발 브랜치에 변경사항을 커밋한 다음 개발 브랜치를 production 브랜치에 병합합니다. 그런 다음 Looker 환경에 배포하면 Looker가 production 분기의 최신 커밋을 사용합니다. (기본 Git 워크플로 및 고급 Git 구현을 위한 기타 옵션은 이 페이지의 프로덕션에 변경사항 가져오기 섹션을 참고하세요.)

Looker 환경의 프로덕션 브랜치에서 항상 최신 커밋을 사용하지 않으려는 경우 deploy 권한이 있는 개발자는 고급 배포 모드를 사용하여 Looker 환경에 사용할 정확한 커밋을 지정할 수 있습니다. 이는 각 환경이 서로 다른 코드베이스 버전을 가리키는 다중 환경 개발자 워크플로에 유용합니다. 또한 한 명 이상의 개발자 또는 관리자가 프로덕션에 배포된 변경사항을 더 세부적으로 관리할 수 있게 됩니다.

고급 배포 모드를 사용 설정하면 Looker IDE에서 개발자에게 변경사항을 프로덕션으로 배포하라는 메시지가 표시되지 않습니다. 대신 IDE를 통해 개발자는 변경사항을 production 분기에 병합하라는 메시지를 표시합니다. 이후 다음과 같은 방법으로만 변경사항을 배포할 수 있습니다.

• Looker IDE에서 배포 관리자 사용
• 웹훅 트리거
• API 엔드포인트 사용

자세한 내용은 고급 배포 모드 문서 페이지를 참고하세요.

변경사항의 영향 확인

조직에 변경사항을 제공한 후에는 콘텐츠 검증을 사용하여 대시보드 또는 저장된 Look을 무효화하지 않았는지 확인할 수 있습니다. 문제가 있는 경우 이를 수정할 수 있습니다.

일반적인 문제 처리

모델을 사용하는 동안 다음을 수행해야 할 수 있습니다.

• 변경사항 취소

  경우에 따라 데이터 모델링 변경사항을 취소해야 할 수도 있습니다. 아직 저장되지 않은 경우 페이지를 새로고침하거나 페이지에서 나가면 경고 메시지를 수락할 수 있습니다. 변경사항을 저장한 경우 커밋되지 않은 변경사항 되돌리기 섹션에 설명된 대로 커밋되지 않은 변경사항을 되돌릴 수 있습니다.

• 다른 개발자와 병합 충돌 처리

  데이터 모델에 작업하는 개발자가 둘 이상 있는 경우 일반적으로 Git에서 상황을 처리합니다. 그러나 때때로 Git은 병합 충돌을 해결하기 위해 사람이 필요합니다.

필드 이름 변경과 같은 일부 변경사항은 기존 대시보드 및 디자인에 영향을 줄 수 있습니다. 앞서 언급했듯이 변경사항을 조직에 제공한 후에는 콘텐츠 검증을 사용하여 콘텐츠를 확인하고 문제를 해결할 수 있습니다.

커밋되지 않은 변경사항 되돌리기

개인 개발 브랜치에서 작업할 때 배포하지 않으려면 저장한 커밋되지 않은 변경사항을 되돌릴 수 있습니다. 프로젝트의 모든 파일에 커밋되지 않은 모든 변경사항을 되돌리거나 단일 파일의 변경사항만 되돌릴 수 있습니다.

모든 파일의 커밋되지 않은 변경사항을 되돌리려면 다음 안내를 따르세요.

1. Git Actions 패널에서 되돌리기 옵션을 클릭합니다.
2. 되돌리기 옵션을 선택합니다.
   • 커밋되지 않은 변경사항만 되돌리려면 커밋되지 않은 변경사항 되돌리기를 선택합니다. 변경사항 보기 링크를 클릭하여 되돌릴 변경사항을 볼 수도 있습니다.
   • 커밋되지 않은 변경사항 및 커밋된 변경사항을 포함하여 모든 변경사항을 되돌리려면 프로덕션으로 되돌리기를 선택합니다.
3. 되돌리기를 완료하려면 확인을 클릭합니다.

단일 파일 콘텐츠의 추가 또는 삭제 내용을 되돌리려면 파일의 메뉴에서 변경사항 되돌리기 옵션을 선택합니다.

파일 이름을 변경하면 기본적으로 원본 파일이 삭제되고 새 이름으로 새 파일이 생성됩니다. 두 개 이상의 파일이 포함되어 있기 때문에 파일 되돌리기 옵션을 사용하여 파일 이름 변경을 실행취소할 수 없습니다. 파일 이름 변경을 실행취소하려면 Git Actions 패널에서 되돌리기 옵션을 사용하세요.

또한 파일을 삭제하면 IDE 파일 브라우저에 더 이상 파일이 표시되지 않습니다. 파일 삭제를 되돌리려면 Git Actions 패널에서 되돌리기 옵션을 사용하세요.

병합 충돌 해결

일반적으로 Git는 새로운 변경사항을 LookML 파일의 프로덕션 버전과 자동으로 병합할 수 있습니다. Git이 유지할 변경사항을 결정하는 데 문제가 발생하면 병합 충돌이 발생합니다. 일반적으로 내가 마지막으로 가져온 후 다른 개발자가 변경했으며 동일한 영역에서 변경한 경우에 발생합니다. 코드에 병합 충돌이 있는 경우 변경사항을 커밋하고 프로덕션에서 가져온 후 Looker에 경고를 표시합니다.

Looker에서 병합 충돌 경고가 표시되면 추가로 변경하기 전에 병합 충돌을 해결하는 것이 좋습니다. 병합 충돌을 프로덕션으로 푸시하면 파싱 오류가 발생하여 데이터를 탐색할 수 없습니다. 변경사항을 푸시하여 계속 진행하려는 고급 Git 사용자는 해결 안 함 버튼을 클릭합니다.

LookML 파일 자체에서 충돌이 있는 줄은 다음과 같이 표시됩니다.

<<<<<<< HEAD
Your code
&#61;&#61;&#61;&#61;&#61;&#61;&#61;
Production code
>>>>>>> branch 'master'

Looker는 병합 충돌을 나타내기 위해 다음과 같은 병합 마커를 표시합니다.

• <lt;<lt;HEAD>는 충돌하는 선의 시작을 표시합니다.
• >>>> branch 'master'는 충돌하는 선의 끝을 표시합니다.
• ======= 코드는 비교할 수 있도록 각 버전의 코드를 구분합니다.

앞의 예에서 your code는 커밋한 변경사항을 나타내고 production code는 Git가 변경사항을 자동으로 병합할 수 없는 코드를 나타냅니다.

병합 충돌을 해결하려면 다음 안내를 따르세요.

1. 병합 충돌이 있는 파일을 찾습니다. Looker에서 이러한 파일을 빨간색으로 표시합니다. 또는 프로젝트를 검색하여 '<' 또는 'HEAD'와 같은 병합 마커를 찾을 수 있으며 프로젝트의 모든 충돌을 찾을 수 있습니다. Git 작업 패널에 표시되는 병합 경고에서 files 링크를 클릭하여 영향을 받은 파일을 찾을 수도 있습니다.
2. 파일에서 병합 충돌이 있는 줄로 이동하여 보관하지 않으려는 텍스트 버전을 삭제하고 병합 충돌 마커도 모두 삭제합니다.

3. 파일을 저장하고 병합 충돌로 표시된 다른 파일에도 위 단계를 반복합니다.

   팁: 각 병합 마커를 프로젝트에서 검색하여 모든 충돌을 해결했고 모든 병합 마커를 삭제했는지 확인하세요. LookML 파일에서 병합 마커의 모든 인스턴스를 삭제해야 합니다. 이러한 마커는 사용자의 데이터 탐색을 방해하는 파싱 오류를 유발할 수 있습니다.

4. 모든 병합 충돌을 해결하고 프로젝트에서 모든 병합 마커를 삭제한 후에는 변경사항을 커밋하고 프로덕션에 배포합니다.

병합 충돌을 해결하고 해결 방법을 프로덕션으로 푸시했으므로 이제 다른 개발자가 프로덕션 환경에서 가져와 평소와 같이 작업을 계속할 수 있습니다.

Git 가비지 컬렉션

Git 가비지 컬렉션은 불필요한 파일을 정리하고 파일 버전을 압축하여 Git 저장소를 최적화합니다. Looker 인스턴스가 업데이트되거나 재부팅될 때 Git 가비지 컬렉션(git gc)이 자동으로 실행됩니다. git gc을 너무 자주 실행하지 않도록 Looker는 마지막 git gc 이후 30일을 기다린 후 다음 재부팅 시 git gc를 실행합니다.

드물지만 git gc이 실행되는 동안 원격으로 변경사항 푸시 또는 브랜치를 원격으로 푸시할 수 있습니다. Looker에 오류가 표시되면 1~2분 정도 기다린 다음 변경사항을 다시 푸시해 봅니다.