Apa yang dimaksud dengan "cabang", "tag" dan "trunk" dalam repositori Subversion?

Saya sering melihat kata-kata ini di sekitar diskusi Subversion (dan saya kira repositori umum).
Saya telah menggunakan SVN untuk proyek saya selama beberapa tahun terakhir, tetapi saya tidak pernah memahami konsep lengkap direktori ini.

Apa yang mereka maksud?

Hmm, tidak yakin saya setuju dengan tag Nick re yang mirip dengan cabang. Tag hanyalah penanda

• Batang akan menjadi badan utama pengembangan, yang dimulai dari awal proyek hingga saat ini.

• Cabang akan menjadi salinan kode yang berasal dari titik tertentu di bagasi yang digunakan untuk menerapkan perubahan besar pada kode sambil menjaga integritas kode di bagasi. Jika perubahan besar bekerja sesuai rencana, mereka biasanya digabungkan kembali ke bagasi.

• Tag akan menjadi titik waktu pada bagasi atau cabang yang ingin Anda pertahankan. Dua alasan utama untuk pelestarian adalah apakah ini merupakan rilis utama dari perangkat lunak, apakah alpha, beta, RC atau RTM, atau ini adalah titik paling stabil dari perangkat lunak sebelum revisi utama pada trunk diterapkan.

Dalam proyek-proyek sumber terbuka, cabang-cabang utama yang tidak diterima ke dalam bagasi oleh para pemangku kepentingan proyek dapat menjadi basis untuk percabangan - misalnya, proyek-proyek yang benar-benar terpisah yang berbagi sumber yang sama dengan kode sumber lainnya.

Sub cabang dan tag dibedakan dari trunk dengan cara berikut:

Subversi memungkinkan sysadmin untuk membuat skrip kait yang dipicu untuk dieksekusi ketika peristiwa tertentu terjadi; misalnya, melakukan perubahan pada repositori. Sangat umum untuk implementasi repositori Subversion yang khas untuk memperlakukan setiap jalur yang mengandung "/ tag /" untuk dilindungi dari penulisan setelah pembuatan; hasil akhirnya adalah bahwa tag, setelah dibuat, tidak dapat diubah (setidaknya untuk pengguna "biasa"). Ini dilakukan melalui skrip kait, yang menegakkan immutabilitas dengan mencegah perubahan lebih lanjut jika tag adalah simpul induk dari objek yang diubah.

Subversion juga telah menambahkan fitur, sejak versi 1.5, yang berkaitan dengan "pelacakan gabungan cabang" sehingga perubahan yang dilakukan pada cabang dapat digabungkan kembali ke bagasi dengan dukungan untuk penggabungan "pintar" tambahan.

Pertama-tama, seperti yang ditunjukkan oleh @AndrewFinnell dan @KenLiu, dalam SVN nama direktori itu sendiri tidak ada artinya - "trunk, branch and tag" hanyalah sebuah konvensi umum yang digunakan oleh kebanyakan repositori. Tidak semua proyek menggunakan semua direktori (itu cukup umum untuk tidak menggunakan "tag" sama sekali), dan pada kenyataannya, tidak ada yang menghentikan Anda dari memanggil mereka apa pun yang Anda suka, meskipun melanggar konvensi sering membingungkan.

Saya akan menjelaskan kemungkinan skenario penggunaan cabang dan tag yang paling umum, dan memberikan contoh skenario bagaimana mereka digunakan.

• Batang : Area pengembangan utama. Di sinilah rilis utama Anda berikutnya dari kode hidup, dan umumnya memiliki semua fitur terbaru.

• Cabang : Setiap kali Anda merilis versi utama, itu membuat cabang dibuat. Ini memungkinkan Anda untuk melakukan perbaikan bug dan membuat rilis baru tanpa harus merilis fitur terbaru - mungkin belum selesai atau belum teruji.

