Cập nhật mô hình con Git để cam kết mới nhất về nguồn gốc

Tôi có một dự án với một mô hình con Git. Đó là từ một ssh: // ... URL và là trên cam kết A. Cam kết B đã được đẩy tới URL đó và tôi muốn mô hình con lấy lại cam kết và thay đổi nó.

Bây giờ, sự hiểu biết của tôi là git submodule updatenên làm điều này, nhưng nó không. Nó không làm gì cả (không có đầu ra, mã thoát thành công). Đây là một ví dụ:

$ mkdir foo
$ cd foo
$ git init .
Initialized empty Git repository in /.../foo/.git/
$ git submodule add ssh://user@host/git/mod mod
Cloning into mod...
user@host's password: hunter2
remote: Counting objects: 131, done.
remote: Compressing objects: 100% (115/115), done.
remote: Total 131 (delta 54), reused 0 (delta 0)
Receiving objects: 100% (131/131), 16.16 KiB, done.
Resolving deltas: 100% (54/54), done.
$ git commit -m "Hello world."
[master (root-commit) 565b235] Hello world.
 2 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100644 .gitmodules
 create mode 160000 mod
# At this point, ssh://user@host/git/mod changes; submodule needs to change too.
$ git submodule init
Submodule 'mod' (ssh://user@host/git/mod) registered for path 'mod'
$ git submodule update
$ git submodule sync
Synchronizing submodule url for 'mod'
$ git submodule update
$ man git-submodule 
$ git submodule update --rebase
$ git submodule update
$ echo $?
0
$ git status
# On branch master
nothing to commit (working directory clean)
$ git submodule update mod
$ ...

Tôi cũng đã cố gắng git fetch mod, mà dường như làm một lấy (nhưng có thể không có khả năng, bởi vì nó không khiến cho một mật khẩu!), Nhưng git logvà git showphủ nhận sự tồn tại của các cam kết mới. Cho đến nay tôi chỉ đang rmsử dụng mô-đun và thêm lại nó, nhưng điều này cả về nguyên tắc và tẻ nhạt trong thực tế.

Các git submodule updatelệnh thực sự nói với Git mà bạn muốn submodules của bạn để mỗi lần kiểm tra ra các cam kết đã được quy định trong chỉ mục của superproject. Nếu bạn muốn cập nhật các mô hình con của bạn lên cam kết mới nhất có sẵn từ xa của chúng, bạn sẽ cần phải thực hiện việc này trực tiếp trong các mô hình con.

Vì vậy, tóm lại:

# Get the submodule initially
git submodule add ssh://bla submodule_dir
git submodule init

# Time passes, submodule upstream is updated
# and you now want to update

# Change to the submodule directory
cd submodule_dir

# Checkout desired branch
git checkout master

# Update
git pull

# Get back to your project root
cd ..

# Now the submodules are in the state you want, so
git commit -am "Pulled down update to submodule_dir"

Hoặc, nếu bạn là một người bận rộn:

git submodule foreach git pull origin master

Git 1.8.2 có một tùy chọn mới --remote, sẽ cho phép chính xác hành vi này. Đang chạy

git submodule update --remote --merge

sẽ lấy các thay đổi mới nhất từ ​​thượng nguồn trong mỗi mô hình con, hợp nhất chúng vào và kiểm tra phiên bản mới nhất của mô hình con. Như tài liệu đưa ra:

--Xa xôi

Tùy chọn này chỉ hợp lệ cho lệnh cập nhật. Thay vì sử dụng SHA-1 được ghi lại của siêu dự án để cập nhật mô hình con, hãy sử dụng trạng thái của nhánh theo dõi từ xa của mô hình con.

Điều này tương đương với việc chạy git pulltrong mỗi mô hình con, thường là chính xác những gì bạn muốn.

Trong thư mục cha mẹ dự án của bạn, chạy:

git submodule update --init

Hoặc nếu bạn có các mô đun con đệ quy chạy:

git submodule update --init --recursive

Đôi khi điều này vẫn không hoạt động, bởi vì bằng cách nào đó bạn có những thay đổi cục bộ trong thư mục mô đun con cục bộ trong khi mô hình con đang được cập nhật.

Hầu hết thời gian thay đổi cục bộ có thể không phải là thay đổi bạn muốn cam kết. Nó có thể xảy ra do xóa tệp trong mô hình con của bạn, v.v. Nếu vậy, hãy thiết lập lại trong thư mục mô hình con cục bộ và trong thư mục cha mẹ dự án của bạn, chạy lại:

git submodule update --init --recursive

Dự án chính của bạn chỉ ra một cam kết cụ thể mà mô hình con nên ở. git submodule updatecố gắng kiểm tra cam kết đó trong mỗi mô hình con đã được khởi tạo. Subodule thực sự là một kho lưu trữ độc lập - chỉ cần tạo một cam kết mới trong mô hình con và đẩy nó là không đủ. Bạn cũng cần thêm một cách rõ ràng phiên bản mới của mô hình con trong dự án chính.

Vì vậy, trong trường hợp của bạn, bạn nên tìm đúng cam kết trong mô hình con - hãy giả sử đó là mẹo của master :

cd mod
git checkout master
git pull origin master

Bây giờ quay trở lại dự án chính, giai đoạn mô hình con và cam kết rằng:

cd ..
git add mod
git commit -m "Updating the submodule 'mod' to the latest version"

Bây giờ đẩy phiên bản mới của dự án chính của bạn:

git push origin master

Từ thời điểm này, nếu có ai cập nhật dự án chính của họ, thì git submodule updateđối với họ sẽ cập nhật mô hình con, giả sử nó đã được khởi tạo.

Có vẻ như hai kịch bản khác nhau đang được trộn lẫn với nhau trong cuộc thảo luận này:

cảnh 1

Sử dụng các con trỏ của kho lưu trữ cha mẹ của tôi cho các mô hình con, tôi muốn kiểm tra cam kết trong mỗi mô hình con mà kho lưu trữ mẹ đang trỏ tới, có thể sau lần lặp đầu tiên qua tất cả các mô hình con và cập nhật / kéo chúng từ xa.

Điều này, như đã chỉ ra, được thực hiện với

git submodule foreach git pull origin BRANCH
git submodule update

Kịch bản 2, mà tôi nghĩ là những gì OP đang nhắm đến

Nội dung mới đã xảy ra trong một hoặc nhiều mô hình con và tôi muốn 1) kéo các thay đổi này và 2) cập nhật kho lưu trữ cha mẹ để trỏ đến cam kết CHÍNH (mới nhất) của các mô hình con này.

