Bagaimana saya bisa menentukan cabang / tag saat menambahkan submodule Git?

Bagaimana cara git submodule add -bkerjanya?

Setelah menambahkan submodule dengan cabang tertentu, repositori baru yang dikloning (setelah git submodule update --init) akan berada di komit tertentu, bukan cabang itu sendiri ( git statuspada submodule menunjukkan "Tidak saat ini di cabang mana pun").

Saya tidak dapat menemukan informasi tentang .gitmodulesatau .git/configtentang cabang submodule atau komit tertentu, jadi bagaimana cara Git mengetahuinya?

Selain itu, apakah mungkin untuk menentukan tag bukan cabang?

Saya menggunakan versi 1.6.5.2.

Catatan: Git 1.8.2 menambahkan kemungkinan untuk melacak cabang. Lihat beberapa jawaban di bawah ini.

Agak membingungkan untuk membiasakan diri dengan hal ini, tetapi submodula tidak ada di cabang. Mereka, seperti yang Anda katakan, hanyalah sebuah penunjuk ke komit tertentu dari repositori submodule.

Ini berarti, ketika orang lain memeriksa repositori Anda, atau menarik kode Anda, dan melakukan pembaruan submodule, submodule tersebut diperiksa oleh komit tertentu.

Ini bagus untuk submodule yang tidak sering berubah, karena dengan demikian semua orang di proyek dapat memiliki submodule pada komit yang sama.

Jika Anda ingin memindahkan submodule ke tag tertentu:

cd submodule_directory
git checkout v1.0
cd ..
git add submodule_directory
git commit -m "moved submodule to v1.0"
git push

Kemudian, pengembang lain yang ingin memiliki submodule_directory berubah menjadi tag itu, melakukan ini

git pull
git submodule update --init

git pullperubahan yang menunjukkan direktori submodule mereka. git submodule updatesebenarnya menyatu dalam kode baru.

Saya ingin menambahkan jawaban di sini yang sebenarnya hanya konglomerat dari jawaban lain, tetapi saya pikir ini mungkin lebih lengkap.

Anda tahu Anda memiliki submission Git ketika Anda memiliki dua hal ini.

1. Anda .gitmodulesmemiliki sebuah entri seperti:

   [submodule "SubmoduleTestRepo"]
       path = SubmoduleTestRepo
       url = https://github.com/jzaccone/SubmoduleTestRepo.git
   

2. Anda memiliki objek submodule (bernama SubmoduleTestRepo dalam contoh ini) di repositori Git Anda. GitHub menunjukkan ini sebagai objek "submodule". Atau lakukangit submodule status dari baris perintah. Objek submit Git adalah jenis khusus objek Git, dan mereka menyimpan informasi SHA untuk komit tertentu.

   Setiap kali Anda melakukan git submodule update, itu akan mengisi submodule Anda dengan konten dari komit. Ia tahu di mana menemukan komit karena informasi dalam .gitmodules.

   Sekarang, yang harus -bdilakukan adalah menambahkan satu baris dalam .gitmodulesfile Anda . Jadi mengikuti contoh yang sama, akan terlihat seperti ini:

   [submodule "SubmoduleTestRepo"]
       path = SubmoduleTestRepo
       url = https://github.com/jzaccone/SubmoduleTestRepo.git
       branch = master
   

   Catatan: hanya nama cabang yang didukung dalam .gitmodulesfile, tetapi SHA dan TAG tidak didukung! (Alih-alih itu, komit cabang dari setiap modul dapat dilacak dan diperbarui menggunakan " git add .", misalnya seperti git add ./SubmoduleTestRepo, dan Anda tidak perlu mengubah .gitmodulesfile setiap kali)

   Objek submodule masih menunjuk komit tertentu. Satu-satunya -bpilihan yang dibeli oleh Anda adalah kemampuan untuk menambahkan --remotebendera pada pembaruan Anda sesuai jawaban Vogella:

   git submodule update --remote
   

   Alih-alih mengisi konten submodule ke komit yang ditunjuk oleh submodule, itu menggantikan komit dengan komit terbaru di cabang master, MAKA ia mengisi submodule dengan komit itu. Ini dapat dilakukan dalam dua langkah dengan jawaban djacobs7. Karena Anda sekarang telah memperbarui komit objek submodule menunjuk, Anda harus komit objek submodule yang diubah ke repositori Git Anda.

   git submodule add -bbukan cara ajaib untuk menjaga semuanya tetap up to date dengan cabang. Itu hanya menambahkan informasi tentang cabang dalam .gitmodulesfile dan memberi Anda pilihan untuk memperbarui objek submodule ke komit terbaru dari cabang tertentu sebelum mengisinya.

