Menemukan ekstensi git vendor .

Posting silang dari blog medium saya: https://medium.com/opsops/git-vendor-295db4bcec3a

Saya ingin memperkenalkan cara yang tepat untuk menangani pembatalan repositori git.

Apa itu 'membatalkan'?

Vendor adalah cara untuk mengintegrasikan pekerjaan orang lain ke dalam pekerjaan Anda. Ini kebalikan dari 'menghubungkan' dengan perpustakaan pihak ketiga. Alih-alih menjadikan pustaka itu sebagai dependensi, aplikasi menggunakan pustaka ini sebagai bagian dari kode sumber sendiri dan menyimpan kode itu 'di dalam' itu sendiri.

Biasanya, pembatalan dilakukan dengan perangkat bahasa: bundler, kargo, pip, dll. Tetapi kadang-kadang Anda perlu vendor sesuatu yang tidak tercakup oleh perangkat yang ada, atau sesuatu multi-bahasa, bahwa tidak mungkin untuk menemukan alat bahasa 'inti' untuk itu.

Solusi untuk situasi ini adalah membatalkan pada tingkat git. Anda memiliki repositori git Anda sendiri (saya menyebutnya ' repo tujuan '), dan Anda ingin memasukkan beberapa repositori lain (saya menyebutnya ' repo sumber ') sebagai direktori ke dalam (repo tujuan) Anda.

Hal-hal yang Anda harapkan dari sistem pembatalan yang dirancang dengan baik (terlepas dari Git atau tidaknya):

• Visibilitas Anda ingin tahu bahwa beberapa kode dibatalkan, artinya tidak ditulis oleh committer.
• Terbukti Anda ingin tahu dari mana asalnya. Apa repositori yang diintegrasikan seseorang ke repo Anda dua tahun lalu? Dan apa versi / commit itu?
• Pembaruan Anda ingin dapat memperbarui kode itu ketika bug diperbaiki di repo asli (atau memiliki fitur lama menunggu). Sebagai kasus khusus untuk pembaruan, Anda ingin dapat menghapus kode yang dibatalkan (dan hanya itu).
• Pengulangan Vendor tidak harus menjadi seni, itu harus menjadi proses pembuktian kesalahan yang kaku. vendor foo menjadi bilah harus menghasilkan hasil yang sama tidak peduli siapa yang melakukannya.
• Transportabilitas. Seseorang yang mengkloning repositori Anda harus dapat terus berurusan dengan pembatalan dengan cara yang persis sama seperti yang Anda lakukan. Itu berarti semua informasi yang terkait dengan pembatalan harus tetap di git dan harus ditransfer selama push / pull.
• Pemerintahan. Semua perubahan yang dibatalkan harus tetap 'sebagaimana adanya' sampai seseorang memperbaruinya. Anda tidak ingin memiliki pembaruan (pemecahan) yang tidak terduga, terlebih lagi, Anda benar-benar ingin menyimpan hal-hal yang dibatalkan bahkan sumber repo tidak lagi tersedia.
• Patchability. Anda ingin dapat mengubah kode yang dibatalkan dan masih dapat memperbaruinya ke versi yang lebih baru. Lebih disukai, tanpa konflik, tetapi setidaknya, dengan visibilitas yang jelas di mana konflik itu terjadi.

Dan, memberikan sifat git dari Git, Anda ingin sistem itu ramah cabang. Jika cabang A memiliki kode yang dibatalkan pada versi a1, dan cabang B di versi b1, Anda ingin beralih di antara mereka setiap kali Anda beralih antara A dan B. Selain itu, Anda ingin dapat mengubah versi a1 ke a2, dan versi b1 ke b2 tanpa khawatir tentang versi di cabang lain.

... Dan Anda ingin dapat vendor lebih dari satu repositori eksternal, jadi membatalkan tidak boleh hanya satu kali peristiwa per repo.

Seperti yang Anda lihat itu adalah daftar panjang persyaratan. Saya menganalisis solusi yang ada (lainnya) sebelum sampai ke solusi terbaik (vendor git).

Salin tempel

Copy-paste adalah cara yang sangat kejam untuk vendor apa pun yang tidak ada yang baik saya katakan tentang hal itu. Anda kehilangan sumber, visibilitas, kemampuan pembaruan. Anda tidak kehilangan transportabilitas, karena tidak ada tautan ke repo lama di tempat pertama. Jangan melakukan pembatalan seperti itu.

Git-in-git

Ini adalah trik yang bodoh tapi agak berhasil. Buat folder vendored_foobar ke dalam repositori Anda, masuk ke vendored_foobar dan clone foobar itu. Kembali ke tingkat atas dan komit semua perubahan yang Anda miliki.

