Có ai đang sử dụng tính năng git super/subproject mới trong các dự án thực không? Làm thế nào nó hoạt động tốt? Ví dụ, tôi hiểu rằng nếu tôi đẩy vào một tiểu dự án, tôi phải tự gọi superprojects hooks (có thể sử dụng hook subprojects, nhưng tuy nhiên)?Có ai thực sự sử dụng git super/subprojects không?
Bằng cách sử dụng mô-đun con, bạn đang xác định trong không gian làm việc Git của bạn (có nghĩa là kho lưu trữ Git "siêu dự án") một cấu hình .
Bằng "cấu hình", ý tôi là "danh sách các thẻ hoặc nút SHA-1 cần thiết để hoạt động trong không gian làm việc của bạn".
(và bởi công việc, tôi có nghĩa là bất cứ "nỗ lực phát triển" nào bạn đang làm trong không gian làm việc của bạn: biên dịch cổ điển, hoặc vá, hoặc hợp nhất, hoặc triển khai, hoặc ...).
Đó là trường hợp khi bạn được nhân bản một siêu dự án và "git update" submodules của bạn: bạn đang checkouting Repos SHA1 chính xác mà trước đó đã được cam kết trong các siêu dự án (ghi nhận là gitlink trong the index).
Chế độ khác là khi bạn đang làm việc trên siêu dự án và trên một hoặc nhiều mô-đun phụ.
Điều đó có nghĩa, đối với một mô-đun con đã cho, bạn đã kiểm tra một chi nhánh cụ thể (bạn không còn sử dụng HEAD tách rời cho nội dung của các mô-đun con đó nữa, mà là một con trỏ đến đầu nhánh).
Sau đó, "đẩy một mô-đun con" có nghĩa là cập nhật một kho lưu trữ ở xa chứa mô-đun phụ đó (và chỉ một mô-đun đó).
Bí quyết thực tế trong kịch bản cuối cùng (có thể xứng đáng là một móc bạn muốn) là khi bạn đang đẩy siêu dự án: bạn cần phải chắc chắn đã đẩy tất cả các mô-đun phụ của mình trước.
Luôn xuất bản thay đổi submodule trước khi xuất bản sự thay đổi đến superproject tham chiếu đến nó. Nếu bạn quên xuất bản thay đổi mô-đun con, những người khác sẽ không thể sao chép kho lưu trữ (của siêu dự án)
Đừng quên bạn can configure a submodule to follow a branch.
Điều này nghe có vẻ giống như một phiên bản alpha của submodules, quá nhiều biến chứng ...: S – inf3rno
Nếu bạn có nghĩa là mô-đun con, thì chắc chắn.
Các mô-đun con không và không nên biết ở mọi nơi chúng được sử dụng. Ví dụ, tôi có một submodule được sử dụng trong một số dự án mà tôi biết (và khá có thể một số mà tôi không).
Đẩy vào một mô-đun con không theo bất kỳ cách nào ảnh hưởng đến phiên bản mã được sử dụng bởi dự án có chứa mô-đun con, vì vậy tôi không chắc chắn bạn muốn móc nối làm gì.
Nếu, ví dụ, submodule chỉ là một phần của một sw lớn hơn tôi có thể muốn biên dịch toàn bộ gói khi ai đó đẩy một. – Makis
Bạn đang thiếu cả hai điểm. 1) Thay đổi mô-đun con không thay đổi bất kỳ dự án nào chứa nó. Ở tất cả. Một bản dựng mới sẽ giống hệt với bản dựng trước đó. 2) Một môđun con đã cho có thể được hàng ngàn ứng dụng sử dụng và không thể biết tất cả chúng là gì. – Dustin
Tất nhiên mô-đun có thể được sử dụng bởi các ứng dụng khác nhau nhưng tất nhiên dự án chính sẽ có kịch bản lệnh xây dựng bao gồm mô-đun. Tôi không hiểu điều này "chút nào" - nếu tôi có một dự án với hai mô-đun con và một người nào đó đẩy các thay đổi của họ vào một trong các mô-đun con như thế nào thì mô-đun con không thay đổi? Nếu nó thay đổi và tôi có một kịch bản xây dựng bao gồm submodule đó, sau đó tất nhiên xây dựng là khác nhau. – Makis
FWIW, chúng tôi đang cố gắng thực hiện bước nhảy vọt, và dự án của chúng tôi (bitweaver, hệ thống quản lý nội dung) là hệ thống mô-đun cao, với nearly 160 repositories). Một "xây dựng" thường chứa hai tá hoặc nhiều kho phụ. Chúng tôi đã sử dụng 'các mô-đun ảo' trong CVS, và điều này làm việc rất tuyệt vời cho chúng tôi, tuy nhiên CVS có những hạn chế riêng của nó đối với các cam kết dàn dựng.
Các mô-đun con Git có một số hạn chế nghiêm trọng, và bạn chắc chắn nên đánh giá việc thực hiện của mercurial vì nó chắc chắn và linh hoạt hơn cho các dự án ngoài/mô-đun (tức là nó hỗ trợ các hệ thống VCS khác, thậm chí là HgGit).
Dưới đây là những thách thức lớn nhất:
Mỗi submodule được cứng liên kết với một đặc biệt cam kết khi bạn "git submodule thêm" trong siêu respository. Điều này là do thiết kế và tìm kiếm lợi ích của người bảo trì git, vì vậy tôi không mong đợi nó sẽ thay đổi bất kỳ lúc nào. Điều này gây đau đớn cho một hệ thống giống như hệ thống của chúng tôi, trong đó cam kết luôn xảy ra trong các mô-đun phụ . Bạn phải cập nhật dự án siêu hạng để cập nhật hoặc cập nhật repos phụ của bạn để làm chủ sau cập nhật môđun con ban đầu. (xem supergit bên dưới để biết giải pháp của chúng tôi).
Bạn không thể dễ dàng cam kết và đẩy tới tất cả sub-repo từ gốc. Điều này cũng rất khó chịu, hãy xem supergit bên dưới.
Khác nhau gotchas có thể gây khó chịu, đặc biệt là những thứ "ghi đè âm thầm thay đổi".
supergit
Chúng tôi đã viết một shell script call supergit để xử lý một số painfulness. Nó làm bản sao, submodule init, cập nhật, và kiểm tra tổng thể tất cả trong một ngã swoop. Nó cũng sẽ thực hiện lệnh git cho tất cả các thư mục trong siêu repo riêng lẻ (xử lý khối lượng lớn các loại).
HTH, chúc may mắn.
+1 đây là một tổng quan tốt về những thuận và chống. FYI, đối với các cam kết mã hóa cứng, điều này được kỳ vọng sẽ hữu ích trong trường hợp các mô-đun phụ hiếm khi (hoặc theo cách thủ công) được cập nhật thành các phiên bản tốt, được biết đến (ví dụ: thẻ sản xuất) - vì vậy nó hoạt động rất tốt trong trường hợp đó. – ashes999
Là một tiểu dự án giống như một mô-đun con? Tôi đã sử dụng chúng. – Apreche