Điểm:1

Git branching strategies with a small team to develop a Drupal site

lá cờ in

We're a small team (5-6 developers) building a Drupal 7 site. Previously, we've used Features (https://www.drupal.org/project/features) to export our configurations from development to production. We've relied largely on assigning developers discrete, unrelated tasks.

Our upcoming work has distinct, but related development. For example, I anticipate we'll need to add fields that will be used by two different tasks (for example, think about a date field for an event. One developer is working on the email invite and the other is working on the event display page). If we are able to anticipate this overlap, we'd be able to do this before either starts work.

However, if we don't realize a common need until after work has begun in separate branches per developer/feature, this becomes trickier. I believe that we would need to merge their branches together to access the common code-which defeats the point of us having separate branches in the first place.

Curious for what you'd suggest or has worked well in the past! Thanks!

Note: I've identified these potential solutions, both with drawbacks:

  • Cherry pick commits. While this could be helpful, it's also likely that a cherry-picked commit will include extraneous changes beyond the narrow scope needed here. And it's just as likely that the single commit won't include all of the changes necessary (For example, if one commit created the feature, and a second created the field, you'd need to cherry pick both commits). This all seems to head for a merge headache down the road.

  • Create a folder within sites/all/features/ignore, manually transfer the needed features there from the other branch. Include this directory in .gitignore. I don't like that:

  1. This has our team sending features files all over outside of git,
  2. That it could introduce dependency errors if features are changed in the original, but not updated in the other places that they are used,
  3. That users may make changes to the ignored features that aren't moved into git,
  4. That switching between computers/development environments would lose these files
  5. That all related branches would need to be merged before deploying to production (which again, undermines the point of branching since these branches are now dependent on each other and would have to be released at once, rather than when ready/needed).
  • Another option is to make the change (export the feature needed or cherry-pick commits) to the parent branch (e.g., Develop or Develop-Feature) so that it's available to all child branches.
Jaypan avatar
lá cờ de
Đây không phải là câu trả lời bạn đang tìm kiếm, nhưng thành thật mà nói, tôi không khuyên bạn nên bắt đầu một trang web mới trên Drupal 7 vào thời điểm này. EOL của nó là tháng 11 năm 2022, chỉ một năm nữa kể từ bây giờ. Sau đó, Drupal 7 sẽ không nhận được các bản cập nhật bảo mật nữa và việc nâng cấp từ D7 -> D8 KHÔNG dễ dàng. Ngoài ra, API quản lý cấu hình trong D8 dễ dàng hơn các Tính năng của D7 (https://www.morpht.com/blog/drupal-8-configuration-part-1-configuration-api). Tôi khuyên bạn nên bắt đầu các trang web mới trong D9. Hầu hết mọi mô-đun đã được nâng cấp từ D8 -> D9 vì quá trình nâng cấp dễ dàng hơn nhiều.
Grayson Cooper avatar
lá cờ in
Xin lỗi vì đã không làm rõ! Đây không phải là một trang web mới. Tôi đã bắt đầu các trang web mới trong D9 và đồng ý rằng nó dễ dàng hơn/đẹp hơn và trong khi D9 có thể thực hiện 99% những gì chúng tôi cần, thì 1% là khá quan trọng (chủ yếu liên quan đến Quy tắc). Chúng tôi đang xây dựng mọi thứ theo cách thân thiện với D9 để giảm thiểu khó khăn khi di chuyển, đồng thời cố gắng xây dựng một số kỹ năng cho nhóm của chúng tôi để họ cảm thấy thoải mái với D9 (chẳng hạn như chuyển sang git). Tôi cho rằng câu hỏi này vẫn áp dụng cho các trang web D9 (ngoài các tính năng) và có vẻ như cam kết hái anh đào là cách tiếp cận lý tưởng.
leymannx avatar
lá cờ ne
Xem xét Soạn trang web để quản lý đóng góp và cốt lõi. Cung cấp cách các nhà phát triển có thể dễ dàng đồng bộ Live DB mới nhất vào trang web cục bộ của họ. Mỗi khi nhà phát triển bắt đầu một nhánh tính năng mới (hoặc chuyển nhánh) hoặc hợp nhất phát triển với nhánh tính năng hiện có, họ sẽ đồng bộ hóa Live DB mới nhất vào trang web cục bộ của họ và phải chạy `composer install`, `drush updb` và `drush fra` . Giữ cho các nhánh tính năng nhỏ, mọi người phải cung cấp yêu cầu hợp nhất/kéo với trạng thái ổn định vào cuối ngày làm việc. Bỏ qua các tệp xây dựng giao diện người dùng từ repo. Để đó cho CI.
leymannx avatar
lá cờ ne
Biến các tập lệnh của Trình soạn thảo, các lệnh Drush tùy chỉnh, biến_get/_set() và hook_update_N() thành những người bạn tốt nhất của bạn.
Kevin avatar
lá cờ in
Tôi không thể nghĩ rằng cần có Quy tắc như một công cụ chặn để nâng cấp. Bạn có thể tạo lại nhiều quy tắc đó trong một vài dòng mã/Sự kiện hoặc sử dụng quy tắc kinh doanh.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.