(Git 2.22, Q2 2019, telah diperkenalkan git submodule set-branch --branch aBranch -- <submodule_path>)

Perhatikan bahwa jika Anda memiliki yang ada submodule yang tidak melacak cabang belum , maka ( jika Anda memiliki 1.8.2+ git ):

• Pastikan repo induk tahu bahwa submodule-nya sekarang melacak cabang:

  cd /path/to/your/parent/repo
  git config -f .gitmodules submodule.<path>.branch <branch>
  

• Pastikan submodule Anda paling lambat dari cabang itu:

  cd path/to/your/submodule
  git checkout -b branch --track origin/branch
    # if the master branch already exist:
    git branch -u origin/master master
  

         (dengan 'asal' menjadi nama repo jarak jauh hulu , submodule telah dikloning.
         Bagian git remote -vdalam submodule akan menampilkannya. Biasanya, itu 'asal')

• Jangan lupa untuk mencatat status submodule baru Anda di repo orang tua Anda:

  cd /path/to/your/parent/repo
  git add path/to/your/submodule
  git commit -m "Make submodule tracking a branch"
  

• Pembaruan berikutnya untuk submodule itu harus menggunakan --remoteopsi:

  # 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 
  

Perhatikan bahwa dengan Git 2.10+ (Q3 2016), Anda dapat menggunakan ' .' sebagai nama cabang:

Nama cabang dicatat seperti submodule.<name>.branchdalam .gitmodulesuntuk update --remote.
Nilai khusus .digunakan untuk menunjukkan bahwa nama cabang dalam submodule harus nama yang sama dengan cabang saat ini di repositori saat ini .

Tapi, seperti dikomentari oleh LubosD

Dengan git checkout, jika nama cabang yang diikuti adalah " .", itu akan mematikan pekerjaan Anda yang tidak berkomitmen!
Gunakan git switchsebagai gantinya.

Itu berarti Git 2.23 (Agustus 2019) atau lebih.

Lihat " Bingung olehgit checkout "

Jika Anda ingin memperbarui semua submodul Anda mengikuti cabang:

    git submodule update --recursive --remote

Perhatikan bahwa hasilnya, untuk setiap submodule yang diperbarui, akan hampir selalu menjadi HEAD terpisah , seperti yang dicatat Dan Cameron dalam jawabannya .

( Clintm mencatat dalam komentar bahwa, jika Anda menjalankan git submodule update --remotedan sha1 yang dihasilkan sama dengan cabang saat submodule aktif, ia tidak akan melakukan apa pun dan membiarkan submodule tetap "pada cabang itu" dan tidak dalam keadaan kepala terpisah. )

Untuk memastikan cabang benar-benar diperiksa (dan itu tidak akan mengubah SHA1 dari entri khusus yang mewakili submodule untuk repo induk), ia menyarankan:

git submodule foreach -q --recursive 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; git switch $branch'

Setiap submodule masih akan mereferensikan SHA1 yang sama, tetapi jika Anda membuat komitmen baru, Anda akan bisa mendorongnya karena dirujuk oleh cabang yang Anda ingin submodule dilacak.
Setelah dorongan dalam submodule, jangan lupa untuk kembali ke induk repo, tambahkan, komit dan tekan SHA1 baru untuk submodul yang dimodifikasi.

Perhatikan penggunaan $toplevel, direkomendasikan dalam komentar oleh Alexander Pogrebnyak .
$topleveldiperkenalkan di git1.7.2 pada Mei 2010: commit f030c96 .

ini berisi jalur absolut dari direktori tingkat atas (di mana .gitmodules).

dtmlandmenambahkan komentar :

Skrip foreach akan gagal untuk checkout submodules yang tidak mengikuti cabang.
Namun, perintah ini memberi Anda berdua:

 git submodule foreach -q --recursive 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; [ "$branch" = "" ] && git checkout master || git switch $branch' –

Perintah yang sama tetapi lebih mudah dibaca:

git submodule foreach -q --recursive \
    'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; \
     [ "$branch" = "" ] && \
     git checkout master || git switch $branch' –

umläute memurnikan perintah dtmland dengan versi yang disederhanakan dalam komentar :

git submodule foreach -q --recursive 'git switch $(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'

beberapa baris:

git submodule foreach -q --recursive \
  'git switch \
  $(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'