Điều này sẽ được thực hiện bởi

git submodule foreach git pull origin BRANCH
git add module_1_name
git add module_2_name
......
git add module_n_name
git push origin BRANCH

Không thực tế lắm, vì bạn sẽ phải mã hóa n đường dẫn đến tất cả các mô hình con n, ví dụ như một tập lệnh để cập nhật các con trỏ cam kết của kho lưu trữ mẹ.

Sẽ thật tuyệt khi có một lần lặp tự động thông qua mỗi mô hình con, cập nhật con trỏ kho lưu trữ cha mẹ (sử dụng git add ) để trỏ đến phần đầu của mô hình con.

Đối với điều này, tôi đã thực hiện kịch bản Bash nhỏ này:

git-update-submodules.sh

#!/bin/bash

APP_PATH=$1
shift

if [ -z $APP_PATH ]; then
  echo "Missing 1st argument: should be path to folder of a git repo";
  exit 1;
fi

BRANCH=$1
shift

if [ -z $BRANCH ]; then
  echo "Missing 2nd argument (branch name)";
  exit 1;
fi

echo "Working in: $APP_PATH"
cd $APP_PATH

git checkout $BRANCH && git pull --ff origin $BRANCH

git submodule sync
git submodule init
git submodule update
git submodule foreach "(git checkout $BRANCH && git pull --ff origin $BRANCH && git push origin $BRANCH) || true"

for i in $(git submodule foreach --quiet 'echo $path')
do
  echo "Adding $i to root repo"
  git add "$i"
done

git commit -m "Updated $BRANCH branch of deployment repo to point to latest head of submodules"
git push origin $BRANCH

Để chạy nó, thực thi

git-update-submodules.sh /path/to/base/repo BRANCH_NAME

Xây dựng

Trước hết, tôi giả sử rằng nhánh có tên $ BRANCH (đối số thứ hai) tồn tại trong tất cả các kho lưu trữ. Hãy làm cho điều này thậm chí còn phức tạp hơn.

Một vài phần đầu tiên là một số kiểm tra rằng các đối số là có. Sau đó, tôi lấy nội dung mới nhất của kho lưu trữ cha mẹ (tôi thích sử dụng --ff (chuyển tiếp nhanh) bất cứ khi nào tôi chỉ thực hiện thao tác kéo. Tôi đã loại bỏ, BTW).

git checkout $BRANCH && git pull --ff origin $BRANCH

Sau đó, một số khởi tạo mô hình con, có thể là cần thiết, nếu các mô hình con mới đã được thêm hoặc chưa được khởi tạo:

git submodule sync
git submodule init
git submodule update

