버전 제어 사용 및 배포

이 페이지에서는 프로젝트가 이미 버전 제어용으로 설정되어 있다고 가정합니다. 이 페이지에 설명된 옵션 대신 Git 구성 버튼이 표시되면 먼저 프로젝트에 Git를 설정해야 합니다.

Looker는 Git를 사용해서 변경사항을 기록하고 파일 버전을 관리합니다. 각 LookML 프로젝트는 Git 저장소에 해당하며 각 개발자 브랜치는 Git 브랜치와 상관관계가 있습니다.

Looker는 GitHub, GitLab, Bitbucket과 같은 여러 Git 제공업체와 호환되도록 구성할 수 있습니다. Looker 프로젝트에 Git를 설정하는 방법에 대한 자세한 내용은 Git 연결 설정 및 테스트 문서 페이지를 참고하세요.

Git 브랜치 다루기

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

Git의 또 다른 주요 기능은 다른 개발자와 손쉽게 공동작업할 수 있다는 점입니다. 브랜치를 만들고 원하는 경우 변경할 수 있으며, 다른 개발자는 해당 브랜치로 전환하여 브랜치를 검토하거나 변경할 수 있습니다. 다른 개발자가 브랜치에 변경사항을 커밋하면 Looker에 원격 변경사항 가져오기 버튼이 표시됩니다. 추가로 변경하려면 먼저 커밋된 변경사항을 브랜치로 가져와야 합니다.

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

개인 브랜치

개발 모드에 처음 들어가면 Looker가 개인 Git 브랜치를 자동으로 만듭니다. 개인 브랜치는 dev-로 시작하고 개발자의 이름이 포함됩니다.

개인 브랜치는 개발자별로 자별로 할당되고 삭제할 수 없습니다. 개인 브랜치는 다른 모든 개발자에게는 읽기 전용입니다. 프로젝트의 다른 개발자와 공동작업하는 경우에는 다른 브랜치로 전환하여 변경사항을 적용할 수 있도록 새 브랜치를 만들어야 할 수 있습니다.

새 Git 브랜치 만들기

다른 개발자와의 공동작업 없이 간단한 수정 작업을 하는 경우, 일반적으로 개인 브랜치에서 작업하는 것이 좋습니다. 개인 브랜치를 사용하여 빠르게 업데이트한 다음 변경사항을 커밋하고 프로덕션으로 푸시할 수 있습니다.

하지만 개인 브랜치 외에도 새로운 Git 브랜치를 만들 수도 있습니다. 다음과 같은 경우 새 Git 브랜치가 적합합니다.

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

새 브랜치를 만들기 전에 다음을 수행합니다.

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

새 Git 브랜치를 만들려면 다음 안내를 따르세요.

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

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

  3. 왼쪽 아이콘 메뉴에서 Git 아이콘을 선택하여 Git 작업 패널을 엽니다.

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

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

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

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

  8. 만들기를 선택하여 브랜치를 만듭니다.

또는 프로젝트 설정의 브랜치 관리 탭에서 Git 브랜치를 만들 수 있습니다.

Git 브랜치 이름 지정 규칙

Looker는 Git에서 지정한 브랜치 이름 지정 규칙 요구사항을 사용합니다.

