git submodule không được đưa vào sản xuất
Vừa tạo một kho lưu trữ mới với hai mô-đun con. Nó hoạt động tốt trên cục bộ nhưng khi đẩy lên sản xuất, các mô-đun con không có ở đó. Mỗi thư mục gốc mô-đun con đều có, nhưng không có tệp nào bên trong
git version 2.27.0
Tạo repo trên sản xuất
git --bare init
cd hooks && touch post-receive && chmod +x post-receive
cat hooks/post-receive
#/bin/sh
git --work-tree=/var/www/repo --git-dir=/var/git_repos/repo.git checkout -f
Đẩy mạnh sản xuất từ dev / local
git push production master
git statusnói rằng mọi thứ đều được cập nhật. Ngay cả khi nó được gọi trong thư mục mô-đun con. Đã cố gắng xóa thư mục mô-đun con trên kho lưu trữ cục bộ, cam kết / đẩy đến kho lưu trữ. Sau đó git push production mastervà thư mục mô-đun con gốc đã bị xóa trên máy chủ sản xuất. Sau đó, cố gắng thêm lại
# git submodule add [email protected]:alias/repo_name.git php/repo/repo_name
Cloning into '/var/www/project/php/repo/repo_name'...
remote: Enumerating objects: 19, done.
remote: Counting objects: 100% (19/19), done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 19 (delta 8), reused 19 (delta 8), pack-reused 0
Receiving objects: 100% (19/19), 8.62 KiB | 8.62 MiB/s, done.
Resolving deltas: 100% (8/8), done.
Sau đó cam kết với kho lưu trữ và sau đó git push production master. Vấn đề giống nhau. Trong quá trình sản xuất, các thư mục gốc của các mô-đun con hiện diện nhưng không có tệp nào trong các thư mục.
Khi tôi duyệt qua kho lưu trữ trên github, các mô-đun con được liên kết chính xác.
Mọi thứ hoạt động trong kho lưu trữ cục bộ
Trả lời
Các thư mục mô-đun con không trống trên github (hoặc trong repo cục bộ), nhưng khi chuyển sang phiên bản sản xuất, chúng được
Điều đó được mong đợi: một mô-đun con bao gồm:
- một URL được đăng ký trong
.gitmodules - a gitlink, một mục nhập đặc biệt trong chỉ mục đại diện cho SHA1 của cây gốc của kho lưu trữ mô-đun con.
Khi bạn sao chép một kho lưu trữ từ xa với các mô-đun con (bằng cách sử dụng git clone --recurse-submodulestùy chọn, các kho lưu trữ mô-đun con đó sẽ được nhân bản chính nó và được kiểm tra tại SHA1 được đại diện bởi gitlink đó.
"Đẩy vào sản xuất" là một việc khó khăn vì bạn không được phép đẩy đến một kho lưu trữ đã kiểm tra (không phải của người dùng) (ngay cả về mặt kỹ thuật, bạn cũng có thể làm được ).
Tốt hơn là nên đẩy đến một kho lưu trữ trống trên sản xuất, kho lưu trữ này sẽ sử dụng móc sau nhận để khôi phục các tệp (bao gồm cả nội dung mô-đun con, bằng cách sử dụng git restore --recurse-submodules)
Sau khi thảo luận :
Bạn cần máy chủ sản xuất đăng ký khóa SSH công khai cho tài khoản của mình, vì các mô-đun con được đăng ký
.gitmodulesbằng URL SSH.Tập lệnh sau khi nhận sẽ trở thành:
#!/bin/bash cd /var/www/repo git --git-dir=/var/git_repos/repo.git --work-tree=. restore --recurse-submodules :/
Với git submodule, bạn không thể thiết lập cây làm việc rõ ràng
Điều đó có nghĩa là, nếu các mô-đun con có liên quan, thì thư mục hiện tại của bạn phải là cây làm việc.
Sau đó, bạn có thể thực hiện các lệnh như git checkout/ git restorewith --recurse-submodules, hoặc git submodule update --init, thậm chí với một git-dir ( --git-dir=/path/to/bare/repo.git) khác.
Các mô-đun con sẽ được cập nhật vì cây làm việc hiện tại của bạn là cây phù hợp.
Nếu bạn đang ở bất kỳ đâu /var/www/repo, ngay cả khi bạn chỉ định git --work-tree=/var/www/repo ..., không có lệnh nào trong số các lệnh nói trên git checkout/ git restorewith --recurse-submodules, hoặc git submodule update --initsẽ hoạt động đối với các mô-đun con của repo của bạn.
Đó là: Các /var/www/repotệp của bạn sẽ được khôi phục, nhưng các mô-đun con sẽ vẫn trống.