Sebelum Git 2.26 (Q1 2020), pengambilan yang diperintahkan untuk secara rekursif mengambil pembaruan dalam submodul pasti menghasilkan rim output, dan itu menjadi sulit untuk menemukan pesan kesalahan.

Perintah telah diajarkan untuk menyebutkan submodul yang memiliki kesalahan pada akhir operasi .

Lihat komit 0222540 (16 Jan 2020) oleh Emily Shaffer ( nasamuffin) .
^{(Digabung oleh Junio ​​C Hamano - gitster- dalam commit b5c71cc , 05 Feb 2020)}

fetch: tekankan kegagalan selama pengambilan submodule

^{Ditandatangani oleh: Emily Shaffer}

Dalam kasus ketika pengambilan submodule gagal ketika ada banyak submodul, kesalahan dari pengambilan submodul yang gagal dikuburkan di bawah aktivitas pada submodul lain jika lebih dari satu pengambilan diambil kembali fetch-by-oid.
Sebut kegagalan terlambat sehingga pengguna sadar bahwa ada masalah, dan di mana .

Karena fetch_finish()hanya dipanggil secara sinkron dengan run_processes_parallel,mutex tidak diperlukan di sekitar submodules_with_errors.

Git 1.8.2 menambahkan kemungkinan untuk melacak cabang.

# add submodule to track master branch
git submodule add -b branch_name URL_to_Git_repo optional_directory_rename

# update your submodule
git submodule update --remote 

Lihat juga Git submodules

Contoh cara saya menggunakan submit Git.

1. Buat repositori baru
2. Kemudian klon repositori lain sebagai submodule
3. Kemudian kita memiliki submodule yang menggunakan tag yang disebut V3.1.2
4. Dan kemudian kita berkomitmen.

Dan itu terlihat sedikit seperti ini:

git init 
vi README
git add README
git commit 
git submodule add git://github.com/XXXXX/xxx.yyyy.git stm32_std_lib
git status

git submodule init
git submodule update

cd stm32_std_lib/
git reset --hard V3.1.2 
cd ..
git commit -a

git submodule status 

Mungkin ini membantu (meskipun saya menggunakan tag dan bukan cabang)?

Dalam pengalaman saya beralih cabang di proyek super atau checkout di masa depan masih akan menyebabkan kepala HEADs submodules terlepas apakah submodule ditambahkan dan dilacak dengan benar (yaitu @ djacobs7 dan @Johnny Z jawaban).

Dan bukannya secara manual memeriksa cabang yang benar secara manual atau melalui skrip submodule git dapat digunakan.

Ini akan memeriksa file konfigurasi submodule untuk properti cabang dan checkout cabang yang ditetapkan.

git submodule foreach -q --recursive 'branch="$(git config -f <path>.gitmodules submodule.$name.branch)"; git checkout $branch'

Git submodules agak aneh - mereka selalu dalam mode "kepala terpisah" - mereka tidak memperbarui ke komit terbaru pada cabang seperti yang Anda harapkan.

Ini masuk akal ketika Anda memikirkannya. Katakanlah saya membuat repositori foo dengan bilah submodule . Saya mendorong perubahan saya dan memberitahu Anda untuk memeriksa melakukan a7402be dari repositori foo .

Kemudian bayangkan seseorang melakukan perubahan pada bilah repositori sebelum Anda dapat membuat klon Anda.

Ketika Anda memeriksa komit a7402be dari repositori foo , Anda berharap untuk mendapatkan kode yang sama saya mendorong. Itu sebabnya submodul tidak diperbarui sampai Anda memberi tahu mereka secara eksplisit dan kemudian membuat komit baru.

Secara pribadi saya pikir submodul adalah bagian yang paling membingungkan dari Git. Ada banyak tempat yang dapat menjelaskan submodul lebih baik daripada saya. Saya merekomendasikan Pro Git oleh Scott Chacon.

Untuk beralih cabang untuk submodule (dengan asumsi Anda sudah memiliki submodule sebagai bagian dari repositori):

• cd untuk me-root repositori Anda yang berisi submodules
• Buka .gitmodulesuntuk diedit
• Tambahkan baris di bawah ini path = ...dan url = ...mengatakan branch = your-branch, untuk setiap submodule; simpan file .gitmodules.
• maka tanpa mengubah direktori lakukan $ git submodule update --remote

... ini harus menarik komit terbaru pada cabang yang ditentukan, untuk setiap submodule yang dimodifikasi.

