2012-08-22 20 views
6

Gần đây, chúng tôi gặp nhiều vấn đề với kho lưu trữ Git của chúng tôi. Chúng tôi là người dùng các mô-đun con git cho tổng cộng 4 kho được chia sẻ giữa các ứng dụng của chúng tôi.Git submodules issue work issues

Ví dụ: kho lưu trữ 'trang web' có tổng cộng 3 mô-đun con.

[submodule "vendor/api"] 
    path = vendor/api 
    url = [email protected]:api 
[submodule "vendor/auth"] 
    path = vendor/auth 
    url = [email protected]:auth 
[submodule "vendor/tools"] 
    path = vendor/tools 
    url = [email protected]:tools 

Chúng tôi đã kiểm tra chính xác trang web chính 'trang web' của chúng tôi. Bây giờ một trong những đồng nghiệp của tôi đã làm một sự thúc đẩy, sau đó tôi git pull; git status:

# On branch master 
# Changed but not updated: 
# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>..." to discard changes in working directory) 
# 
# modified: vendor/api (new commits) 
# modified: vendor/auth (new commits) 
# modified: vendor/tools (new commits) 
# 
no changes added to commit (use "git add" and/or "git commit -a") 

[email protected]:~/projects/website$ git diff 

diff --git a/vendor/api b/vendor/api 
index 41795fc..b582d80 160000 
--- a/vendor/api 
+++ b/vendor/api 
@@ -1 +1 @@ 
-Subproject commit 41795fc4dde464d633f4c0f01eebb6ab1ad55582 
+Subproject commit b582d802419b0ee7bc3959e7623fec0b94680269 
diff --git a/vendor/auth b/vendor/auth 
index a00369b..4599a71 160000 
--- a/vendor/auth 
+++ b/vendor/auth 
@@ -1 +1 @@ 
-Subproject commit a00369bf29f14c761ce71f7b95aa1e9c107fb2ed 
+Subproject commit 4599a7179c9b7ca4afa610a15ffa4a8fc6ebf911 
diff --git a/vendor/tools b/vendor/tools 
index f966744..c678cf6 160000 
--- a/vendor/tools 
+++ b/vendor/tools 
@@ -1 +1 @@ 
-Subproject commit f966744359510656b492ae3091288664cdb1410b 
+Subproject commit c678cf6f599fc450e312f0459ffe74e593f5890f 

vấn đề với git diff đó là gì? Vấn đề là các commit mới cho mỗi submodule là OLDER hơn các commit sẽ bị ghi đè. Đó không phải là những gì chúng tôi muốn vì trên kho lưu trữ đang trỏ chính xác đến 41795fc4dde464d633f4c0f01eebb6ab1ad55582, a00369bf29f14c761ce71f7b95aa1e9c107fb2edf966744359510656b492ae3091288664cdb1410b và nếu chúng tôi thêm sửa đổi này vào cam kết tiếp theo, chúng tôi có thể sẽ làm mọi thứ. Tôi không biết tại sao nó lại nhận được bản sửa đổi lâu đời nhất và không phải là bản mới nhất.

Tôi đã cố gắng để giải quyết điều này bằng bản thân mình nhưng không thành công:

[email protected]:~/projects/website$ git pull; git submodule foreach git pull 

Làm lệnh cuối cùng đó là không đúng bởi vì chúng tôi có lẽ sẽ cập nhật con trỏ của 'trang web' đến mới nhất của mỗi submodule và chúng tôi không muốn điều này. Chúng tôi muốn bảo tồn bản sửa đổi chính xác rằng nó trên kho lưu trữ.

Một trong những điều mà tôi đã giải thích rằng chúng tôi thường làm việc bên trong các môđun con này, ví dụ:

[email protected]:~/projects/website$ cd vendor/api 
[email protected]:~/projects/website/vendor/api$ git checkout master 
[email protected]:~/projects/website/vendor/api$ echo "lorem ipsum" >> example.file 
[email protected]:~/projects/website/vendor/api$ git add example.file; git push 

Khi chúng ta làm một git submodule update chi nhánh 'thầy' bị mất trên mỗi submodule.

Cuối cùng, điều gì là đúng cách để thực hiện push, pull và làm việc với các mô-đun con và không gặp phải tất cả sự cố này?

Cảm ơn bạn trước

Trả lời

8

Hãy xem số git-scm documention và truyền cho nhóm của bạn. Hiện tượng bạn đang thấy được mô tả chính xác trong phần "Cloning a Project with Submodules". Trước tiên, trạng thái ban đầu mà bạn quan sát thấy, trong đó git diff hiển thị kết quả trái ngược bất ngờ cho các băm cam kết đó, cho biết bạn đã hợp nhất cập nhật mô-đun con trong repo chính, nhưng không chạy git submodule update cục bộ. Bạn phải chạy git submodule update mỗi khi bạn kéo xuống một thay đổi mô-đun nhỏ trong dự án chính. Tại sao? Con trỏ của môđun con, nghĩa là kho lưu trữ cha nghĩ là trạng thái của vendor/auth, không thực sự là cam kết HEAD của kho lưu trữ con số vendor/auth. Đó là một chút khó hiểu cho đến khi bạn hiểu làm thế nào git được theo dõi các tiểu bang submodule. Một lần nữa, các git-scm documentation là giá trị đọc.

Thứ hai, git submodule update từ chối chi nhánh master trên mô hình con theo thiết kế. Xem phần "Issues with submodules" của các tài liệu đó. Các trang con người, như thường là đúng với git, cho chúng ta biết những gì chúng ta cần phải biết:

update 
    Update the registered submodules, i.e. clone missing submodules and checkout the commit specified in the index of the containing repository. This will 
    make the submodules HEAD be detached unless --rebase or --merge is specified or the key submodule.$name.update is set to rebase, merge or none. none 
    can be overridden by specifying --checkout. 

Bạn đang đặt các môđun con của bạn trong 'tách HEAD' trạng thái mỗi khi bạn phát hành git submodule update mà không cần tranh cãi.

Vậy làm cách nào để bạn làm việc với các mô-đun con mà không gặp phải vấn đề này? Đầu tiên, hãy tự hỏi mình và nhóm của bạn: Chúng ta có thực sự cần chúng không? Submodules là một tính năng mạnh mẽ và hữu ích trong một số trường hợp, nhưng chúng được thiết kế nhiều hơn cho các thư viện của bên thứ ba so với các dự án đang hoạt động được chia thành các kho phụ. Bạn chắc chắn có thể sử dụng chúng theo cách này, nhưng chi phí quản lý có thể nhanh chóng vượt quá bất kỳ lợi ích bạn đang nhận được. Trừ khi kho lưu trữ của bạn khá lớn, hoặc các mô-đun con của bạn hoàn toàn theo mô-đun, bạn có thể yêu cầu "Would we be better off with a single repository?" Ngay cả khi câu trả lời là "không", hãy xem subtree merging, có thể thành công hơn cho trường hợp sử dụng của bạn.

Nếu bạn vẫn muốn sử dụng các mô-đun con, hãy xem the docs được liên kết ở trên, cũng như nhiều questionsanswers trên SO và các trang web khác về quy trình làm việc phụ. Chúng sẽ giúp bạn đạt được quy trình an toàn hơn.

Các vấn đề liên quan