Apakah tag git didorong juga?


190

Sejak saya membuat repositori, tampaknya tag yang saya buat tidak didorong ke repositori. Ketika saya lakukan git tagdi direktori lokal semua tag ada, tetapi ketika saya masuk ke repositori jarak jauh dan melakukan git tag, hanya beberapa yang pertama muncul.

Apa masalahnya?


3
git push --follow-tagssekarang dapat bermanfaat, lihat jawaban saya di bawah ini
VonC


1
Setuju dengan duplikat: meskipun ini lebih tua, pertanyaan lain lebih baik diajukan.
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

Jawaban:


247

Anda bisa melakukan ini:

git push --tags

27
Saya cukup yakin itu berarti bahwa referensi HEAD tidak akan didorong, artinya Anda HANYA mendorong tag.
Dan Rosenstark

47
"Saya sarankan untuk tidak menggunakan atau melatih orang lain untuk menggunakan git push --tagskarena bisa sangat sulit untuk menyingkirkan tag buruk ketika rekan kerja Anda dilatih untuk mendorong semua tag, karena orang terus mendorong tag buruk lama yang mereka miliki secara lokal setiap kali mereka ingin mendorong tag baru. Karena ini, saya hanya akan menyarankan setiap orang untuk menggunakan git push origin <tag_name>sekarang. " - disalin dari stackoverflow.com/a/5195913/4130619
mengurangi aktivitas

Saya pikir jawaban lain, stackoverflow.com/a/16164809/11635 harus diterima. Bahkan jika tidak, itu pasti harus dibaca - itu memberikan pro dan kontra dan akhirnya jawaban yang lebih praktis dan benar untuk hari ini
Ruben Bartelink

140

Dalam konfigurasi git remote default Anda harus mendorong tag secara eksplisit (ketika mereka diambil secara otomatis bersama dengan komit yang mereka tuju). Anda harus menggunakan

$ git push <remote> tag <tagname>

untuk mendorong satu tag, atau

$ git push <remote> --tags

untuk mendorong semua tag (atau git push --tagsuntuk mendorong remote standar, biasanya origin).

Ini adalah perilaku yang sangat dimaksudkan, untuk membuat tag mendorong secara eksplisit. Tag pendorong biasanya merupakan pilihan sadar.


Meringkas apa yang ditulis Junio ​​C. Hamano (ditautkan dalam komentar oleh @Andre Miras)

Saat mengambil, Anda berinteraksi dengan repositori jarak jauh yang telah diterbitkan seseorang, yang berarti:

  1. set tag yang ada di sana adalah semua penerbit ingin orang melihat, dan
  2. tidak hanya Anda tetapi orang lain juga akan melihat tag yang sama.

Dengan kata lain, tag dalam repositori yang Anda ambil dirancang untuk publik dan dibagikan. Ini akan memfasilitasi komunikasi antar pengembang jika mudah bagi semua orang untuk mengambil tag yang sama ini.

Itulah sebabnya git fetchtag "mengikuti" secara otomatis, yaitu mengunduh tag saat mengunduh revisi yang mereka tunjukkan - dengan kata lain mengunduh semua tag yang diterbitkan yang relevan .

Saat mendorong, Anda mendorong dari repositori kerja Anda, yang sebagian besar waktu tidak publik, dan tag di repositori itu tidak dirancang untuk publik. Anda dapat menggunakan tag lokal Anda sendiri untuk menandai kemajuan Anda, jadi tidak masuk akal untuk mendorong secara membabi buta semua tag dalam repositori ke repositori yang Anda dorong untuk mempublikasikan perubahan Anda, yang tag-nya adalah definisi publik.

Itu sebabnya Anda perlu mendorong tag secara eksplisit, untuk menandai tag sebagai publik.


Atau Anda dapat mengkonfigurasi jarak jauh yang Anda dorong untuk selalu mendorong semua tag, mis. Letakkan sesuatu seperti itu di .git/config:

[remote "publish"] # atau apa pun namanya
    url = ...
    push = + referensi / kepala / *: referensi / kepala / *
    push = + ref / tag / *: ref / tag / *

Ini berarti paksa dorong semua kepala (semua cabang) dan semua tag (jika Anda tidak ingin memaksa mendorong kepala, hapus awalan '+' dari refspec).


Bukankah ini selalu melakukan 'push push' dari semua kepala?
Stefan Näwe

@Stefan: Ya, benar. Diperbarui.
Jakub Narębski

19
"Ini adalah perilaku yang sangat dimaksudkan, untuk membuat tag mendorong secara eksplisit. Tag dorongan biasanya menjadi pilihan sadar." Saya tidak mengerti alasannya. Bisakah Anda menguraikan mengapa itu akan buruk bagi Git untuk mendorong tag secara otomatis?
Ryan Lundy

