'drush rsync'대 'git'을 사용하여 스테이징 개발-> 생산의 장점은 무엇입니까?

개발 작업을 위해 git control 하에서 Drupal 사이트를 설정했습니다.

마스터, 베어 GIT 리포지토리의 부모이며 다양한 프로젝트 작업 git 복제본에서 변경 사항이 적용되고 마스터로 다시 푸시되면 업데이트 후 후크가 즉시 변경 사항을 단일 라이브 스테이징 웹 사이트 (http : / /staging.loc.). 특별한 것은 없으며 예상대로 작동합니다.

또한 사이트 "@STAGING"을 서서히 처리했습니다. 경우에 따라 변경 사항을 준비 사이트에서 프로덕션 서버로 승격시키고 싶습니다.

비교적 간단한 두 가지 방법이 떠 오릅니다.

(1) 준비 사이트가 안정적으로 보이는 시점에 마스터 리포지토리에서 git checkout으로 프로덕션 사이트를 만듭니다.

(2) 준비 사이트에서 프로덕션 사이트로 drush rsync+ drush sql-sync를 사용 하십시오.

둘 다 작동하도록 만들 수 있습니다. (2) 본질적으로 Drupal 중심 / 인식이 더 많이 보인다는 사실 외에, 결국 Drush는 Drupal 전용 툴 세트입니다. 두 접근 방식의 상대적인 장점은 무엇입니까?

(1) 이상 (2)를 고려해야하는 특별한 이유가 있습니까?

두 경우 모두 "Everything"이 하나 이상의 개정 제어 인스턴스에 해당합니다 ...

나는 두 가지 기술을 모두 사용했다. 둘 다 @stage에서 테스트 한 동일한 파일이 @live로 끝나는 것을 보장하는 데 사용할 수 있습니다. rsync의 장점은 프로덕션 서버에서 추가 파일 (예 : ".git"및 관련)을 끝내지 않는다는 것입니다. 나는 vps와 재 동기화하는 경향이 있고 내가 소유 한 상자 (예 : 인트라넷 사이트)에서 git을 사용한다.

drush rsync를 사용할 때의 문제점은 여러 사람이 서버에 변경 사항을 푸시하는 경우입니다.

귀하의 예는 한 사람 만 변화를 추진하는 것을 보여줍니다.

개발자 A가 변경 사항을 푸시하고 개발자 B가 변경 사항을 푸시하면 git이 충돌을 해결하거나 개발자 B가 충돌을 해결하도록하십시오.

나는 실제로 둘 다 사용합니다. svn / git과 rsync는 서로 다른 두 가지 용도로 사용됩니다. SVN / 자식 소스 제어위한, rsync그리고 sql-sync효율적으로 준비 자극 및 동기화를위한 것이다. drush rsync @staging @prod단순성 측면에서 극복하기가 매우 어렵고 continuous Integration코드 품질 문제 / 방법론을 더 깊이 익히고 싶다면 대부분의 환경 에 쉽게 통합 할 수 있습니다.

개인적으로 Git을 사용하여 버전 제어, 배포 및 다양한 서버 코드베이스 동기화 및 rsync를 사용하여 사용자 파일 이동 / 동기화 (.gitignore 파일에 특정 경로를 추가하여 무시).