Submule Git vs Git clone

Tôi đang làm việc trên một dự án nguồn mở trên GitHub.

Nó có một thư mục con / Nhà cung cấp trong đó nó có một bản sao của một số thư viện bên ngoài. Người bảo trì ban đầu của dự án đã cập nhật thư mục này với bản sao mới hơn của thư viện bên ngoài.

Một nhà phát triển gửi cho tôi một yêu cầu kéo với ý tưởng để thay thế bản sao này bằng mô hình con git .

Và tôi đang xem xét liệu đó có phải là ý tưởng tốt hay không.

Tiểu trình Git Ưu điểm:

• Các mô hình con được thiết kế đặc biệt cho các kịch bản tương tự
• Nó loại bỏ khả năng cam kết vô tình với Nhà cung cấp sẽ bị ghi đè trong khi cập nhật tiếp theo

Submule Git Nhược điểm:

• Dường như các mô đun con git đẩy sự phức tạp từ người bảo trì sang một người sẽ sao chép / kéo dự án (các bước bổ sung cần thiết sau khi bạn sao chép để bắt đầu làm việc với dự án: "git mô đun con khởi tạo", "cập nhật mô hình con git"

Ý kiến ​​của bạn về điều này là gì?

Một điều nữa. Vấn đề này là thư viện kích thước nhỏ hợp lý với các phụ thuộc bên ngoài rất hạn chế. Tôi nghĩ rằng bất kỳ công cụ xây dựng nào sẽ là quá mức cần thiết cho nó bây giờ.

Một thay thế cho một mô hình con là sử dụng git subtree. Điều này mang lại lợi ích của git submodulenhưng không đẩy sự phức tạp đến người dùng cuối. Kho lưu trữ của bên thứ ba được hợp nhất vào cây dự án chính, nhưng có siêu dữ liệu được lưu trữ theo cách mà bạn có thể:

• trích xuất kho lưu trữ của bên thứ ba sau, nếu có bất kỳ thay đổi thú vị nào được thực hiện
• hợp nhất trong các bản cập nhật mới từ kho lưu trữ của bên thứ ba (ghi chú hợp nhất , không ghi đè)

Đối với người dùng Git không đủ tinh vi để hiểu các mô hình con, cách tiếp cận cây con làm cho việc sao chép dự án của bạn không khó khăn hơn bất kỳ bản sao nào khác. Một đoạn ngắn từ tài liệu:

Subtrees cho phép các tiểu dự án được đưa vào một thư mục con của dự án chính, tùy ý bao gồm toàn bộ lịch sử của tiểu dự án.

Ví dụ: bạn có thể bao gồm mã nguồn cho thư viện dưới dạng thư mục con của ứng dụng của mình.

Subtrees không được nhầm lẫn với các mô hình con, có nghĩa là cho cùng một nhiệm vụ. Không giống như các mô hình con, cây con không cần bất kỳ cấu trúc đặc biệt nào (như tệp .gitmodule hoặc gitlinks) có trong kho lưu trữ của bạn và không buộc người dùng cuối của kho lưu trữ của bạn phải làm bất cứ điều gì đặc biệt hoặc để hiểu cách thức hoạt động của cây con. Một cây con chỉ là một thư mục con có thể được cam kết, phân nhánh và hợp nhất cùng với dự án của bạn theo bất kỳ cách nào bạn muốn.

Tôi đã thiết lập một dự án tại nơi làm việc bằng cách sử dụng các mô hình con và những rắc rối với việc giữ cho các mô hình con được cập nhật trong bản sao của mọi người là quá nhiều công việc. Gần đây tôi đã thay đổi sử dụng cây con ở khắp mọi nơi và những vấn đề đó biến mất.

Lưu ý rằng git-subtree là một phần của git/contribthư mục và phải được cài đặt riêng.

Một nhược điểm của việc sử dụng các mô hình con là các tarball hoặc kho lưu trữ zip trên Github (và nhiều dịch vụ khác) không bao gồm các nguồn của các mô hình con. Đó là, tài liệu lưu trữ không khép kín. Đây là một vấn đề nếu kho lưu trữ nhỏ và không thực sự có tập lệnh xây dựng, giống như trang HTML tĩnh tùy thuộc vào thư viện JavaScript.

Đây là một nơi lý tưởng để sử dụng mô hình con. Chúng làm giảm kích thước và độ phức tạp của kho lưu trữ của bạn và giúp cập nhật các thư viện bên ngoài lên phiên bản mới dễ dàng hơn.

Chúng không khó để tìm ra cách sử dụng và chúng được sử dụng khá phổ biến trong tình huống này, vì vậy chỉ cần ghi chú trong README của dự án là bạn sử dụng các mô hình con và phải làm gì, và mọi người nên có thể hình dung nó ra Lần đầu tiên tôi gặp một kho lưu trữ với một mô hình con, tôi đã tải nó lên và chạy trong 10 đến 15 phút và chưa bao giờ có vấn đề với việc tìm hiểu phải làm gì kể từ đó.

Việc sử dụng các mô hình con ngăn bạn thực hiện các thay đổi cục bộ đối với mã & tạo ra sự phụ thuộc vào kho lưu trữ bên ngoài. Nếu bạn chắc chắn rằng bạn sẽ không bao giờ muốn tùy chỉnh thư viện hoặc thực hiện sửa lỗi cục bộ và có thể chắc chắn rằng máy chủ bên ngoài sẽ luôn khả dụng khi bạn muốn sao chép một bản sao mới.

Nói tóm lại - bạn có muốn đơn giản sử dụng libs hay bạn coi chúng là một phần của cơ sở mã của bạn? Nếu chúng không phải là 'mã của bạn', tại sao chúng lại nằm trong kiểm soát phiên bản và không chỉ là thứ bạn yêu cầu phải cài đặt?