Tôi đã có một kho lưu trữ Git trong đó tất cả mã của tôi nằm trong nhánh chính và trước đây tôi chỉ bỏ qua tất cả các tệp Drupal, do đó tôi giữ một khoảng cách chặt chẽ giữa mã mà tôi đã viết (hoặc sửa đổi hoặc có thể sửa đổi) và mã có thể được tạo ra với Drush hoặc bất cứ điều gì.
Đây dường như là một chiến lược tốt cho đến khi tôi phải nâng cấp Drupal. Tôi nhận ra rằng tôi muốn có thể quay trở lại nếu mọi thứ trở nên tồi tệ, và công cụ nào tốt hơn để sử dụng hơn Git để làm điều đó. Tôi nghĩ rằng đây sẽ là tình huống hoàn hảo cho một nhánh tính năng, vì vậy tôi đã tạo một drupal-7.14nhánh, tự nó .gitignorebỏ qua tất cả các tệp mã và cài đặt của mình và chỉ chú ý đến các tệp là một phần của cài đặt Drupal mà tôi sẽ không t được chạm vào. Tôi đã thực hiện nâng cấp bằng tay (tải xuống, giải nén, gỡ bỏ, sao chép), sắp xếp qua các trường hợp đường biên như robot.txt và .htaccess và ghi đè lên .gitignore của Drupal bằng chính tôi. Tôi đã sửa một số cài đặt hoạt động với 7.14 nhưng không phải với 7.15, để phục hồi từ lỗi 500, và sau đó mọi thứ dường như hoàn hảo. Tôi đổi tên chi nhánh thành drupal-7.15và chuẩn bị đi trên con đường hạnh phúc.
CHO Ôi!
Nếu tôi hợp nhất drupal-7.15chi nhánh với chủ, tôi sẽ mất việc tách mã.
Có lẽ có một số cách để chuyển đổi một nhánh thành mô hình con. Giả sử điều đó là có thể, đó có thể là chiến lược tốt nhất. Tôi đã biết trước khi tôi làm điều này rằng các mô hình con là giải pháp "đúng", nhưng vì tôi không nhận ra tác dụng phụ của việc sử dụng các nhánh cho các tệp không bị theo dõi trước đó, tôi đã quyết định cắt góc và đi theo con đường đó. (Ngoài ra, tất cả các cách tiếp cận mà tôi đã thấy khi sử dụng các mô hình con với Drupal đều cho rằng bạn đang bắt đầu một dự án mới và Drupal sẽ là nhánh chính. Tôi không mong muốn đặt mã của người khác thành nhánh chính và tôi đã có một repo với một nhánh chính. Điều này có vẻ như sẽ phức tạp không cần thiết chỉ để thực hiện nâng cấp.)
Có thể có một số giải pháp khác mà tôi chưa từng nghĩ đến.
Làm thế nào tôi có thể phục hồi tốt nhất từ điều này với ít nhược điểm nhất có thể?
CẬP NHẬT : Đây là bản phát triển (trong máy ảo Linux trên máy tính xách tay của tôi) và chưa đi vào sản xuất. Vào thời điểm chúng tôi đi vào sản xuất, tôi dự định sẽ thu gọn mọi thứ trong các mô-đun tính năng, nhưng điều đó vẫn chưa được thực hiện.
CẬP NHẬT 2 : Submodules có thể không hoạt động. Theo Pro Git , "Submodules cho phép bạn giữ một kho lưu trữ Git như một thư mục con của kho lưu trữ Git khác". Drupal không cung cấp bất kỳ sự tách biệt tốt đẹp như vậy. Thay vì tất cả mã Drupal nằm trong thư mục con, mối quan hệ ít nhiều bị đảo ngược, nhưng vẫn không có sự tách biệt rõ ràng, vì bạn có thể chỉnh sửa .htaccess và robot.txt, do đó mã của bạn và repo Drupal được trộn lẫn với nhau. Tôi đang tìm cách giải quyết vấn đề này .