• Tag : Setiap kali Anda merilis versi (rilis final, rilis kandidat (RC), dan beta) Anda membuat tag untuk itu. Ini memberi Anda salinan kode waktu seperti saat berada pada keadaan itu, memungkinkan Anda untuk kembali dan mereproduksi bug apa pun jika perlu dalam versi masa lalu, atau merilis kembali versi masa lalu persis seperti sebelumnya. Cabang dan tag di SVN ringan - di server, itu tidak membuat salinan lengkap dari file, hanya penanda yang mengatakan "file-file ini disalin pada revisi ini" yang hanya memakan beberapa byte. Dengan mengingat hal ini, Anda tidak perlu khawatir tentang membuat tag untuk kode apa pun yang dirilis. Seperti yang saya katakan sebelumnya, tag sering dihilangkan dan sebagai gantinya, changelog atau dokumen lain mengklarifikasi nomor revisi ketika rilis dibuat.

Misalnya, katakanlah Anda memulai proyek baru. Anda mulai bekerja di "trunk", pada apa yang akhirnya akan dirilis sebagai versi 1.0.

• trunk / - versi pengembangan, segera menjadi 1,0
• cabang / - kosong

Setelah 1.0.0 selesai, Anda cabang trunk ke cabang "1.0" baru, dan membuat tag "1.0.0". Sekarang kerjakan apa yang nantinya akan menjadi 1,1 berlanjut di bagasi.

• trunk / - versi pengembangan, segera menjadi 1,1
• branch / 1.0 - 1.0.0 versi rilis
• tags / 1.0.0 - 1.0.0 versi rilis

Anda menemukan beberapa bug dalam kode, dan memperbaikinya di bagasi, dan kemudian menggabungkan perbaikan ke cabang 1.0. Anda juga dapat melakukan yang sebaliknya, dan memperbaiki bug di cabang 1.0 dan kemudian menggabungkannya kembali ke trunk, tetapi biasanya proyek tetap dengan penggabungan satu arah hanya untuk mengurangi kemungkinan kehilangan sesuatu. Terkadang bug hanya dapat diperbaiki di 1.0 karena usang di 1.1. Tidak masalah: Anda hanya ingin memastikan bahwa Anda tidak merilis 1.1 dengan bug yang sama yang telah diperbaiki di 1.0.

• trunk / - versi pengembangan, segera menjadi 1,1
• branch / 1.0 - rilis 1.0.1 mendatang
• tags / 1.0.0 - 1.0.0 versi rilis

Setelah Anda menemukan cukup banyak bug (atau mungkin satu bug kritis), Anda memutuskan untuk melakukan rilis 1.0.1. Jadi, Anda membuat tag "1.0.1" dari cabang 1.0, dan lepaskan kodenya. Pada titik ini, trunk akan berisi apa yang akan menjadi 1.1, dan cabang "1.0" berisi kode 1.0.1. Lain kali Anda merilis pembaruan ke 1.0, itu akan menjadi 1.0.2.

• trunk / - versi pengembangan, segera menjadi 1,1
• branch / 1.0 - rilis 1.0.2 mendatang
• tags / 1.0.0 - 1.0.0 versi rilis
• tags / 1.0.1 - 1.0.1 versi rilis

Akhirnya Anda hampir siap untuk merilis 1.1, tetapi Anda ingin melakukan beta terlebih dahulu. Dalam hal ini, Anda kemungkinan melakukan cabang "1.1", dan tag "1.1beta1". Sekarang, kerjakan apa yang akan menjadi 1.2 (atau 2.0 mungkin) berlanjut di trunk, tetapi bekerja di 1.1 berlanjut di cabang "1.1".

• trunk / - versi pengembangan, segera menjadi 1,2
• branch / 1.0 - rilis 1.0.2 mendatang
• branch / 1.1 - rilis 1.1.0 mendatang
• tags / 1.0.0 - 1.0.0 versi rilis
• tags / 1.0.1 - 1.0.1 versi rilis
• tags / 1.1beta1 - 1.1 versi rilis beta 1

Setelah Anda merilis 1.1 final, Anda melakukan tag "1.1" dari cabang "1.1".

