n8n 인스턴스가 Git 리포지터리에 연결된 경우 작업을 Git과 동기화해야 합니다.

이 문서에서는 Git 개념과 용어에 어느 정도 익숙하다고 가정합니다. n8n이 Git과 작동하는 방법에 대한 소개는 Git과 n8n을 참조하세요.

다른 사람의 작업 가져오기#

Git에서 작업을 Pull하려면 메인 메뉴에서 Pull 을 선택하세요.

스크린샷 보기

<figure markdown>
	![메뉴가 닫혀 있을 때 풀 및 푸시 버튼](/_images/source-control-environments/pull-push-menu-closed.png)
	<figcaption>메뉴가 닫혀 있을 때 풀 및 푸시 버튼</figcaption>
</figure>

<figure markdown>
	![메뉴가 열려 있을 때 풀 및 푸시 버튼](/_images/source-control-environments/pull-push-menu-open.png)
	<figcaption>메뉴가 열려 있을 때 풀 및 푸시 버튼</figcaption>
</figure>

n8n은 로컬 변경 사항 덮어쓰기에 대한 경고를 표시할 수 있습니다. Pull and override를 선택하여 로컬 작업을 Git의 콘텐츠로 재정의합니다.

변경 사항에 새 변수 또는 자격 증명 스텁이 포함된 경우 n8n은 사용하기 전에 항목의 값을 채워야 한다고 알립니다.

Pull 시 워크플로 및 자격 증명 소유자가 변경될 수 있음#

Git에서 n8n 인스턴스로 Pull할 때 n8n은 워크플로와 자격 증명을 일치하는 사용자 또는 프로젝트에 할당하려고 시도합니다.

원래 소유자가 사용자인 경우:

동일한 소유자가 두 인스턴스 모두에서 사용 가능한 경우 (이메일이 일치하는 경우) 소유자는 그대로 유지됩니다. 원래 소유자가 새 인스턴스에 없는 경우 n8n은 Pull을 수행하는 사용자를 워크플로 소유자로 설정합니다.

원래 소유자가 프로젝트인 경우:

n8n은 원래 프로젝트 이름과 새 인스턴스의 프로젝트 이름을 일치시키려고 시도합니다. 일치하는 프로젝트가 없으면 n8n은 해당 이름으로 새 프로젝트를 만들고, 현재 사용자를 프로젝트 소유자로 할당하고, 워크플로와 자격 증명을 프로젝트로 가져옵니다.

Pull 시 워크플로 자동 게시#

Pull 시 Auto publish 드롭다운을 사용하여 워크플로를 자동으로 게시하도록 선택할 수 있습니다. 세 가지 모드가 있습니다:

• Off (기본값): 워크플로 게시를 시도하지 않습니다. 워크플로는 현재 로컬 게시 상태를 유지합니다.
• If workflow already published: 이 인스턴스에서 이미 게시된 워크플로만 게시를 시도합니다. 새 워크플로는 게시되지 않습니다.
• On: 새 워크플로를 포함하여 Pull된 모든 워크플로를 게시하려고 시도합니다.

n8n은 자동 게시 설정에 관계없이 아카이브된 워크플로를 자동 게시하지 않습니다.

자동 게시가 활성화된 상태에서 Pull한 후 n8n은 성공적으로 게시된 워크플로와 실패한 워크플로를 보여주는 결과 모달을 표시합니다. 워크플로에 유효성 검사 오류나 누락된 자격 증명이 있는 경우 게시가 실패할 수 있습니다.

자동 게시는 Pull 엔드포인트에서 autoPublish 파라미터를 사용하여 none, published 또는 all 값으로 API를 통해서도 사용할 수 있습니다.

Pull이 짧은 서비스 중단을 유발할 수 있음#

게시된 워크플로에 변경 사항을 Pull하면 n8n이 Pull하는 동안 워크플로를 게시 취소했다가 다시 게시합니다. 이로 인해 워크플로에 몇 초의 다운타임이 발생할 수 있습니다.

작업을 Git으로 보내기#

Git에 작업을 푸시하려면:

1. 메인 메뉴에서 푸시 를 선택합니다.

   --8<-- "_snippets/source-control-environments/push-pull-menu-state.md"

2. 변경 사항 커밋 및 푸시 모달에서 푸시할 워크플로우와 데이터 테이블을 선택합니다. 상태(신규, 수정됨, 삭제됨)로 필터링하거나 항목을 검색할 수 있습니다. n8n은 태그, 변수 및 자격 증명 스텁을 자동으로 푸시합니다.

   n8n은 워크플로우의 게시된 버전이 아닌 현재 저장된 버전을 푸시합니다. 이후 원격 서버에서 별도로 버전을 게시해야 합니다.

