Tôi cảm thấy rằng việc sử dụng mô-đun con Git bằng cách nào đó gây rắc rối cho quy trình phát triển của tôi. Tôi đã nghe nói về cây con Git và Gitslave.
Câu trả lời:
Cái nào tốt nhất cho bạn tùy thuộc vào nhu cầu, mong muốn và quy trình làm việc của bạn. Theo một số nghĩa, chúng là bán đẳng cấu, nó chỉ là một số dễ sử dụng hơn những cái khác cho các nhiệm vụ cụ thể.
gitslave hữu ích khi bạn kiểm soát và phát triển trên các dự án con ít hơn cùng lúc với siêu dự án và hơn nữa khi bạn thường muốn gắn thẻ, phân nhánh, đẩy, kéo, v.v. tất cả các kho lưu trữ cùng một lúc. gitslave chưa bao giờ được thử nghiệm trên các cửa sổ mà tôi biết. Nó yêu cầu perl.
git-submodule sẽ tốt hơn khi bạn không kiểm soát các tiểu dự án hoặc cụ thể hơn là muốn sửa tiểu dự án tại một bản sửa đổi cụ thể ngay cả khi tiểu dự án thay đổi. git-submodule là một phần tiêu chuẩn của git và do đó sẽ hoạt động trên windows.
git-subtree cung cấp chiến lược hợp nhất cây con có sẵn từ giao diện người dùng đến git. Sẽ tốt hơn khi bạn muốn có một lịch sử git "thống nhất" trong kho lưu trữ. Không giống như chiến lược hợp nhất cây con, việc xuất các thay đổi sang các cây (thư mục) khác nhau trở lại dự án ban đầu dễ dàng hơn, nhưng nó không tự động như với gitslave hoặc thậm chí là git-submodule.
repo về lý thuyết tương tự như gitslave, nhưng không được tài liệu hóa tốt cho các hoạt động không phải android mà tôi đã tìm thấy. Nó khá dành riêng cho mô hình phát triển Google Android và chỉ hỗ trợ một số lệnh git (mặc dù bạn có thể chạy các lệnh tùy ý) và hỗ trợ gốc hạn chế không hỗ trợ, ví dụ: một kho lưu trữ tập trung để đẩy đến và kiểm tra chi nhánh có vẻ khá khó khăn.
kitenet's mr là những gì bạn muốn sử dụng nếu bạn có nhiều hệ thống kiểm soát phiên bản đang sử dụng, nhưng hầu như bị giới hạn đối với các siêu dự án chỉ git do cách tiếp cận mẫu số chung thấp nhất của nó. Có nhiều cách để chạy các lệnh tùy ý, nhưng chúng không được tích hợp tốt.
mr run git config ...hoặc có lẽ (thậm chí tệ hơn) phương thức tệp cấu hình thành bí danh các lệnh cụ thể đối với tên. Tất nhiên, nếu bạn biết về một số chức năng của ông không rõ ràng ngay lập tức khi đọc trang người đàn ông, tôi muốn biết về nó.
git/contrib. Cài đặt trong Ubuntu với sudo make install install-doc prefix=/usr libexecdir=/usr/lib/git-coretừ cây nguồn Git ( không hoạt động với Git đóng gói).
Tôi hiện đang sử dụng các mô-đun con để phát triển và không chỉ liên quan đến các thư viện của bên thứ ba. Có một số cách mà bạn có thể làm cho cuộc sống dễ dàng hơn với các mô-đun con, đặc biệt khi chúng là nguồn gốc của các xung đột hợp nhất hoặc tái cơ sở. Nhìn vào ls-tree để biết 2 commit liên quan đến xung đột trong submodule. Đây có lẽ là phần khó khăn nhất của mô-đun con đối với mọi người. Hiện tại, tập lệnh sẽ làm cho việc này dễ dàng hơn nhiều. Các phiên bản tương lai của Git nên có hỗ trợ gốc tốt hơn để xử lý chúng.
Hi vọng điêu nay co ich.
Chúng tôi đã gặp sự cố tương tự khi sử dụng mô-đun con Git trong các dự án mà chúng tôi có phụ thuộc vào nhiều ngôn ngữ khác nhau. Để đối phó với chúng, chúng tôi đã xây dựng và tạo nguồn mở một công cụ có tên MDLR ("Mô-đun") cung cấp cho bạn các phụ thuộc Git được kiểm soát theo phiên bản khai báo với chức năng tương tự như các mô-đun con Git, nhưng không có quy trình làm việc phiền phức. Bạn có thể cài đặt nó và quản lý các phần phụ thuộc của mình bằng các hướng dẫn / tải xuống trên repo GitHub
Đối với một số trường hợp sử dụng, tôi thích từng cách tiếp cận đơn giản sau:
Kho lưu trữ lồng nhau. Nếu dự án phần mềm của bạn có cơ chế plugin, với mỗi plugin trong thư mục con riêng của nó, bạn có thể bỏ qua git-bỏ qua các thư mục plugin này và trong hệ thống tệp cục bộ của bạn, để biến mỗi plugin thành kho lưu trữ git của riêng nó. Bằng cách này, tất cả các tệp của bạn tạo thành một cây thư mục duy nhất, nhưng được quản lý trong các kho lưu trữ git khác nhau. Nó sẽ không nhầm lẫn git.
Kho lưu trữ mỗi gói. Đối với các dự án phần mềm mà bạn sử dụng một số loại hệ thống quản lý gói mã nguồn (gem / Bundler, npm, lê hoặc tương tự), bạn có thể đặt mã đã sử dụng lại vào các kho lưu trữ git riêng biệt, sau đó tạo các gói nguồn từ chúng và sau đó cài đặt chúng bằng công cụ quản lý gói vào dự án mẹ. Kho lưu trữ git của dự án mẹ của bạn sẽ chỉ chứa tham chiếu đến các gói được yêu cầu và phiên bản của chúng, trong khi mã thực của các gói này sẽ bị bỏ qua git như được thực hiện với tất cả các gói khác và thư viện bên ngoài. So với các kho lưu trữ lồng nhau được đề xuất ở trên, đây là một cách tiếp cận phức tạp hơn vì nó cho phép chỉ định phiên bản gói nào sẽ được cài đặt.