Anda juga dapat terus mempertahankan 1.0 jika Anda mau, porting perbaikan bug di antara ketiga cabang (1.0, 1.1, dan trunk). Yang penting adalah untuk setiap versi utama dari perangkat lunak yang Anda pertahankan, Anda memiliki cabang yang berisi versi kode terbaru untuk versi itu.

Penggunaan cabang lainnya adalah untuk fitur. Di sinilah Anda bercabang batang (atau salah satu cabang rilis Anda) dan bekerja pada fitur baru secara terpisah. Setelah fitur selesai, Anda menggabungkannya kembali dan menghapus cabang.

• trunk / - versi pengembangan, segera menjadi 1,2
• branch / 1.1 - rilis 1.1.0 mendatang
• branch / ui-rewrite - cabang fitur eksperimental

Gagasannya adalah ketika Anda mengerjakan sesuatu yang mengganggu (yang akan menahan atau mengganggu orang lain untuk melakukan pekerjaan mereka), sesuatu yang eksperimental (yang mungkin bahkan tidak berhasil), atau mungkin hanya sesuatu yang membutuhkan waktu lama. (dan Anda takut jika menahan rilis 1.2 ketika Anda siap untuk mengambil 1.2 dari trunk), Anda dapat melakukannya secara terpisah di cabang. Secara umum, Anda selalu memperbaruinya dengan trunk dengan menggabungkan perubahan ke dalamnya setiap saat, yang membuatnya lebih mudah untuk diintegrasikan kembali (digabung kembali ke trunk) ketika Anda selesai.

Perhatikan juga, skema versi yang saya gunakan di sini hanyalah satu dari banyak. Beberapa tim akan melakukan rilis perbaikan / pemeliharaan bug sebagai 1.1, 1.2, dll., Dan perubahan besar sebagai 1.x, 2.x, dll. Penggunaan di sini adalah sama, tetapi Anda dapat menamai cabang "1" atau "1 .x "bukannya" 1.0 "atau" 1.0.x ". (Selain itu, versi semantik adalah panduan yang baik tentang cara melakukan nomor versi).

Selain apa yang dikatakan Nick, Anda bisa mengetahui lebih lanjut di Streamed Lines: Branching Patterns for Parallel Software Development

Dalam gambar ini mainadalah trunk, rel1-maintcabang dan 1.0tag.

Secara umum (tampilan alat agnostik), cabang adalah mekanisme yang digunakan untuk pengembangan paralel. SCM dapat memiliki dari 0 hingga n cabang. Subversi memiliki 0.

• Bagasi adalah cabang utama yang direkomendasikan oleh Subversion , tetapi Anda sama sekali tidak dipaksa untuk membuatnya. Anda bisa menyebutnya 'utama' atau 'rilis', atau tidak memilikinya sama sekali!

• Cabang merupakan upaya pengembangan. Itu tidak boleh dinamai sumber daya (seperti 'vonc_branch') tetapi setelah:

  • tujuan 'myProject_dev' atau 'myProject_Merge'
  • perimeter rilis 'myProjetc1.0_dev'atau myProject2.3_Merge' atau 'myProject6..2_Patch1' ...

• Menandai adalah snapshot file agar dapat dengan mudah kembali ke keadaan itu. Masalahnya adalah bahwa tag dan cabang sama di Subversion . Dan saya pasti akan merekomendasikan pendekatan paranoid:

  Anda dapat menggunakan salah satu skrip kontrol akses yang disediakan dengan Subversion untuk mencegah siapa pun melakukan apa pun selain membuat salinan baru di area tag.

Tag sudah final. Isinya tidak boleh berubah. TIDAK PERNAH. Pernah. Anda lupa garis di catatan rilis? Buat tag baru. Usang atau hapus yang lama.

Sekarang, saya membaca banyak tentang "menggabungkan kembali ini dan itu di cabang ini dan itu, kemudian akhirnya di cabang batang". Itu disebut alur kerja gabungan dan tidak ada yang wajib di sini . Bukan karena Anda memiliki cabang trunk yang Anda harus menggabungkan kembali apa pun.

Dengan konvensi, cabang trunk dapat mewakili kondisi perkembangan Anda saat ini, tetapi itu untuk proyek sekuensial sederhana, yaitu proyek yang memiliki:

• tidak ada pengembangan 'di muka' (untuk menyiapkan versi berikutnya-berikutnya menyiratkan perubahan tersebut sehingga tidak kompatibel dengan pengembangan 'trunk' saat ini)
• tidak ada refactoring besar-besaran (untuk menguji pilihan teknis baru)
• tidak ada pemeliharaan jangka panjang dari rilis sebelumnya

Karena dengan satu (atau semua) skenario itu, Anda mendapatkan sendiri empat 'batang', empat 'perkembangan saat ini', dan tidak semua yang Anda lakukan dalam pengembangan paralel tersebut harus digabungkan kembali ke 'batang'.

Dalam SVN tag dan branch sangat mirip.

Tag = irisan waktu yang ditentukan, biasanya digunakan untuk rilis

Branch = juga sebuah irisan yang telah ditentukan yang dapat melanjutkan perkembangannya, biasanya digunakan untuk versi utama seperti 1.0, 1.5, 2.0, dll, kemudian ketika Anda melepaskan Anda memberi tag pada cabang. Ini memungkinkan Anda untuk terus mendukung rilis produksi sambil bergerak maju dengan memecah perubahan di bagasi

Trunk = ruang kerja pengembangan, di sinilah semua pengembangan harus terjadi, dan kemudian perubahan digabungkan kembali dari rilis cabang.

Mereka tidak benar-benar memiliki makna formal. Folder adalah folder untuk SVN. Mereka adalah cara yang diterima secara umum untuk mengatur proyek Anda.

• Bagasi adalah tempat Anda menyimpan jalur utama pengembangan Anda. Folder cabang adalah tempat Anda dapat membuat, well, cabang, yang sulit dijelaskan dalam posting singkat.

• Cabang adalah salinan bagian dari proyek Anda yang Anda kerjakan secara terpisah dari trunk. Mungkin itu untuk eksperimen yang mungkin tidak ke mana-mana, atau mungkin untuk rilis berikutnya, yang nantinya akan Anda gabungkan kembali ke bagasi ketika menjadi stabil.

• Dan folder tag adalah untuk membuat salinan dari repositori Anda yang ditandai, biasanya pada pos pemeriksaan rilis.

Tapi seperti saya katakan, untuk SVN, folder adalah folder. branch, trunkdan tag hanyalah konvensi.

Saya menggunakan kata 'salin' secara bebas. SVN sebenarnya tidak membuat salinan lengkap dari hal-hal di repositori.

The trunk adalah baris pengembangan yang memegang kode sumber terbaru dan fitur. Seharusnya ada perbaikan bug terbaru di dalamnya serta fitur terbaru yang ditambahkan ke proyek.

The cabang biasanya digunakan untuk melakukan sesuatu dari bagasi (atau jalur pembangunan lainnya) yang lain akan mematahkan membangun. Fitur-fitur baru sering dibangun di cabang dan kemudian digabungkan kembali ke bagasi. Cabang sering kali berisi kode yang tidak harus disetujui untuk jalur pengembangan tempat cabang itu bercabang. Sebagai contoh, seorang programmer dapat mencoba optimasi pada sesuatu di cabang dan hanya bergabung kembali di jalur pengembangan setelah optimasi memuaskan.

The tag adalah snapshot dari repositori pada waktu tertentu. Tidak ada perkembangan yang terjadi pada ini. Mereka paling sering digunakan untuk mengambil salinan dari apa yang dirilis ke klien sehingga Anda dapat dengan mudah memiliki akses ke apa yang digunakan klien.

Berikut ini tautan ke panduan yang sangat bagus untuk repositori:

• Kontrol Sumber HOWTO

Artikel-artikel di Wikipedia juga layak dibaca.

Nah, itu hal tentang pengembangan perangkat lunak, tidak ada pengetahuan yang konsisten tentang apa pun, semua orang tampaknya memiliki cara mereka sendiri, tetapi itu karena itu adalah disiplin yang relatif muda.

Inilah cara sederhana saya,