3. 커밋 메시지를 입력합니다. 변경 사항을 한 문장으로 간략히 설명해야 합니다.

4. 커밋 및 푸시를 선택합니다. n8n이 작업을 Git으로 전송하고 완료 시 성공 메시지를 표시합니다.

커밋되는 것#

n8n은 다음을 Git에 커밋합니다:

• 워크플로 (태그 및 워크플로 소유자 이메일 주소 포함). 어떤 워크플로를 Push할지 선택할 수 있습니다.
• 자격 증명 스텁 - ID, 이름 및 유형. 다른 필드는 표현식인 경우에만 포함됩니다. 어떤 자격 증명을 Push할지 선택할 수 있습니다.
• 변수 스텁 (ID 및 이름)
• 데이터 테이블 스키마 (테이블 이름과 열 정의, 행 데이터는 제외). 어떤 데이터 테이블을 Push할지 선택할 수 있습니다.
• 프로젝트
• 폴더

병합 동작 및 충돌#

n8n의 소스 컨트롤 구현은 의견이 있습니다. 자격 증명 및 변수에 대한 병합 충돌을 자동으로 해결합니다. n8n은 워크플로의 충돌을 감지할 수 없습니다.

워크플로#

Push하거나 Pull할 때 워크플로에 대해 어떻게 할지 명시적으로 n8n에 알려야 합니다. Git 리포지터리가 신뢰의 원천으로 작동합니다.

Pull할 때 워크플로의 로컬 사본이 Git과 다르다는 경고를 받을 수 있으며, 수락하면 로컬 사본이 재정의됩니다. Pull 시 관련 변경 사항을 잃지 않도록 주의하세요.

Push할 때 로컬 워크플로가 Git에 있는 내용을 재정의하므로 최신 버전인지 확인하세요. 그렇지 않으면 최근 변경 사항을 재정의할 위험이 있습니다.

위에서 설명한 문제를 방지하려면 워크플로 작업이 완료되는 즉시 변경 사항을 Push해야 합니다. 그런 다음 안전하게 Pull할 수 있습니다.

데이터 손실을 피하려면:

• 소스 컨트롤 설정이 워크플로가 한 방향으로 흐르도록 설계하세요. 예를 들어 개발 인스턴스에서 편집하고, Git에 Push한 다음, 프로덕션으로 Pull합니다. 프로덕션 인스턴스에서 편집하고 Push하지 마세요.
• 모든 워크플로를 Push하지 마세요. 필요한 것만 선택하세요.
• Git 리포지터리의 파일을 수동으로 편집할 때 주의하세요.

자격 증명, 변수 및 워크플로 태그#

자격 증명과 변수는 n8n이 보존할 버전을 선택하므로 병합 문제가 있을 수 없습니다.

Pull 시:

• 태그, 변수 또는 자격 증명이 존재하지 않으면 n8n이 생성합니다.
• 태그, 변수 또는 자격 증명이 이미 있으면 n8n이 업데이트하지 않습니다. 단 다음 경우는 예외입니다:
  • API 또는 외부에서 변수 값을 설정한 경우. 새 값이 기존 값을 덮어씁니다.
  • 자격 증명 이름이 변경된 경우. n8n은 Git의 버전을 사용합니다.
  • 태그 이름이 변경된 경우. n8n이 태그 이름을 업데이트합니다. 태그 이름을 변경할 때 주의하세요. 태그 이름은 고유하며 Pull 과정에서 고유성에 관한 데이터베이스 문제가 발생할 수 있습니다.

Push 시:

• n8n은 전체 변수 및 태그 파일을 덮어씁니다.
• 자격 증명이 이미 있으면 n8n이 변경 사항으로 덮어쓰지만, Pull 시 기존 자격 증명에는 이러한 변경 사항을 적용하지 않습니다.

데이터 테이블#

n8n은 환경 전반에 걸쳐 데이터 테이블 스키마(테이블 구조 및 열 정의)를 동기화합니다. 행 데이터는 동기화되지 않습니다.

Push 시:

• 포함할 데이터 테이블을 선택할 수 있습니다.
• n8n은 테이블 이름, 열 이름, 열 유형 및 열 순서를 내보냅니다.

Pull 시:

• n8n은 로컬에 존재하지 않는 새 데이터 테이블을 만듭니다.
• 기존 데이터 테이블의 경우 n8n은 Git의 버전과 일치하도록 스키마를 업데이트합니다. 여기에는 새 열 추가 및 원격 버전에 더 이상 존재하지 않는 열 제거가 포함됩니다.