(Git 2.22, quý 2 năm 2019, đã giới thiệu git submodule set-branch --branch aBranch -- <submodule_path>)
Lưu ý rằng nếu bạn có một mô hình con hiện tại chưa theo dõi một nhánh , thì ( nếu bạn có git 1.8.2+ ):
Hãy chắc chắn rằng repo cha biết rằng mô hình con của nó hiện theo dõi một nhánh:
cd /path/to/your/parent/repo
git config -f .gitmodules submodule.<path>.branch <branch>
Hãy chắc chắn rằng mô hình con của bạn thực sự là muộn nhất của nhánh đó:
cd path/to/your/submodule
git checkout -b branch --track origin/branch
# if the master branch already exist:
git branch -u origin/master master
(với 'nguồn gốc' là tên của repo từ xa ngược dòng , mô hình con đã được sao chép từ.
Mộtgit remote -vbên trong mô hình con đó sẽ hiển thị nó. Thông thường, đó là 'origin')
Đừng quên ghi lại trạng thái mới của mô hình con trong repo cha mẹ của bạn:
cd /path/to/your/parent/repo
git add path/to/your/submodule
git commit -m "Make submodule tracking a branch"
Bản cập nhật tiếp theo cho mô hình con đó sẽ phải sử dụng --remotetùy chọn:
# update your submodule
# --remote will also fetch and ensure that
# the latest commit from the branch is used
git submodule update --remote
# to avoid fetching use
git submodule update --remote --no-fetch
Lưu ý rằng với Git 2.10+ (quý 3 năm 2016), bạn có thể sử dụng ' .' làm tên chi nhánh:
Tên của chi nhánh được ghi nhận là submodule.<name>.branchtrong .gitmodulescho update --remote.
Một giá trị đặc biệt .được sử dụng để chỉ ra rằng tên của nhánh trong mô hình con phải cùng tên với nhánh hiện tại trong kho lưu trữ hiện tại .
Nhưng, như đã nhận xét của LubosD
Với git checkout, nếu tên chi nhánh phải theo là " .", nó sẽ giết chết công việc không được cam kết của bạn!
Sử dụnggit switch thay thế.
Điều đó có nghĩa là Git 2.23 (tháng 8 năm 2019) trở lên.
Xem " Bối rối bởigit checkout "
Nếu bạn muốn cập nhật tất cả các mô hình con của bạn theo một nhánh:
git submodule update --recursive --remote
Lưu ý rằng kết quả, đối với mỗi mô hình con được cập nhật, hầu như sẽ luôn là một ĐẦU tách rời , như Dan Cameron lưu ý trong câu trả lời của mình .
( Ghi chú của Clintm trong các bình luận rằng, nếu bạn chạy git submodule update --remotevà kết quả sha1 giống với nhánh mà mô hình con hiện đang hoạt động, nó sẽ không làm gì cả và để mô hình con vẫn "ở nhánh đó" và không ở trạng thái đầu tách ra. )
Để đảm bảo chi nhánh thực sự được kiểm tra (và điều đó sẽ không sửa đổi SHA1 của mục đặc biệt đại diện cho mô hình con cho repo cha), ông gợi ý:
git submodule foreach -q --recursive 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; git switch $branch'
Mỗi mô hình con vẫn sẽ tham chiếu cùng một SHA1, nhưng nếu bạn thực hiện các cam kết mới, bạn sẽ có thể đẩy chúng bởi vì chúng sẽ được tham chiếu bởi nhánh mà bạn muốn mô hình con theo dõi.
Sau lần đẩy đó trong một mô hình con, đừng quên quay lại repo cha, thêm, cam kết và đẩy SHA1 mới cho các mô hình con được sửa đổi đó.
Lưu ý việc sử dụng $toplevel, được đề xuất trong các ý kiến của Alexander Pogrebnyak .
$toplevelđã được giới thiệu trong git1.7.2 vào tháng 5 năm 2010: commit f030c96 .
nó chứa đường dẫn tuyệt đối của thư mục cấp cao nhất (ở đâu .gitmodules).
dtmlandthêm vào trong các ý kiến :
Kịch bản foreach sẽ không kiểm tra các mô đun con không theo nhánh.
Tuy nhiên, lệnh này cung cấp cho bạn cả hai:
git submodule foreach -q --recursive 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; [ "$branch" = "" ] && git checkout master || git switch $branch' –
Lệnh tương tự nhưng dễ đọc hơn:
git submodule foreach -q --recursive \
'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; \
[ "$branch" = "" ] && \
git checkout master || git switch $branch' –
umläute tinh chỉnh lệnh của dtmland với một phiên bản đơn giản hóa trong các ý kiến :
git submodule foreach -q --recursive 'git switch $(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'
nhiều dòng:
git submodule foreach -q --recursive \
'git switch \
$(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'
Trước Git 2.26 (Q1 2020), một lần tìm nạp được yêu cầu tìm nạp đệ quy các bản cập nhật trong các mô hình con chắc chắn tạo ra các luồng đầu ra và rất khó phát hiện ra các thông báo lỗi.
Lệnh đã được dạy để liệt kê các mô đun con có lỗi ở cuối hoạt động .
Xem cam kết 0222540 (ngày 16 tháng 1 năm 2020) bởi Emily Shaffer ( nasamuffin) .
(Được hợp nhất bởi Junio C Hamano - gitster- trong cam kết b5c71cc , ngày 5 tháng 2 năm 2020)
fetch: nhấn mạnh sự thất bại trong quá trình tìm nạp mô hình con
Đã ký tắt: Emily Shaffer
Trong trường hợp khi tìm nạp mô hình con không thành công khi có nhiều mô hình con, lỗi từ quá trình tìm nạp mô hình con đơn độc bị chôn vùi dưới hoạt động trên các mô hình con khác nếu có nhiều hơn một lần tìm nạp lại fetch-by-oid.
Gọi ra một lỗi muộn để người dùng nhận thức được rằng đã xảy ra lỗi và ở đâu .
Bởi vì fetch_finish()chỉ được gọi một cách đồng bộ bằng cách run_processes_parallel,biến đổi không bắt buộc xung quanh submodules_with_errors.