Dự án của tôi sử dụng hơn 100 git submodules, mà submodule thay thế có thể xử lý rất nhiều kho một cách duyên dáng

Question

Tôi đã nghiên cứu git subtree và các lựa chọn thay thế cho git submodules. Dự án của tôi có hơn 100 submodules và nó rất khó sử dụng để quản lý tất cả chúng.

Bất kỳ ai cũng có thể đề xuất quy trình làm việc hoạt động thực sự tốt với số lượng lớn các kho lưu trữ cần được đồng bộ hóa.

Answer 1

Nếu bạn dự án có hơn 100 git submodules của các thành phần và phụ thuộc, quản lý của họ sẽ khó sử dụng dù bạn sử dụng phương pháp nào :-) Tôi khuyên bạn nên tìm cách để viết và tự động hóa càng nhiều phần càng tốt. Hãy tin tôi đi, tính mới mẻ của việc chơi với các lệnh git xâu chuỗi sẽ hao mòn rất nhanh đối với hầu hết mọi người, đặc biệt là khi thời hạn đang đến gần. Đã có một câu trả lời rất tốt here về so sánh các phương pháp khác nhau để quản lý các dự án phụ git.

Về quy trình làm việc, trước tiên tôi sẽ tách các kho lưu trữ nằm dưới sự kiểm soát của bạn khỏi những kho không phải là kho lưu trữ của bên thứ ba.

Đối với kho lưu trữ của bên thứ ba không thay đổi thường xuyên (thông qua hợp nhất hoặc PR), bạn vẫn có thể sử dụng mô-đun con. Thông thường, bạn sẽ chỉ các mô-đun con này đến phần đầu của một số thẻ ổn định. Đồng bộ hóa chúng chỉ là vấn đề chạy (hoặc tập lệnh) git submodule update --recursive --remote. Nếu các phụ thuộc bên thứ 3 này có thể được chỉ định trong các công cụ quản lý gói như bundler (for ruby projects), nó sẽ giúp đơn giản hóa việc quản lý tiểu dự án của bạn.

Đối với kho lưu trữ của riêng bạn và thay đổi thường xuyên, gitslave hoặc git-subtree là hai lựa chọn thay thế, tùy thuộc vào sở thích của nhóm của bạn.

gitslave multiplexes git hoạt động thành nhiều nhánh. IOW, khi bạn chi nhánh, hợp nhất, cam kết, đẩy, kéo, vv, mỗi lệnh sẽ được chạy trên dự án cha mẹ và tất cả nô lệ lần lượt. Điều này yêu cầu nhóm làm việc theo cách từ trên xuống, bắt đầu từ siêu dự án xuống các nô lệ.

gitsubtree sử dụng chức năng subtree merge của Git để đạt được hiệu ứng tương tự như mô-đun con, bằng cách lưu trữ tệp trong kho chính và hợp nhất các thay đổi trực tiếp vào kho lưu trữ đó. Kết quả cuối cùng là một kho lưu trữ kinh điển với tùy chọn bao gồm tất cả lịch sử tiểu dự án. Theo cách này, điều này cho phép các thành viên trong nhóm tập trung hơn vào các subtrees mà họ chịu trách nhiệm, nhưng sẽ yêu cầu thêm công việc để hợp nhất trở lại cây cha.

Là nhà phát triển, ưu tiên của tôi là làm việc ở cấp tiểu dự án thấp hơn (để làm "red, green, refactor" cycle) và chỉ chạm vào các dự án chính khi cần. Nhưng bất kể bạn chọn quy trình làm việc từ trên xuống hay dưới lên, hãy cố gắng xác định các bước dễ bị lặp lại lỗi trong chiến lược hợp nhất của bạn, và viết chúng càng nhiều càng tốt.