Saya memilikinya di file .gitconfig saya. Ini masih konsep, tetapi terbukti bermanfaat sampai sekarang. Ini membantu saya untuk selalu menempelkan kembali submodul ke cabang mereka.

[alias]

######################
#
#Submodules aliases
#
######################


#git sm-trackbranch : places all submodules on their respective branch specified in .gitmodules
#This works if submodules are configured to track a branch, i.e if .gitmodules looks like :
#[submodule "my-submodule"]
#   path = my-submodule
#   url = [email protected]/my-submodule.git
#   branch = my-branch
sm-trackbranch = "! git submodule foreach -q --recursive 'branch=\"$(git config -f $toplevel/.gitmodules submodule.$name.branch)\"; git checkout $branch'"

#sm-pullrebase :
# - pull --rebase on the master repo
# - sm-trackbranch on every submodule
# - pull --rebase on each submodule
#
# Important note :
#- have a clean master repo and subrepos before doing this !
#- this is *not* equivalent to getting the last committed 
#  master repo + its submodules: if some submodules are tracking branches 
#  that have evolved since the last commit in the master repo,
#  they will be using those more recent commits !
#
#  (Note : On the contrary, git submodule update will stick 
#to the last committed SHA1 in the master repo)
#
sm-pullrebase = "! git pull --rebase; git submodule update; git sm-trackbranch ; git submodule foreach 'git pull --rebase' "

# git sm-diff will diff the master repo *and* its submodules
sm-diff = "! git diff && git submodule foreach 'git diff' "

#git sm-push will ask to push also submodules
sm-push = push --recurse-submodules=on-demand

#git alias : list all aliases
#useful in order to learn git syntax
alias = "!git config -l | grep alias | cut -c 7-"

Kami menggunakan Quack untuk menarik modul tertentu dari repositori Git lain. Kita perlu menarik kode tanpa seluruh basis kode dari repositori yang disediakan - kita membutuhkan modul / file yang sangat spesifik dari repositori besar itu dan harus diperbarui setiap kali kita menjalankan pembaruan.

Jadi kami mencapainya dengan cara ini:

Buat konfigurasi

name: Project Name

modules:
  local/path:
    repository: https://github.com/<username>/<repo>.git
    path: repo/path
    branch: dev
  other/local/path/filename.txt:
    repository: https://github.com/<username>/<repo>.git
    hexsha: 9e3e9642cfea36f4ae216d27df100134920143b9
    path: repo/path/filename.txt

profiles:
  init:
    tasks: ['modules']

Dengan konfigurasi di atas, ia membuat satu direktori dari repositori GitHub yang disediakan sebagaimana ditentukan dalam konfigurasi modul pertama, dan yang lainnya adalah untuk menarik dan membuat file dari repositori yang diberikan.

Pengembang lain hanya perlu dijalankan

$ quack

Dan itu menarik kode dari konfigurasi di atas.

Satu-satunya efek dari memilih cabang untuk submodule adalah bahwa, setiap kali Anda melewati --remoteopsi di git submodule updatebaris perintah, Git akan memeriksa dalam mode HEAD terlepas (jika --checkoutperilaku default dipilih) komit terbaru dari cabang jauh yang dipilih .

Anda harus sangat berhati-hati saat menggunakan fitur pelacakan cabang jarak jauh ini untuk submodula Git jika Anda bekerja dengan klon submodul yang dangkal. Cabang yang Anda pilih untuk tujuan ini dalam pengaturan submodule BUKAN cabang yang akan dikloning selama git submodule update --remote. Jika Anda lulus juga --depthparameternya dan Anda tidak memberi tahu Git tentang cabang mana yang ingin Anda klon - dan sebenarnya Anda tidak bisa di git submodule updatebaris perintah !! -, ia akan secara implisit berperilaku seperti dijelaskan dalam git-clone(1)dokumentasi git clone --single-branchketika --branchparameter eksplisit hilang, dan karena itu akan mengkloning cabang utama saja .

Tanpa mengherankan, setelah tahap kloning dilakukan oleh git submodule updateperintah, akhirnya akan mencoba untuk memeriksa komit terbaru untuk cabang jarak jauh yang sebelumnya Anda atur untuk submodule, dan, jika ini bukan yang utama, itu bukan bagian dari klon dangkal lokal Anda, dan karenanya akan gagal dengan

fatal: Membutuhkan satu revisi

Tidak dapat menemukan asal saat ini / revisi NotThePrimaryBranch di jalur submodule 'mySubmodule'

git submodule add -b mengembangkan --name branch-name - https: //branch.git