브랜치 패턴#

n8n 인스턴스와 Git 브랜치 간의 관계는 유연합니다. 필요에 따라 다양한 설정을 만들 수 있습니다.

권장 사항: 동일한 n8n 인스턴스에서 푸시와 풀을 동시에 수행하지 마세요.

n8n 인스턴스에서 브랜치로 작업을 푸시하고, 같은 인스턴스로 다시 풀하는 것은 가능하지만, 권장되지 않습니다.
병합 충돌 및 작업 덮어쓰기를 방지하려면 한 방향으로만 작업을 진행하는 프로세스를 만들 것을 권장합니다. 즉, Git으로 푸시하거나 Git에서 가져오되, 두 작업을 동시에 수행하지 않는 것이 좋습니다.

여러 인스턴스, 여러 브랜치#

이 패턴은 여러 개의 n8n 인스턴스를 두고 각 인스턴스가 고유한 브랜치에 연결되는 것을 포함합니다.

이 패턴은 환경에 사용할 수 있습니다. 예를 들어, 개발과 운영 두 개의 n8n 인스턴스를 생성합니다. 각 인스턴스를 자신의 브랜치에 연결합니다. 개발 인스턴스에서 작업을 하고 이를 브랜치에 푸시한 다음, 운영 브랜치로 작업을 이동하기 위해 풀 리퀘스트를 생성하고, 운영 인스턴스로 풀 합니다.

이 패턴의 장점:

프로덕션 환경에 변경 사항이 실수로 반영되는 것을 방지하는 추가적인 안전 장치가 됩니다.
환경 간 작업을 복사하려면 GitHub에서 풀 리퀘스트를 수행해야 합니다.
두 개 이상의 인스턴스를 지원할 수 있습니다.

단점:

환경 간 작업을 복사하는 과정에서 수동 작업이 더 많이 필요합니다.

여러 인스턴스, 하나의 브랜치#

이 패턴은 모든 곳에서 동일한 워크플로, 태그 및 변수를 원하지만 서로 다른 n8n 인스턴스에서 사용하고 싶을 때 사용합니다.

이 패턴은 환경에 사용할 수 있습니다. 예를 들어, 개발과 운영 두 개의 n8n 인스턴스를 생성합니다. 두 인스턴스를 동일한 브랜치에 연결합니다. 개발에서 작업을 푸시하고, 운영으로 가져옵니다.

이 패턴은 n8n의 새 버전을 테스트할 때도 유용합니다: 새 버전으로 새로운 n8n 인스턴스를 생성하고 Git 브랜치에 연결하여 테스트할 수 있으며, 운영 인스턴스는 안전하게 업그레이드할 수 있다고 확신할 때까지 이전 버전을 유지합니다.

이 패턴의 장점은 한 인스턴스에서 푸시하면 다른 환경에서도 즉시 작업을 사용할 수 있다는 것입니다.

하지만 다음과 같은 단점이 있습니다:

실수로 푸시하는 경우, 해당 작업이 프로덕션 인스턴스로 반영될 위험이 있습니다.
GitHub Action을 사용하여 자동으로 풀하도록 설정한 경우, 다중 인스턴스 및 다중 브랜치 패턴을 사용하거나, 프로덕션에 반영하고 싶지 않은 작업을 실수로 푸시하지 않도록 주의해야 합니다.
동일한 인스턴스에서 푸시와 풀을 수행하면, 변경 사항이 덮어씌워지면서 데이터 손실이 발생할 수 있습니다.
작업 흐름이 한 방향으로만 진행되도록 프로세스를 설정하는 것이 좋습니다.

하나의 인스턴스, 여러 브랜치#

인스턴스 소유자는 어떤 Git 브랜치가 인스턴스에 연결되는지를 변경할 수 있습니다. 이 경우 전체 설정은 여러 인스턴스, 여러 브랜치 패턴일 가능성이 높지만, 하나의 인스턴스가 브랜치 간 전환하는 방식입니다.

이는 작업 검토에 유용합니다. 예를 들어, 서로 다른 사용자들이 자신의 인스턴스에서 작업하고 자신의 브랜치에 푸시할 수 있습니다. 검토자는 검토 인스턴스에서 작업하여 브랜치 간 전환하여 서로 다른 사용자로부터의 작업을 로드할 수 있습니다.

정리 없음

n8n은 브랜치를 변경할 때 인스턴스의 기존 내용을 정리하지 않습니다. 이 패턴에서 브랜치를 전환하면 각 브랜치의 모든 워크플로가 인스턴스에 남게 됩니다.

하나의 인스턴스, 하나의 브랜치#

가장 간단한 패턴입니다.