브랜치 패턴

소스 컨트롤로 가능한 n8n 인스턴스와 Git 브랜치 간의 다양한 관계를 이해합니다.

n8n 인스턴스와 Git 브랜치 간의 관계는 유연합니다. 필요에 따라 다양한 설정을 만들 수 있습니다. 권장 사항: 동일한 n8n 인스턴스에 푸시와 풀을 동시에 사용하지 마세요 인스턴스에서 브랜치로 작업을 푸시하고, 같은 인스턴스로 풀하는 것이 가능하지만 n8n은 이를 권장하지 않습니다. 머지 충돌과 작업 덮어쓰기 위험을 줄이기 위해, 작업이 한 방향으로만 흐르는 프로세스를 만드세요: Git으로 가거나, Git에서 오거나, 둘 다는 아닙니다. 다중 인스턴스, 다중 브랜치 # 이 패턴은 각각 자체 브랜치에 연결된 여러 n8n 인스턴스를 갖는 것을 포함합니다. 이 패턴을 환경에 사용할 수 있습니다. 예를 들어 개발 및 프로덕션의 두 n8n 인스턴스를 만듭니다. 각자의 브랜치에 연결합니다. 개발 인스턴스에서 개발 브랜치로 작업을 Push하고, Pull request를 통해 프로덕션 브랜치로 작업을 이동한 다음, 프로덕션 인스턴스로 Pull합니다. 이 패턴의 장점은 다음과 같습니다: 실수로 변경 사항이 프로덕션 환경에 적용되는 것을 방지하는 추가 안전 레이어가 생깁니다. 환경 간에 작업을 복사하려면 GitHub에서 풀 리퀘스트를 수행해야 합니다. 두 개 이상의 인스턴스를 지원합니다. 단점은 환경 간에 작업을 복사할 때 수동 단계가 더 많다는 점입니다. 다중 인스턴스, 단일 브랜치 # 동일한 워크플로, 태그 및 변수를 모든 곳에 두고 싶지만 다른 n8n 인스턴스에서 사용하고 싶을 때 이 패턴을 사용하세요. 이 패턴을 환경에 사용할 수 있습니다. 예를 들어 개발 및 프로덕션의 두 n8n 인스턴스를 만듭니다. 두 인스턴스를 동일한 브랜치에 연결합니다. 개발에서 작업을 Push하고 프로덕션으로 Pull합니다. 이 패턴은 n8n의 새 버전을 테스트할 때도 유용합니다: 새 버전의 새 n8n 인스턴스를 만들고 Git 브랜치에 연결하고 테스트할 수 있으며, 프로덕션 인스턴스는 업그레이드가 안전하다고 확신할 때까지 이전 버전에 남아있습니다. 이 패턴의 장점은 한 인스턴스에서 푸시하면 작업이 다른 환경에 즉시 제공된다는 점입니다. 단점은 다음과 같습니다: 실수로 푸시하면 프로덕션 인스턴스에 작업이 반영될 위험이 있습니다. GitHub Action을 사용하여 풀을 자동화 하도록 설정한 경우, 멀티 인스턴스 멀티 브랜치 패턴을 사용하거나, 프로덕션에 반영하고 싶지 않은 작업은 절대 푸시하지 않도록 주의해야 합니다. 동일한 인스턴스에 푸시와 풀을 동시에 사용하면 이러한 작업 수행 시 변경 사항이 덮어씌워져 데이터 손실이 발생할 수 있습니다. 콘텐츠가 한 방향으로만 흐르도록 프로세스를 설정해야 합니다. 단일 인스턴스, 다중 브랜치 # 인스턴스 소유자는 인스턴스에 연결하는 Git 브랜치를 변경할 수 있습니다. 이 경우의 전체 설정은 다중 인스턴스, 다중 브랜치 패턴일 가능성이 높지만, 하나의 인스턴스가 브랜치 사이를 전환합니다. 이것은 작업을 검토하는 데 유용합니다. 예를 들어 다른 사용자들이 자체 인스턴스에서 작업하고 자체 브랜치로 Push할 수 있습니다. 검토자는 검