Kelebihan: mudah dilakukan, menyediakan sumber daya lokal, tata kelola, dan kenyamanan yang luar biasa.

Cons: Ini rapuh, tidak tahan push (folder .git bersarang tidak termasuk ke dalam repo Anda, jadi untuk pengamat eksternal kode yang dibatalkan tidak dapat dibedakan dari milik Anda). Jadi, Anda akan kehilangan daya angkut, dan bukti dalam jangka panjang.

Submodules

Idenya adalah Anda memiliki beberapa folder git yang Anda kelola di git lain. Itu adalah 'sesuatu' tertua yang disediakan git. Sayangnya, ini tidak ramah cabang, dan tidak memiliki tata kelola atas kode yang dibatalkan. Jika repo jarak jauh hilang, Anda tidak dapat menggunakan submodul Anda.

Dan jangan lupa betapa sulitnya mengkloning repo ini.

git subtree

Git dapat menggunakan cara 'subtree' untuk menggabungkan git eksternal sebagai folder ke dalam repositori git lokal. Ini hampir sempurna, kecuali untuk pembaruan, pengulangan, dan asal, dan visibilitas. Kecuali manual yang menggali sejarah git, tidak mungkin untuk melihat bagian mana dari repo git yang dibatalkan dan mana yang tidak. Dan Anda tidak tahu dari mana perubahan itu berasal. Jika committer belum menulis ini, informasi hilang. Dan jika ada, itu tidak dapat diulang karena perubahan kecil dapat terjadi selama mengisi informasi itu.

Jadi, masukkan pemenang yang berharga, vendor git.

Vendor git

Vendor Git adalah ekstensi luar biasa untuk git yang ditulis oleh Brett Langdon sekitar tiga tahun lalu. Ini hanya sekitar 200 baris dalam bash, tetapi ditulis dengan sangat baik sehingga saya tidak mengeluh sama sekali (memiliki semua yang harus dimiliki oleh program yang baik: halaman manual, bantuan, penyelesaian bash, penanganan kesalahan yang wajar, dan penjaga yang gagal).

Ia menggunakan git subtree dan memperluasnya dengan fungsi untuk menutupi sisi longgar dari pembatalan dengan git subtree.

Setiap poin penting diperiksa:

• visilibitas. Panggil saja git vendor list dan lihat semua hal yang dibatalkan.
• asalnya. Ini menunjukkan repo jarak jauh dan memungkinkan untuk melihat komit apa yang dibatalkan.
• pembaruan. git vendor update , dan mendukung cabang, tag, dan melakukan sebagai cara pin-point apa yang harus diambil. Dan Anda dapat melakukan git vendor remove , tentu saja.
• pengulangan. Tidak ada operasi manual yang terlibat, sehingga semua orang akan mendapatkan hasil yang sama pada pembatalan awal atau mengikuti pembaruan.
• transportabilitas. Semua perubahan disimpan sebagai tag khusus dalam sejarah git, sehingga mereka sepenuhnya push / pull-friendly. Dan mereka bekerja sangat baik dengan cabang dan pemeriksaan sejarah yang sewenang-wenang.
• perjanjian Semua kode yang dibatalkan disimpan di dalam repo Anda.
• tambalan Yaitu (Anda akan melihat konflik gabungan yang jelas dengan perubahan Anda), tetapi itu adalah sisi terlemah dari vendor git. Saya lebih suka memiliki 'patch queue' (seperti di debian / path untuk paket deb), namun demikian, ada dukungan minimal untuk itu.

Ini memiliki kebijakan khusus tentang bagaimana hal-hal dibatalkan: jika Anda ingin mengkloning https://github.com/serverscom/dibctl masuk ke vendor/github.com/serverscom/dibctl/ . Anda dapat mengubah bagian ' vendor/ ', tetapi sisanya merupakan kebijakan yang sulit. Symlinks bisa mempermudah itu.

Ada beberapa bug kecil di sana: Anda tidak dapat menggunakannya pada repo kosong, Anda tidak dapat menggunakan git lokal sebagai sumber, Anda tidak dapat melihat bantuan sampai Anda berada di git repo. Tak satu pun dari mereka menyebabkan masalah selama pekerjaan normal dengan repo nyata.

Kesimpulan

git-vendor adalah alat yang sempurna untuk vendor satu git repo ke yang lain. Ini menyediakan semua fungsionalitas yang diperlukan untuk praktik terbaik pembatalan: menjaga sumber asli, memberikan visibilitas dan pembaruan.