모든 코드가 마스터 브랜치에있는 Git 리포지토리가 있는데 이전에 모든 Drupal 파일을 무시하고 있었기 때문에 내가 작성한 (또는 수정하거나 수정할 수있는) 코드와 코드를 엄격하게 구분했습니다. Drush 등으로 생성 될 수 있습니다.
Drupal을 업그레이드해야 할 때까지 이것은 좋은 전략처럼 보였다. 상황이 나빠지면 롤백하고 싶습니다 .Git보다 도구를 사용하는 것이 더 좋습니다. 나는 이것이 기능 브랜치에 대한 완벽한 상황이라고 생각했다. 그래서 브랜치를 만들고 모든 코드와 설정 파일을 무시하고 Drupal 설치의 일부인 파일에만주의를 기울 이도록 drupal-7.14자체적 .gitignore으로 주었다. 만지지 마십시오. robots.txt 및 .htaccess와 같은 경계 사례를 정렬하고 Drupal의 .gitignore를 내 자신으로 덮어 쓰면서 직접 다운로드 (다운로드, 압축 풀기, untar, 복사)했습니다. 500 오류에서 복구하기 위해 7.14에서는 작동했지만 7.15에서는 작동하지 않는 일부 설정을 수정 한 후 모든 것이 완벽 해 보였습니다. 지점의 이름을 바꾸고 drupal-7.15행복하게 가려고했습니다.
내가 실수로했던 것을 깨달을 때까지 : 마스터 브랜치에서 이전에 추적하지 않았지만 작업 디렉토리에 남겨진 파일은 이제 더 이상 추적되지 않은 파일이 아니기 때문에 마스터를 체크 아웃 할 때 작업 디렉토리에서 제거되었습니다! 도!
drupal-7.15지점을 마스터와 병합하면 코드 분리가 손실됩니다.
분기를 하위 모듈로 변환하는 방법이있을 수 있습니다. 가능하다고 가정하면, 이것이 최선의 전략 일 수 있습니다. 하위 모듈이 "올바른"솔루션이라는 것을 알기 전에는 이전에 추적되지 않은 파일에 분기를 사용하는 부작용을 인식하지 못했기 때문에 모서리를 자르고 해당 경로로 이동하기로 결정했습니다. (또한 Drupal에서 하위 모듈을 사용하는 것으로 보았던 모든 접근 방식은 새로운 프로젝트를 시작하고 Drupal이 마스터 브랜치가 될 것이라고 가정합니다. 다른 사람의 코드를 마스터 브랜치로 만드는 것은 바람직하지 않습니다. 마스터 지점이있는 리포지토리로 업그레이드하는 것만으로는 불필요하게 복잡해 보였습니다.)
내가 생각하지 않은 다른 해결책이있을 수 있습니다.
가장 적은 단점을 가지고 어떻게 이것을 가장 잘 복구 할 수 있습니까?
업데이트 : 이것은 내 랩톱의 Linux VM에서 개발 중이며 아직 프로덕션 환경으로 이동하지 않았습니다. 프로덕션으로 갈 때까지 모든 것이 기능 모듈로 마무리 될 계획이지만 아직 제자리에 있지 않습니다.
업데이트 2 : 하위 모듈 이 작동하지 않을 수 있습니다. Pro Git 에 따르면"하위 모듈을 사용하면 Git 저장소를 다른 Git 저장소의 하위 디렉토리로 유지할 수 있습니다". Drupal은 그러한 훌륭한 분리를 제공하지 않습니다. 모든 Drupal 코드가 서브 디렉토리에있는 대신, 관계가 다소 역전되지만 .htaccess와 robots.txt를 편집 할 수 있으므로 코드와 Drupal 저장소가 혼합되어 있기 때문에 아직 명확하게 구분되지 않습니다. 난 이 문제에 대한 해결 방법을 찾고 .