Untuk apa saya menggunakan git-worktree?

Saya membaca posting Github di git-worktree . Mereka menulis:

Misalkan Anda bekerja di repositori Git pada cabang yang dipanggil feature, ketika pengguna melaporkan bug dengan urgensi tinggi master. Pertama Anda membuat pohon kerja tertaut dengan cabang baru hotfix,, diperiksa relatif terhadap master [...] Anda dapat memperbaiki bug, mendorong perbaikan terbaru, dan membuat permintaan tarik.

Ketika saya sedang mengerjakan fitur cabang yang disebut dan beberapa bug dengan tingkat urgensi tinggi dilaporkan, saya biasanya menyembunyikan apa pun yang sedang saya kerjakan dan membuat cabang baru. Setelah selesai, saya bisa terus bekerja. Ini adalah model yang sangat sederhana, saya telah bekerja seperti itu selama bertahun-tahun.

Di sisi lain, menggunakan git-worktree memiliki keterbatasannya sendiri:

Misalnya, cabang yang sama tidak boleh diperiksa di dua pohon yang terhubung secara bersamaan, karena itu akan memungkinkan perubahan yang dilakukan dalam satu pohon yang bekerja untuk membawa yang lainnya tidak sinkron.

Mengapa saya memilih alur kerja yang lebih rumit untuk masalah yang sudah diselesaikan?

Adakah sesuatu tentang git-worktreehal itu yang tidak dapat dilakukan sebelumnya dan yang membenarkan fitur baru yang kompleks ini?

Bagi saya, git worktree adalah peningkatan terbesar sejak lama. Saya bekerja dalam pengembangan perangkat lunak perusahaan. Di sana, sangat umum bahwa Anda harus mempertahankan versi lama seperti yang Anda rilis 3 tahun lalu. Tentu saja Anda memiliki cabang untuk setiap versi sehingga Anda dapat dengan mudah beralih ke sana dan memperbaiki bug. Namun, beralih itu mahal, karena sementara itu Anda sepenuhnya merestrukturisasi repositori dan mungkin membangun sistem. Jika Anda beralih, IDE Anda akan menjadi gila mencoba menyesuaikan pengaturan proyek.

Dengan worktree, Anda dapat menghindari konfigurasi ulang yang konstan itu. Periksa cabang-cabang tua itu di folder terpisah menggunakan worktree. Untuk setiap cabang, Anda mendapat proyek IDE independen.

Tentu saja ini bisa dilakukan di masa lalu dengan mengkloning repo beberapa kali dan ini adalah pendekatan saya sejauh ini. Namun, itu juga berarti membuang-buang ruang hardrive dan lebih buruk perlu mengambil perubahan yang sama dari repo beberapa kali.

Saya dapat melihat beberapa kegunaan untuk ini.

Jika Anda memiliki rangkaian uji yang berjalan untuk waktu yang lama, bayangkan berjam-jam, dan Anda memulainya secara efektif memblokir copy pekerjaan sampai tes selesai. Berpindah cabang selama tes-tes itu akan mematahkannya dengan cara yang sulit dimengerti.

Maka dengan itu git-worktreesaya dapat memiliki ide kedua diluncurkan untuk cabang lain melakukan pekerjaan di sana.

Juga, ketika saya beralih ke beberapa cabang lain untuk melakukan penyelidikan cepat, IDE saya berpikir banyak file tiba-tiba berubah dan akan mengindeks semua perubahan itu, hanya harus mengindeks ulang mereka ketika saya beralih kembali.

Kasus penggunaan ketiga adalah melakukan perbandingan file menggunakan alat lain selain git-diff, seperti biasa diff, antara dua direktori, bukan jika dua cabang.

Satu penggunaan yang jelas adalah untuk secara bersamaan membandingkan perilaku (bukan sumber) versi yang berbeda - misalnya versi yang berbeda dari situs web atau hanya halaman web.

