4

우리는 WordPress 웹 사이트 개발의 버전 관리를 위해 Mercurial을 사용할 계획입니다.Mercurial을 사용하는 WordPress 개발. 전체 트리 또는 하위 리포지토리 모음?

WordPress의 개발 모델은 플러그인 및 테마의 기본 루트에서 몇 개의 하위 디렉토리에 개발이 이루어 지지만 주 루트는 WordPress 버전 업데이트를 통해 변경 될 수 있으며 버전 제어가 필요하지 않습니다.

내 상황은 위의 하위 디렉토리가 제어하에 있거나 VC에서 메인 WordPress 코드를 제거하기 위해 hgignore를 사용하여 루트에있는 저장소로 관리하는 것이 가장 좋습니다. 또는 디렉토리에 뿌리를 둔 몇 개의 하위 저장소 개발이 진행되는 곳과 래퍼 상위 저장소가 함께 참여할 수 있습니까?

각 접근법의 장단점 및 배포 효과는 무엇입니까?

새 서버를 처음으로 가져 왔을 때 두 번째 접근법 (하위 리포지토리)을 사용하면 개발 디렉토리가 WordPress 트리 내에서 올바른 위치에 생성됩니까?

+2

또 다른 가능성은 워드 프레스를 의존성 (합리적)으로 생각하고 컴포저와 같은 것을 사용하는 것입니다. (그러면 새로운 서버를 구축하는 프로세스의 일부가 될 수도 있습니다.) 슬프게도, 올바른 방향으로 향하고 있지만 , 그것은 여전히 ​​[다소 fiddly] (http://roots.io/using-composer-with-wordpress/)입니다. (덧붙여 말하면, roots.io 사이트의 [12 Factor WordPress] (http://roots.io/twelve-factor-wordpress/) 게시물은 WordPress를 레슬링하여 [ 현대 개발 실무] (https://github.com/roots/bedrock). –

+0

대단히 감사합니다. Matt, 거기에 몇 가지 유용한 포인터가 있습니다. Mark Jaquith의 WordPress Skeleton [여기] (https://github.com/markjaquith/WordPress-Skeleton)을 발견했으나 근본적인 프레임 워크는 진화 또는 2 가지로 보입니다. – RSA99

답변

1

일반적으로 유지하고자하는 소스 코드 만 제어하는 ​​버전을 권장합니다. Git을 사용하여, 나는 이전에 좋은 결과를 가진 테마/플러그인 당 하나의 저장소를 수행했다. 부모/자식 테마 관계를 제외하면 WordPress 테마는 어느 정도 완전히 서로 독립적입니다. 각 테마는 논리적으로 분리되어 있기 때문에 버전을 별도의 엔티티로 제어하는 ​​것이 좋습니다.

어떤 시점에서 한 테마에 대한 업데이트를 푸시하고 다른 업데이트는 푸시하지 않는 것이 좋습니다. 별도의 저장소가 있으면 모든 다른 테마의 변경 사항을 쉽게 체크인 할 수 있지만 한 번에 하나씩 만 변경 사항을 게시 할 수 있습니다. 브랜치를 사용하여 동일한 결과를 얻을 수 있지만 소수 이상의 주제가 있으면 매우 복잡 할 수 있습니다.

확실히, 그것은 편안함에 크게 좌우되지만, 50 개 이상의 테마로 설치를 관리하는 경험에서, 가장 쉬운 방법이었습니다.

+0

감사합니다. 꽤 많은 연구가 끝난 후에 내가 언급 한 많은 아이디어를 구현 한 WordPress-Skeleton [여기] (https://github.com/markjaquith/WordPress-Skeleton)을 발견했습니다. 또한 WordPress 개발을 21 세기로 가져 왔던 분야의 원동력이 사용하고있는 것보다 더 많이 보인 것처럼 Git으로 전환했습니다. – RSA99

+0

답변으로 답변을 수락하고 있지만 위의 Matt Gibson의 답변과 WordPress 기반 프레임 워크에 대한 정보를 독자들에게도 알립니다. – RSA99