Git 브랜치 이름은 다음에 해당하지 않아야 합니다.

  • 공백 문자 포함
  • 마침표 두 개(..) 포함
  • 백슬래시(\) 포함
  • 시퀀스(@{) 포함
  • 물음표(?) 포함
  • 여는 대괄호([) 포함
  • ASCII 제어 문자(~ 또는 \^ 또는 :) 포함
  • 마침표로(.)로 시작
  • dev- 접두사로 시작(Looker 개발자의 개인 브랜치용으로 예약됨)
  • 슬래시(/)로 끝남
  • .lock 확장자 끝남

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

다른 Git 브랜치로 전환

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

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

다른 Git 브랜치로 전환하려면 다음 단계를 따르세요.

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

Git 브랜치 관리

프로젝트 설정의 브랜치 관리 탭에는 Looker 프로젝트의 모든 Git 브랜치 테이블이 표시됩니다. 브랜치 관리 탭을 열려면 먼저 왼쪽 아이콘 메뉴에서 설정 아이콘을 선택하여 프로젝트 설정 페이지로 이동합니다. 그런 다음 브랜치 관리 탭을 선택합니다.

브랜치 관리 탭에서 다음을 수행할 수 있습니다.

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

테이블에는 다음 정보가 포함됩니다.

  • 이름: Git 브랜치 이름입니다. Looker 개발자의 개인 브랜치는 dev-로 시작하고 개발자의 성과 이름이 포함됩니다.
  • 상태: 브랜치의 로컬 버전과 브랜치의 원격 버전 간의 차이입니다. 예를 들어, 3 commits behind 상태는 브랜치의 로컬 버전이 브랜치의 원격 버전보다 커밋 3회 뒤쳐지는 것을 의미합니다. Looker는 항상 마스터의 원격 버전을 사용하므로 브랜치 관리 탭에는 마스터 브랜치의 로컬 버전 상태가 표시되지 않습니다. 마스터 브랜치는 항상 최신 상태로 간주할 수 있습니다.
  • 최종 업데이트: Looker 개발자가 브랜치에 커밋한 후 경과된 시간입니다.
  • 작업: 브랜치를 삭제하는 버튼이거나 브랜치를 삭제할 수 없는 이유입니다.

Git 브랜치 삭제

브랜치 관리 탭에서 테이블에 삭제 버튼이 있는 브랜치를 삭제할 수 있습니다. 다음 브랜치는 삭제할 수 없습니다.

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

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

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

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

  1. 먼저 브랜치 체크박스를 선택한 다음 선택한 브랜치 삭제를 선택하여 여러 브랜치를 삭제합니다.
  2. 브랜치 이름 옆에 있는 삭제를 선택하여 단일 브랜치를 삭제합니다.

Looker에서 Git 명령어 실행

Looker에는 Git 서비스와 통합되는 기본 제공 인터페이스가 포함되어 있습니다. Looker에서 LookML IDE의 오른쪽 상단에 Git 버튼을 표시합니다.

Git 버튼에는 변경 및 프로덕션 배포의 현재 위치에 따라 다양한 옵션이 표시됩니다. 일반적으로 버튼에 표시된 옵션이 다음 작업을 위한 가장 좋은 가이드입니다.

개발자 브랜치가 프로덕션 브랜치와 동기화된 경우 Git 버튼에 최신 메시지가 표시되며 이는 선택할 수 없습니다.

프로젝트가 Git에 구성되면 Git 작업 버튼을 선택하여 Git 작업 패널을 열 수 있습니다.

Git 작업 패널에서 사용할 수 있는 명령어는 변경사항 및 프로덕션 배포의 현재 위치에 따라 다릅니다.

프로덕션에 변경사항 적용

기본 Looker Git 통합을 사용하면 Looker에서 개발자에게 다음과 같은 Git 워크플로를 안내합니다.

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

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

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

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

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

Looker IDE 개요 문서 페이지의 추가, 변경사항, 삭제 표시 섹션에 설명된 대로 LookML IDE에는 개발자가 개발 모드에있고 커밋되지 않은 변경 사항이 있음을 나타내는 여러 표시기가 있습니다.

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

프로젝트의 커밋되지 않은 변경사항 창에서 Looker는 모든 프로젝트 파일의 모든 커밋되지 않은 저장된 변경사항에 대한 요약을 표시합니다. 각 변경사항에 대해 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을 검증해야 할 수 있습니다. 이 시나리오에서 Git 버튼에는 LookML 검증 텍스트가 표시됩니다.

이 작업이 필요한지 여부는 프로젝트의 코드 품질 설정에 따라 다릅니다. 콘텐츠 검사기에 대한 자세한 내용은 LookML 유효성 검사 문서 페이지를 참조하세요.

로컬 브랜치를 마지막으로 업데이트한 후 다른 개발자가 프로덕션 브랜치를 변경한 경우 Looker를 통해 프로덕션 브랜치에서 업데이트를 가져와야 합니다. 이 시나리오에서는 Git 버튼에 프로덕션에서 가져오기 텍스트가 표시됩니다.

프로젝트에 고급 배포 모드가 사용 설정된 경우, Git 버튼에는 기본 브랜치에서 가져오기 텍스트가 대신 표시됩니다.

변경사항을 저장하고(필요한 경우 LookML 경고 또는 오류도 수정) 프로덕션에서 가져온 경우(필요한 경우) Git 버튼에 변경사항 커밋 및 푸시 텍스트가 표시됩니다.

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

변경사항을 커밋할 수 있으면 Git 버튼을 사용하여 변경사항을 현재 브랜치에 커밋합니다. Looker에 추가, 변경 또는 삭제된 파일이 나열된 커밋 대화상자가 표시됩니다.

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

빌드되지 않은 PDT 확인

프로젝트에서 PDT를 변경한 경우 프로덕션 버전으로 테이블을 즉시 사용할 수 있도록 프로덕션에 배포할 때 모든 PDT를 빌드하는 것이 가장 좋습니다. 프로젝트에서 PDT의 상태를 확인하려면 프로젝트 상태 아이콘을 선택하여 프로젝트 상태 패널을 연 다음 PDT 상태 유효성 검사 버튼을 선택합니다.

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

데이터 테스트 실행

프로젝트에는 LookML 모델의 논리를 확인하기 위해 데이터 테스트를 정의하는 하나 이상의 test 파라미터가 포함될 수 있습니다. 프로젝트의 데이터 테스트 설정에 대한 자세한 내용은 test 파라미터 문서 페이지를 참조하세요.

프로젝트에 데이터 테스트가 포함되어 있고 개발 모드에 있는 경우 다음과 같은 여러 가지 방법으로 프로젝트의 데이터 테스트를 시작할 수 있습니다.

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

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

  • 테스트의 어설션이 테스트 쿼리의 모든 행에 대해 true이면 데이터 테스트가 통과합니다. 테스트 어설션 및 쿼리 설정에 대한 자세한 내용은 test 파라미터 문서 페이지를 참조하세요.
  • 데이터 테스트에 실패하면 프로젝트 상태 패널에 테스트가 실패한 이유, 테스트에서 모델의 로직에서 오류가 발견되었는지 또는 테스트 자체가 잘못되었는지에 대한 정보가 제공됩니다.
  • 데이터 테스트 결과에서 데이터 테스트 이름을 선택하여 데이터 테스트를 위한 LookML로 직접 이동하거나 쿼리 탐색 버튼을 선택하여 데이터 테스트에서 정의된 쿼리로 Explore를 열 수 있습니다.

프로덕션에 배포하기

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

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

고급 배포 모드

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

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

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

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

  • API 엔드포인트 사용

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

변경사항이 미치는 영향 확인

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

일반적인 문제 처리

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

  • 변경사항 취소

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

  • 다른 개발자의 작업과의 병합 충돌 처리

    데이터 모델을 작업하는 개발자가 두 명 이상인 경우 일반적으로 Git가 이 상황을 처리합니다. 하지만 Git에서 병합 충돌을 해결하는 데 사람이 필요한 경우가 있습니다.

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

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

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

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

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

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

파일 이름을 변경하면 기본적으로 원래 파일을 삭제하고 새 이름으로 새 파일을 생성하게 됩니다. 이 작업은 파일이 두 개 이상 관련되기 때문에 파일 되돌리기 옵션을 사용하여 파일 이름 바꾸기를 실행취소할 수 없습니다. 파일 이름 변경을 실행취소하려면 Git 작업 패널에서 다음으로 되돌리기... 옵션을 사용하세요.

또한 파일을 삭제한 경우 파일이 더 이상 IDE 파일 브라우저에 표시되지 않습니다. 파일 삭제를 되돌리려면 Git 작업 패널에서 다음으로 되돌리기... 옵션을 사용합니다.

병합 충돌 해결

일반적으로 Git는 새 변경사항을 LookML 파일의 프로덕션 버전과 자동으로 병합할 수 있습니다. 병합 충돌은 Git에서 충돌하는 변경사항이 발생하고 어떤 변경사항을 유지해야 하는지 식별할 수 없을 때 발생합니다. 일반적으로 마지막으로 가져온 이후에 다른 개발자가 변경한 사항이 있고 동일한 영역에서 변경사항을 적용했을 때 발생합니다. 코드에 병합 충돌이 발생하면 변경사항을 커밋하고 프로덕션에서 가져온 후 Looker에 병합 충돌 경고가 표시됩니다.

Looker에 병합 충돌 경고가 표시되면 추가 변경사항을 적용하기 전에 병합 충돌을 해결하는 것이 좋습니다. 프로덕션에 병합 충돌을 푸시하면 파싱 오류가 발생하여 데이터 탐색 분석을 방해할 수 있습니다. 고급 Git 사용자로서 변경사항을 푸시하는 경우 해결하지 않음 버튼을 선택하세요.

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

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

Looker는 병합 충돌을 나타내는 다음 병합 마커를 표시합니다.

  • <<<<<<< HEAD는 충돌하는 행의 시작을 표시합니다.
  • >>>>>>> branch 'master'는 충돌하는 행의 끝을 표시합니다.
  • =======은 코드의 각 버전을 분리하여 비교할 수 있게 해줍니다.

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

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

  1. 병합 충돌이 있는 파일을 찾습니다. Looker에서는 이러한 파일을 빨간색으로 표시합니다. 직접 <<<< 또는 HEAD 같은 병합 마커로 프로젝트 검색하여 프로젝트의 모든 충돌을 확인할 수도 있습니다. Git 작업 패널에 표시되는 병합 경고에서 파일 링크를 선택하여 영향을 받는 파일을 찾을 수도 있습니다.
  2. 파일에서 병합 충돌이 발생한 줄로 이동하여 유지하지 않을 텍스트 버전을 삭제하고 모든 병합 충돌 마커도 삭제합니다.

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

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

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

Git 가비지 컬렉션

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

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