Sau đó, tôi cập nhật / kéo tất cả các mô hình con:

git submodule foreach "(git checkout $BRANCH && git pull --ff origin $BRANCH && git push origin $BRANCH) || true"

Lưu ý một số điều: Trước hết, tôi đang xâu chuỗi một số lệnh Git bằng cách sử dụng &&- có nghĩa là lệnh trước đó phải thực thi mà không gặp lỗi.

Sau khi kéo thành công có thể (nếu tìm thấy công cụ mới trên điều khiển từ xa), tôi thực hiện một cú đẩy để đảm bảo rằng một cam kết hợp nhất có thể không bị bỏ lại trên máy khách. Một lần nữa, nó chỉ xảy ra nếu một cú kéo thực sự mang lại những thứ mới.

Cuối cùng, trận chung kết || trueđảm bảo rằng kịch bản tiếp tục bị lỗi. Để thực hiện công việc này, mọi thứ trong phép lặp phải được gói trong dấu ngoặc kép và các lệnh Git được gói trong dấu ngoặc đơn (ưu tiên toán tử).

Phần ưa thích của tôi:

for i in $(git submodule foreach --quiet 'echo $path')
do
  echo "Adding $i to root repo"
  git add "$i"
done

Lặp lại tất cả các mô hình con - với --quiet, loại bỏ đầu ra 'Nhập MODULE_PATH'. Sử dụng'echo $path' (phải ở trong dấu ngoặc đơn), đường dẫn đến mô hình con được ghi vào đầu ra.

Danh sách các đường dẫn mô hình con tương đối này được ghi lại trong một mảng ( $(...)) - cuối cùng lặp lại điều này và làm git add $iđể cập nhật kho lưu trữ mẹ.

Cuối cùng, một cam kết với một số thông báo giải thích rằng kho lưu trữ mẹ đã được cập nhật. Cam kết này sẽ bị bỏ qua theo mặc định, nếu không có gì được thực hiện. Đẩy cái này về nguồn gốc, và bạn đã hoàn thành.

Tôi có một kịch bản chạy chương trình này trong một công việc của Jenkins , chuỗi này được triển khai tự động theo lịch trình sau đó và nó hoạt động như một cơ duyên.

Tôi hy vọng điều này sẽ giúp ích cho ai đó.

Đơn giản và đơn giản, để lấy các mô hình con:

git submodule update --init --recursive

Và bây giờ tiến hành cập nhật chúng lên nhánh chính mới nhất (ví dụ):

git submodule foreach git pull origin master

Lưu ý, trong khi hình thức cập nhật mô hình con hiện đại sẽ là:

git submodule update --recursive --remote --merge --force

Hình thức cũ hơn là:

git submodule foreach --quiet git pull --quiet origin

Ngoại trừ ... hình thức thứ hai này không thực sự "yên tĩnh".

Xem cam kết a282f5a (12 tháng 4 năm 2019) của Nguyễn Thái Ngọc Duy ( pclouds) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết F1c9f6c , ngày 25 tháng 4 năm 2019)}

submodule foreach: sửa lỗi " <command> --quiet" không được tôn trọng

Robin báo cáo rằng

git submodule foreach --quiet git pull --quiet origin

không thực sự yên tĩnh nữa.
Cần im lặng trước fc1b924 ( submodule: port submodulesubcommand ' foreach' từ shell sang C, 2018-05-10, Git v2.19.0-rc0) vìparseopt sau đó không thể vô tình ăn các tùy chọn.

" git pull" Hành xử như thể --quietkhông được đưa ra.

Điều này xảy ra bởi vì parseopttrong submodule--helpersẽ cố gắng phân tích cả--quiet tùy chọn như thể chúng là tùy chọn foreach, không phải git-pull's.
Các tùy chọn được phân tích cú pháp được loại bỏ khỏi dòng lệnh. Vì vậy, khi chúng tôi kéo sau, chúng tôi thực hiện điều này

git pull origin

Khi gọi trình trợ giúp mô đun con, thêm "-- " ở phía trước " git pull" sẽ dừng lại parseoptđể phân tích các tùy chọn không thực sự thuộc về submodule--helper foreach.

PARSE_OPT_KEEP_UNKNOWN được gỡ bỏ như một biện pháp an toàn. parseoptkhông bao giờ thấy các tùy chọn không xác định hoặc một cái gì đó đã đi sai. Ngoài ra còn có một vài cập nhật chuỗi sử dụng trong khi tôi đang xem chúng.