Saya mencoba ini secara lokal.

• buat direktori page1.

• di dalam buat direktori srcdan git inititu.

• di srcbuat page1.htmldengan sedikit konten dan komit.

• $ git branch ver0

• $ git worktree add ../V0 ver0

• di srcmaster tambahkan lebih banyak teks ke page1.htmldan komit.

• $ git branch sty1

• edit page1.htmldi sty1cabang (tambahkan beberapa gaya CSS khas) dan tambahkan komit.

• $ git worktree add ../S1 sty1

Anda sekarang dapat menggunakan browser web untuk membuka dan melihat 3 versi ini secara bersamaan:

• ..\page1\src\page1.html // apa pun yang dimiliki git sebagai arus

• ..\page1\V0\page1.html // versi awal

• ..\page1\S1\page1.html // versi gaya percobaan

1. Ada alasan sah mengapa Anda ingin / membutuhkan banyak worktrees di sistem file sekaligus.

   • memanipulasi file yang diperiksa sementara perlu membuat perubahan di tempat lain (mis. kompilasi / pengujian)

   • diffing file melalui alat diff normal

   • selama menggabungkan konflik, saya sering ingin menavigasi melalui kode sumber karena ada di sisi sumber saat menyelesaikan konflik dalam file.

   • Jika Anda harus sering bolak-balik, ada waktu yang terbuang untuk keluar dan memeriksa ulang yang tidak perlu Anda lakukan dengan beberapa worktrees.

   • biaya mental dari perubahan konteks mental antar cabang melalui penyimpanan git tidak benar-benar dapat diukur. Beberapa orang menemukan bahwa ada biaya mental untuk menyimpan yang tidak ada di sana hanya dengan membuka file dari direktori yang berbeda.

2. Beberapa orang bertanya "mengapa tidak melakukan banyak klon lokal". Memang benar bahwa dengan flag "--local" Anda tidak perlu khawatir tentang penggunaan ruang disk tambahan. Ini (atau gagasan serupa) adalah apa yang telah saya lakukan hingga saat ini. Keuntungan fungsional untuk tabel kerja terkait dari klon lokal adalah:

   1. Dengan klon lokal, meja kerja tambahan Anda (yang berada di klon lokal) tidak memiliki akses ke cabang asal atau hulu. 'Asal' di klon tidak akan sama dengan 'asal' di klon pertama.

      • Berlari git log @{u}..atau git diff origin/feature/other-featurebisa sangat membantu dan ini tidak mungkin lagi atau lebih sulit. Ide-ide ini secara teknis dimungkinkan dengan klon lokal melalui bermacam-macam workarouns, tetapi setiap solusi yang dapat Anda lakukan dilakukan lebih baik dan / atau lebih sederhana melalui worktrees terkait.

   2. Anda dapat membagikan referensi di antara meja kerja. Jika Anda ingin membandingkan atau meminjam perubahan dari cabang lokal lain, sekarang Anda bisa.

tl; dr: Kapan pun Anda ingin memeriksa dua pohon kerja pada saat yang sama karena alasan apa pun, git-worktreeadalah cara yang cepat dan hemat ruang untuk melakukannya.

Jika Anda membuat lembar kerja lain, sebagian besar repo (yaitu .git) akan dibagikan, artinya jika Anda membuat cabang atau mengambil data saat Anda berada di satu pohon kerja, itu juga akan dapat diakses dari pohon kerja lain yang Anda miliki. Katakanlah Anda ingin menjalankan test suite Anda di branch foo tanpa harus mendorongnya ke suatu tempat untuk mengkloningnya, dan Anda ingin menghindari kerumitan mengkloning repo Anda secara lokal, menggunakan git-worktreeadalah cara yang bagus untuk membuat checkout baru dari beberapa keadaan dalam suatu tempat terpisah, baik sementara atau permanen. Sama seperti dengan klon, yang perlu Anda lakukan setelah selesai adalah menghapusnya, dan referensi untuk itu akan menjadi sampah yang dikumpulkan setelah beberapa waktu.

