버전 제어 시스템의 역할에 대해 혼란스러워합니다. 실행중인 웹 사이트를위한 백업 시스템이 아니어야합니다. 정적 컨텐츠를 관리하는 훌륭한 작업을 수행하여 제어 된 방식으로 프로덕션으로 이동합니다. 태그 지정 및 자동 체크 아웃을 올바르게 사용하면 빠르게 변경되는 사이트도 버전 관리 시스템에 유지할 수 있습니다.
버전 관리 시스템은 지난 달 사이트의 모습에서 오늘의 모습 (최소한 소스 제어를받는 구성 요소의 경우)에 대한 정보를 제공합니다. 웹 사이트를 재 구축하는 데 필요한 모든 것을 포함해야합니다 (동적 콘텐츠 제외). 다른 사람들이 지적했듯이, 사용 권한 및 소유권에 대한 변경 사항은 스크립팅되어야하며 해당 스크립트는 버전 관리에 포함됩니다.
웹 사이트에 대한 액세스 권한은 일반적으로 매우 간단합니다. (기본적으로, 웹 서버가 모든 내용을 읽고 거의 쓸 수 없도록해야합니다.) 웹 서버 서브 버전에 의해 쓰기 가능해야하는 몇몇 디렉토리의 디렉토리 소유권을 제외하고, 아마도 git은 권한을 처리합니다. 웹 서버에서 쓸 수있는 디렉토리에는 일반적으로 웹 사이트 소스와 별도로 관리되는 동적 컨텐츠 (웹 사이트에서 작성 및 업데이트)가 포함됩니다.
웹 사이트에서 복잡한 권한 및 ACL을 가진 웹 사이트를 사용하도록 요청받은 경우 웹 사이트를 관리하는 데 사용되는 프로세스에 대해 심각한 우려가 있습니다. 버전 제어 시스템을 구현하고 ACL을이 시스템으로 옮기는 것이 제가 진지하게 고려해야 할 솔루션 중 하나입니다.
블로그 항목 또는 주석과 같은 동적 컨텐츠는 일반적으로 사이트를 빌드하는 데 사용되는 버전 제어가 아닌 데이터베이스 또는 기타 데이터 저장소에 포함됩니다. 데이터 저장소는 (이 소프트웨어와 마찬가지로) 컨텐츠의 버전 제어를 제공하도록 배열 될 수있다. 많은 위키는 버전 관리 시스템을 사용하여 개정을 추적합니다.
편집하다:
내가 사용하는 수정은 (a) 버전 관리가 전혀 없음, (b) 프로덕션 사이트는 마스터 사이트, (c) 변경 될 때마다 아카이브, (d) 아카이브 스크립트는 ACL과 같은 정크를 제거하고, (e) 설치 스크립트는 파일 권한과 같은 다른 정크를 수정합니다.
이러한 문제는 사이트를 버전 제어 시스템으로 가져오고 프로세스를 변경하여 해당 시스템을 통해 마스터 사이트가 업데이트되도록하여 처리 할 수 있습니다. (a), (b) 및 (c)는 버전 관리에 의해 직접 처리됩니다. (c)가 더 잘 작동하도록 릴리스에 태그를 지정할 수 있습니다. (d) 배포 시스템 만 사이트를 변경하는 경우 일반적으로 문제가되지 않습니다. 사이트 컨텐츠에 ACL이 필요하지 않았습니다.
(e) 초기 생성 및 주요 변경시에만 실행해야합니다. 버전 제어에서 사이트를 업데이트하고 자주 실행되는 스크립트도 포함 할 수 있습니다. 이러한 스크립트는 사이트를 혐오 제어 시스템에 유지할 때 매우 간단한 경향이 있습니다.
그런데 왜 이런 일을하는 일반 시스템을 만들지 않았습니까?
버전 관리 시스템을 사용하는 경우 필요하지 않기 때문입니다.
버전 관리 시스템은이 모든 것들을 추적 할 수 있지만, 아무것도하지 않습니다.
CVS와 Subversion은 모두 사용중인 경우 추적해야하는 내용을 추적합니다. 버전 관리 시스템을 사용하지 않거나 추적하지 않아도되기 때문에 추적해야 할 사항을 추적하지 않습니다. 버전 관리 시스템을 사용할 때 추적해야 할 내용을 추적합니다.
버전 관리를 사용하여 콘텐츠를 관리하는 여러 사이트에서 작업했습니다. 모두 준비 사이트, 배포 빈도 및 업데이트 완료에 대한 요구 사항이 서로 다릅니다. 사이트가 버전 관리에 들어가면 나머지 요구 사항을 비교적 쉽게 충족 할 수있었습니다. CVS 및 Subversion에 대한 설명서는 가능한 업데이트 방법을 제안합니다.
버전 제어 컨텐츠 내의 특정 영역에 대한 액세스를 제한하려면 ACL이 필요할 수 있습니다. 그러나 나는 신뢰를 바탕으로 일하는 경향이 있습니다. 버전 관리를 통해 누가 언제 무엇을했는지 쉽게 확인할 수 있습니다. 파일을 다시 포맷하지 않으면 누가 언제 어떤 라인을 추가했는지 보여주는 주석이 달린 파일 히스토리를 쉽게 얻을 수 있습니다.