trunk - Direktori trunk berisi kumpulan pekerjaan terbaru, disetujui, dan digabungkan. Bertentangan dengan apa yang telah diakui banyak orang, bagasi saya hanya untuk pekerjaan yang bersih, rapi, disetujui, dan bukan area pengembangan, melainkan area pelepasan.

Pada suatu saat ketika bagasi tampaknya siap untuk dirilis, maka ia ditandai dan dilepaskan.

cabang - Direktori cabang berisi percobaan dan pekerjaan yang sedang berlangsung. Pekerjaan di bawah cabang tetap di sana sampai disetujui untuk digabung ke dalam bagasi. Bagi saya, ini adalah area di mana semua pekerjaan dilakukan.

Sebagai contoh: Saya dapat memiliki cabang iterasi-5 untuk putaran kelima pengembangan pada produk, mungkin prototipe-9 cabang untuk putaran kesembilan bereksperimen, dan sebagainya.

tag - Direktori tag berisi snapshot dari cabang dan rilis trunk yang disetujui. Setiap kali cabang disetujui untuk bergabung ke dalam bagasi, atau rilis dibuat dari bagasi, snapshot dari cabang yang disetujui atau rilis bagasi dibuat di bawah tag.

Saya kira dengan tag saya bisa melompat-lompat sepanjang waktu untuk poin bunga cukup mudah.

Saya menemukan tutorial hebat tentang SVN ini ketika saya mencari situs web penulis dari Pemrograman Aplikasi Pemrograman Visi Komputer OpenCV 2 dan saya pikir saya harus berbagi.

Dia memiliki tutorial tentang cara menggunakan SVN dan apa arti frasa 'trunk', 'tag' dan 'branch'.

Dikutip langsung dari tutorialnya:

Versi proyek perangkat lunak Anda saat ini, tempat tim Anda sedang bekerja biasanya berada di bawah direktori yang disebut trunk . Seiring perkembangan proyek, pengembang memperbarui versi memperbaiki bug, menambahkan fitur baru) dan mengirimkan perubahannya di bawah direktori itu.

Pada suatu titik waktu tertentu, Anda mungkin ingin membekukan versi dan mengambil snapshot dari perangkat lunak seperti pada tahap pengembangan ini. Ini umumnya sesuai dengan versi resmi perangkat lunak Anda, misalnya, yang akan Anda berikan kepada klien Anda. Snapshots ini terletak di bawah direktori tag proyek Anda.

Akhirnya, seringkali berguna untuk membuat, pada titik tertentu, garis pengembangan baru untuk perangkat lunak Anda. Ini terjadi, misalnya, ketika Anda ingin menguji implementasi alternatif di mana Anda harus memodifikasi perangkat lunak Anda tetapi Anda tidak ingin mengirimkan perubahan ini ke proyek utama sampai Anda memutuskan apakah Anda mengadopsi solusi baru. Tim utama kemudian dapat terus mengerjakan proyek sementara pengembang lain mengerjakan prototipe. Anda akan meletakkan baris baru pengembangan proyek ini di bawah direktori yang disebut cabang .

Direktori trunk adalah direktori yang mungkin paling Anda kenal, karena digunakan untuk menyimpan perubahan terbaru. Basis kode utama Anda harus di bagasi.

Direktori cabang adalah untuk memegang cabang Anda, apa pun itu.

Direktori tag pada dasarnya untuk menandai satu set file tertentu. Anda melakukan ini untuk hal-hal seperti rilis, di mana Anda ingin "1.0" menjadi file-file ini di revisi ini dan "1.1" menjadi file-file ini di revisi ini. Anda biasanya tidak mengubah tag setelah dibuat. Untuk informasi lebih lanjut tentang tag, lihat Bab 4. Menanam dan Menggabungkan (dalam Kontrol Versi dengan Subversi ).

