Sự khác nhau giữa mô hình con git và cây con

Sự khác biệt về khái niệm giữa việc sử dụng mô hình con git và cây con là gì?

Các kịch bản điển hình cho mỗi là gì?

• mô hình con phù hợp hơn cho phát triển dựa trên thành phần , trong đó dự án chính của bạn phụ thuộc vào phiên bản cố định của thành phần khác (repo).
  Bạn chỉ giữ các tài liệu tham khảo trong repo cha mẹ của bạn ( gitlinks , các mục đặc biệt trong chỉ mục )

Điều gì sẽ xảy ra nếu tôi muốn các liên kết luôn luôn trỏ đến TRƯỚC của repo bên ngoài?

Bạn có thể tạo một mô hình con để đi theo ĐẦU của một nhánh của repo từ xa mô đun con, với:

o git submodule add -b <branch> <repository> [<path>]. (để chỉ định một nhánh để theo dõi)
o git submodule update --remotesẽ cập nhật nội dung của mô hình con lên TRÊN mới nhất từ <repository>/<branch>, theo mặc định origin/master. Dự án chính của bạn vẫn sẽ theo dõi các giá trị băm của phần đầu của mô hình con ngay cả khi --remoteđược sử dụng.

• cây con giống như một sự phát triển dựa trên hệ thống , trong đó tất cả repo của bạn chứa mọi thứ cùng một lúc và bạn có thể sửa đổi bất kỳ phần nào.
  Xem một ví dụ trong câu trả lời này .

mô hình con là liên kết;

cây con là bản sao

Sự khác biệt về khái niệm là:

Với các mô đun con git, bạn thường muốn tách một kho lưu trữ lớn thành các kho nhỏ hơn. Cách tham chiếu một mô hình con là kiểu maven - bạn đang tham chiếu một cam kết duy nhất từ ​​kho lưu trữ (mô hình con) khác. Nếu bạn cần một thay đổi trong mô hình con, bạn phải thực hiện một cam kết / đẩy trong mô hình con, sau đó tham chiếu cam kết mới trong kho lưu trữ chính và sau đó cam kết / đẩy tham chiếu đã thay đổi của kho lưu trữ chính. Bằng cách đó, bạn phải có quyền truy cập vào cả hai kho lưu trữ để xây dựng hoàn chỉnh.

Với git cây con, bạn tích hợp một kho lưu trữ khác trong kho của bạn, bao gồm cả lịch sử của nó. Vì vậy, sau khi tích hợp nó, kích thước của kho lưu trữ của bạn có thể lớn hơn (vì vậy đây không phải là chiến lược để giữ cho kho lưu trữ nhỏ hơn). Sau khi tích hợp, không có kết nối với kho lưu trữ khác và bạn không cần truy cập vào nó trừ khi bạn muốn nhận được bản cập nhật. Vì vậy, chiến lược này là nhiều hơn cho việc sử dụng lại mã và lịch sử - cá nhân tôi không sử dụng nó.

mô-đun phụ
đẩy một repo chính đến một điều khiển từ xa không đẩy các tập tin của mô-đun phụ

cây phụ
đẩy một repo chính đến từ xa đẩy các tập tin của cây con