Saya awalnya tersandung pada pertanyaan ini setelah bertanya-tanya untuk apa meja kerja mewah ini dapat digunakan. Sejak itu saya telah mengintegrasikan mereka ke dalam alur kerja saya dan terlepas dari skeptisisme awal saya, saya datang untuk menemukan mereka cukup berguna.

Saya bekerja pada basis kode yang agak besar, yang membutuhkan waktu cukup lama untuk dikompilasi. Saya biasanya memiliki cabang pengembangan saat ini di mesin saya bersama dengan cabang fitur yang saat ini saya kerjakan ditambah cabang utama, yang mewakili keadaan saat ini dari sistem live.

Salah satu manfaat terbesar bagi saya adalah jelas bahwa saya tidak perlu mengkompilasi ulang seluruh hal setiap kali saya beralih cabang (yaitu, worktrees). Efek samping yang bagus adalah saya bisa pergi ke worktree pengembangan, melakukan hal-hal di sana, mengubah direktori ke worktree untuk cabang fitur saya saat ini dan kemudian rebase tanpa harus menarik terlebih dahulu.

Saya punya yang agak tidak biasa: Saya melakukan pengembangan Windows dan Linux pada mesin yang sama . Saya memiliki VirtualBox yang menjalankan Linux di dalam kotak Windows saya. VirtualBox memasang beberapa direktori Windows dan menggunakannya langsung di dalam mesin Linux. Ini memungkinkan saya menggunakan Windows untuk mengelola file tetapi membangun di Linux. Ini adalah proyek lintas-platform, jadi ini dibangun di atas Windows dan Linux dari struktur direktori yang sama.

Masalahnya adalah bahwa sistem pembangunan Linux dan Windows saling menabrak ketika digunakan dalam direktori yang sama; ada beberapa langkah membangun yang rumit untuk mengunduh pustaka, dll., yang menggunakan nama direktori yang sama. Versi Windows dari sistem build mengunduh perpustakaan khusus Windows, dan versi Linux dari sistem build mengunduh perpustakaan khusus Linux.

Di dunia yang ideal, sistem build akan dimodifikasi sehingga Windows & Linux dapat hidup berdampingan dalam direktori, tetapi untuk saat ini, masalahnya sedang ditangani dengan worktrees. Folder "Linux" dapat menghasilkan artefak build khusus Linux, dan folder "Windows" dapat menghasilkan artefak build spesifik Windows. Meskipun ini bukan solusi yang ideal, itu membuat sementara waktu yang bagus sambil menunggu bug sistem build ditangani.

Harus diakui, meja kerja tidak dirancang untuk ini; Saya harus menyimpan versi Windows dan versi Linux di cabang terpisah, walaupun saya lebih suka mereka berada di cabang yang sama. Tetap saja, ia melakukan pekerjaannya, dan merupakan kasus kerja yang agak tidak konvensional, menghemat hari.

Dalam proyek baru untuk saya, saya telah membuat fitur. Tetapi beberapa spesifikasi gagal. Untuk membandingkan hasil dengan mastersaya membuat work-treerepo. Saya membandingkan hasil langkah demi langkah dalam menjalankan kode, sampai mengerti apa yang salah.

Saya menggunakan git worktreeuntuk pengembangan pembelajaran mesin.

Saya memiliki kode fungsional utama dan kemudian saya ingin membagi cabang percobaan yang berbeda (algoritma berbeda dan hyperparameter berbeda). git worktreememungkinkan saya untuk mengintegrasikan dvc bersama berbagai versi kode saya yang dikhususkan untuk algoritma yang berbeda. Setelah menjalankan semua pekerjaan pelatihan, saya mengevaluasi metrik akhir dan bergabung untuk menguasai cabang / model terbaik.