Trong khi ở đó, tôi cũng thêm " --" vào các tiểu ban khác vượt qua " $@" submodule--helper. " $@" trong những trường hợp này là các đường dẫn và ít có khả năng hơn --something-like-this.
Nhưng quan điểm vẫn đứng, git-submoduleđã phân tích và phân loại các tùy chọn, các đường dẫn là gì.
submodule--helperkhông bao giờ nên xem xét các con đường đi quagit-submodule là các tùy chọn ngay cả khi chúng trông giống như một.

Và Git 2.23 (quý 3 năm 2019) khắc phục một sự cố khác: "git submodule foreach " không bảo vệ các tùy chọn dòng lệnh được truyền cho lệnh được chạy chính xác trong mỗi mô hình con, khi --recursivetùy chọn "" được sử dụng.

Xem cam kết 30db18b (24 tháng 6 năm 2019) của Morian Sonnet ( momoson) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết 968eecb , ngày 09 tháng 7 năm 2019)}

submodule foreach: sửa đệ quy các tùy chọn

Gọi điện thoại:

git submodule foreach --recursive <subcommand> --<option>

dẫn đến một lỗi cho biết tùy chọn --<option>không xác định submodule--helper.
Đó là tất nhiên, chỉ khi<option> là một lựa chọn hợp lệ git submodule foreach.

Lý do cho điều này là, cuộc gọi trên được dịch nội bộ thành cuộc gọi đến mô hình con - người trợ giúp:

git submodule--helper foreach --recursive \
    -- <subcommand> --<option>

Cuộc gọi này bắt đầu bằng cách thực hiện tiểu ban với tùy chọn của nó bên trong mô hình con cấp đầu tiên và tiếp tục bằng cách gọi lần lặp tiếp theo của submodule foreachcuộc gọi

git --super-prefix <submodulepath> submodule--helper \
   foreach --recursive <subcommand> --<option>

bên trong mô hình con cấp độ đầu tiên. Lưu ý rằng dấu gạch ngang kép ở phía trước của tiểu ban bị thiếu.

Vấn đề này chỉ bắt đầu phát sinh khi gần đây, PARSE_OPT_KEEP_UNKNOWNcờ cho phân tích cú pháp đối số git submodule foreachđã bị xóa trong cam kết a282f5a .
Do đó, tùy chọn chưa biết hiện đang bị phàn nàn vì phân tích cú pháp đối số không được kết thúc đúng bằng dấu gạch ngang kép.

Cam kết này khắc phục sự cố bằng cách thêm dấu gạch ngang ở phía trước của tiểu ban trong quá trình đệ quy.

git pull --recurse-submodules

Điều này sẽ kéo tất cả các cam kết mới nhất.

Trong trường hợp của tôi, tôi muốn git cập nhật lên bản mới nhất và đồng thời điền lại bất kỳ tệp bị thiếu nào.

Sau đây đã khôi phục các tệp bị thiếu (nhờ --forceđó dường như không được đề cập ở đây), nhưng nó không kéo theo bất kỳ cam kết mới nào:

git submodule update --init --recursive --force

Điều này đã làm:

git submodule update --recursive --remote --merge --force

@Jason đúng theo cách nhưng không hoàn toàn.

cập nhật

Cập nhật các mô hình con đã đăng ký, tức là nhân bản mô đun con bị thiếu và kiểm tra cam kết được chỉ định trong chỉ mục của kho chứa. Điều này sẽ làm cho các mô hình con CHÍNH bị tách ra trừ khi --rebase hoặc --merge được chỉ định hoặc mô hình con chính. $ Name.update được đặt thành rebase hoặc hợp nhất.

Vì vậy, git submodule updatekiểm tra, nhưng đó là cam kết trong chỉ mục của kho chứa. Nó vẫn chưa biết về cam kết mới ngược dòng nào cả. Vì vậy, đi đến mô hình con của bạn, nhận cam kết bạn muốn và cam kết trạng thái mô hình con được cập nhật trong kho lưu trữ chính và sau đó thực hiện git submodule update.

Đây là một lớp lót tuyệt vời để cập nhật mọi thứ mới nhất trên master:

git submodule foreach 'git fetch origin --tags; git checkout master; git pull' && git pull && git submodule update --init --recursive

Cảm ơn Mark Jaquith

Nếu bạn không biết chi nhánh máy chủ, hãy thực hiện điều này:

git submodule foreach git pull origin $(git rev-parse --abbrev-ref HEAD)

Nó sẽ nhận được một nhánh của kho lưu trữ Git chính và sau đó cho mỗi mô hình con sẽ tạo ra một lực kéo của cùng một nhánh.

Nếu bạn đang tìm cách kiểm tra masternhánh cho mỗi mô hình con - bạn có thể sử dụng lệnh sau cho mục đích đó:

git submodule foreach git checkout master