Salah satu alasan mengapa setiap orang memiliki definisi yang sedikit berbeda adalah karena Subversion menerapkan dukungan nol untuk cabang dan tag. Subversion pada dasarnya mengatakan: Kami melihat cabang dan tag berfitur lengkap di sistem lain dan tidak menemukannya berguna, jadi kami tidak mengimplementasikan apa pun. Cukup buat salinan ke direktori baru dengan konvensi nama saja . Maka tentu saja setiap orang bebas untuk memiliki konvensi yang sedikit berbeda. Untuk memahami perbedaan antara yang nyata tag dan salinan + konvensi penamaan belaka melihat entri Wikipedia Subversion tag & cabang .

Tag = irisan waktu yang ditentukan, biasanya digunakan untuk rilis

Saya pikir inilah yang biasanya dimaksud dengan "tag". Tetapi dalam Subversi:

Mereka tidak benar-benar memiliki makna formal. Folder adalah folder untuk SVN.

yang menurut saya agak membingungkan: sistem kontrol revisi yang tidak tahu apa pun tentang cabang atau tag. Dari sudut pandang implementasi, saya pikir cara Subversion untuk membuat "salinan" sangat pintar, tetapi saya harus mengetahuinya adalah apa yang saya sebut abstraksi bocor .

Atau mungkin saya baru saja menggunakan CVS terlalu lama.

Saya pikir beberapa kebingungan berasal dari perbedaan antara konsep tag dan implementasi di SVN. Untuk SVN, tag adalah cabang yang merupakan salinan. Memodifikasi tag dianggap salah dan alat sebenarnya seperti TortoiseSVN akan memperingatkan Anda jika Anda mencoba untuk memodifikasi apa pun dengan ../tags/ .. di jalur.

Saya tidak begitu yakin apa 'tag' itu, tetapi cabang adalah konsep kontrol sumber yang cukup umum.

Pada dasarnya, cabang adalah cara untuk bekerja pada perubahan kode tanpa mempengaruhi trunk. Katakanlah Anda ingin menambahkan fitur baru yang cukup rumit. Anda ingin dapat memeriksa perubahan saat Anda membuatnya, tetapi tidak ingin itu mempengaruhi trunk sampai Anda selesai dengan fitur.

Pertama, Anda akan membuat cabang. Ini pada dasarnya adalah salinan dari trunk ketika Anda membuat cabang. Anda kemudian akan melakukan semua pekerjaan Anda di cabang. Setiap perubahan yang dibuat di cabang tidak memengaruhi trunk, jadi trunk masih dapat digunakan, memungkinkan orang lain untuk terus bekerja di sana (seperti melakukan perbaikan bug atau peningkatan kecil). Setelah fitur Anda selesai, Anda akan mengintegrasikan cabang kembali ke bagasi. Ini akan memindahkan semua perubahan Anda dari cabang ke trunk.

Ada sejumlah pola yang digunakan orang untuk cabang. Jika Anda memiliki produk dengan beberapa versi utama yang didukung sekaligus, biasanya setiap versi akan menjadi cabang. Di tempat saya bekerja, kami memiliki cabang QA dan cabang Produksi. Sebelum merilis kode kami ke QA, kami mengintegrasikan perubahan ke cabang QA, lalu menyebar dari sana. Saat melepaskan ke produksi, kami mengintegrasikan dari cabang QA ke cabang Produksi, jadi kami tahu kode yang berjalan dalam produksi identik dengan apa yang diuji QA.

Inilah entri Wikipedia di cabang , karena mereka mungkin menjelaskan hal-hal yang lebih baik daripada yang saya bisa. :)

Trunk : Setelah selesainya setiap sprint dengan gesit, kami keluar dengan produk yang sebagian dapat dikirim. Rilis ini disimpan di bagasi.

Cabang : Semua kode pengembangan paralel untuk setiap sprint yang sedang berlangsung disimpan di cabang.

Tag : Setiap kali kami merilis jenis produk versi beta yang sebagian dapat dikirim, kami membuat tag untuk itu. Ini memberi kita kode yang tersedia pada titik waktu itu, memungkinkan kita untuk kembali pada keadaan itu jika diperlukan di beberapa titik selama pengembangan.

Bagi orang yang akrab dengan GIT, master di GIT setara dengan trunk di SVN.

Cabang dan tag memiliki terminologi yang sama di GIT dan SVN.