13
@Kyralessa, dalam posting ini git.661346.n2.nabble.com/... , Junio ​​C Hamano (pemelihara Git saat ini) menjelaskan mengapa itu hal yang buruk untuk secara otomatis mendorong tag.
Andre Miras

@AndreMiras Terima kasih atas tautan yang luar biasa ini. Alangkah baiknya jika kita bisa mengintegrasikan postingan Junio ​​ke dalam jawaban ini.
Homer6

67

Perhatikan bahwa sejak git 1.8.3 (22 April, 2013) , Anda tidak lagi harus melakukan 2 perintah untuk mendorong cabang, dan kemudian untuk mendorong tag:

--follow-tagsOpsi " " baru memberi tahu " git push" untuk mendorong tag beranotasi yang relevan saat mendorong cabang keluar .

Anda sekarang dapat mencoba, ketika mendorong komit baru:

git push --follow-tags

Itu tidak akan mendorong semua tag lokal, hanya yang beranotasi yang dirujuk oleh komit yang didorong dengan git push.


Ini telah diperkenalkan di commit c2aba15 oleh Junio ​​C Hamano ( gitster) :

Opsi baru " --follow-tags" memberi tahu " git push" untuk mendorong tag beranotasi yang hilang dari sisi lain dan yang dapat dijangkau oleh riwayat yang sebaliknya didorong keluar.

Misalnya, jika Anda menggunakan dorongan " simple", " current", atau " upstream", biasanya Anda akan mendorong riwayat yang mengarah ke komit pada saat ini HEADdan tidak ada yang lain.
Dengan opsi ini, Anda juga akan mendorong semua tag beranotasi yang dapat dijangkau dari komit ke sisi lain.


Konfigurasi push.followTagsmemungkinkan untuk menyertakan --follow-tagssecara default (Git 2.4.1+, Q2 2015). Lihat " Tag & komitmen push git secara bersamaan "


3
Ini hanya mendorong semua tag beranotasi . Kebanyakan orang / proyek menggunakan tag ringan . Jadi dalam kebanyakan kasus git push --follow-tagstidak mendorong lebih darigit push
Jarl

3
@ James ya, saya telah menyebutkan "beranotasi" dalam jawaban saya. Tapi saya benar-benar hanya menggunakan tag beranotasi, menyimpan tag ringan untuk penggunaan internal murni (yaitu tidak pernah dimaksudkan untuk didorong lagi).
VonC

@VonC: Sekarang ada juga opsi konfigurasi yang menjadikan ini default, seperti yang Anda catat di sini: stackoverflow.com/a/3745250/946850
krlmlr

19

Apa yang biasanya saya lakukan adalah:

[remote "publish"] # atau apa pun namanya
    url = ...
    push =:
    push = + ref / tag / *: ref / tag / *

Artinya mendorong setiap cabang yang sudah ada, ditambah tag. Itu tidak memaksa push, dan itu tidak mendorong cabang bahwa Anda tidak mendorong secara manual.


Bisakah saya juga menempatkan itu di konfigurasi global git pengguna saya? Jika ya, bagaimana? Terima kasih! :)
gucki

Sepertinya Anda memaksakan tag, tetapi bukan cabang.
Adrian Ratnapala

Ya, dan tidak, saya menulis itu, itu akan mendorong tag baru, itu tidak akan memaksa mendorong mereka, dan itu tidak akan mendorong cabang yang belum Anda dorong sendiri.
mat

Saya mencoba saran Jakub, tetapi mendorong cabang yang hanya saya inginkan secara lokal. Saran ini, mat, berfungsi sempurna. Ini menyinkronkan tag tetapi tidak menyinkronkan cabang kecuali mereka adalah cabang pelacakan jarak jauh (yaitu tidak akan mendorong cabang baru ke jarak jauh, tetapi akan memperbaruinya jika mereka sudah ada di jarak jauh). CATATAN: jika Anda memiliki tag dan cabang dengan nama yang sama Anda mendapatkan kesalahan "cocok lebih dari satu". Rujuk ke lostechies.com/jasonmeridth/2010/02/27/refspec-matches-more-than-one/ .
josephdpurcell

5

Dan jika Anda ingin mengambil paksa semua tag, Anda dapat mengaturnya di konfigurasi dengan:

git config remote.origin.tagopt --tags

Dari dokumen:

Mengatur nilai ini ke --no-tag menonaktifkan penandaan otomatis berikut saat mengambil dari jarak jauh. Mengaturnya ke --tags akan mengambil setiap tag dari jarak jauh, bahkan jika tag tersebut tidak dapat dijangkau dari kepala cabang jarak jauh. Mengirimkan flag-flag ini secara langsung ke git-fetch (1) dapat mengesampingkan pengaturan ini. Lihat opsi --tags dan --no-tag git-fetch (1).


1
Pertanyaannya lebih berorientasi pada 'push', apakah jawaban Anda juga berlaku saat mendorong ke remote?
a1an
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.