Pertanyaan Apa arti "cabang", "tag" dan "batang" dalam repositori Subversion?


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

Apa yang mereka maksud?


1131
2017-08-19 13:22


asal


Jawaban:


Hmm, tidak yakin saya setuju dengan nick re tag yang mirip dengan cabang. Sebuah tag hanyalah sebuah penanda

  • Bagasi akan menjadi badan utama pembangunan, yang berasal 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 digabung kembali ke dalam bagasi.

  • Menandai akan menjadi titik waktu pada batang atau cabang yang ingin Anda pertahankan. Dua alasan utama untuk preservasi adalah bahwa ini adalah rilis besar dari perangkat lunak, apakah alfa, beta, RC atau RTM, atau ini adalah titik paling stabil dari perangkat lunak sebelum revisi besar pada bagasi diterapkan.

Dalam proyek sumber terbuka, cabang utama yang tidak diterima ke dalam batang oleh pemangku kepentingan proyek dapat menjadi basis untuk garpu - misalnya, proyek yang benar-benar terpisah yang berbagi asal yang sama dengan kode sumber lain.


864
2017-08-19 13:35



Pertama-tama, seperti yang ditunjukkan oleh @AndrewFinnell dan @KenLiu, di SVN nama direktori itu sendiri tidak berarti apa-apa - "batang, ranting dan tag" hanyalah sebuah konvensi umum yang digunakan oleh sebagian besar 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 inginkan, meskipun melanggar konvensi sering membingungkan.

Saya akan menjelaskan skenario penggunaan paling mungkin dari cabang dan tag, dan memberikan contoh skenario bagaimana mereka digunakan.

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

  • Ranting: Setiap kali Anda merilis versi utama, itu membuat cabang dibuat. Ini memungkinkan Anda 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 akhir, rilis kandidat (RC), dan beta) Anda membuat tag untuk itu. Ini memberi Anda salinan point-in-time kode seperti pada keadaan itu, memungkinkan Anda untuk kembali dan mereproduksi bug apa pun jika diperlukan dalam versi sebelumnya, atau merilis ulang versi sebelumnya persis seperti itu. Cabang dan tag dalam SVN ringan - di server, itu tidak membuat salinan lengkap dari file, hanya penanda yang mengatakan "file-file ini disalin pada revisi ini" yang hanya membutuhkan beberapa byte. Dengan pemikiran ini, Anda tidak perlu khawatir tentang membuat tag untuk setiap kode yang dirilis. Seperti yang saya katakan sebelumnya, tag sering diabaikan dan sebaliknya, 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 batang ke cabang "1.0" baru, dan membuat "1.0.0" tag. Sekarang kerjakan apa yang pada akhirnya akan menjadi 1,1 terus di bagasi.

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

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 sudah usang di 1.1. Tidak terlalu penting: Anda hanya ingin memastikan bahwa Anda tidak merilis 1.1 dengan bug yang sama yang telah diperbaiki pada 1.0.

  • trunk / - versi pengembangan, segera menjadi 1.1
  • cabang / 1.0 - rilis 1.0.1 mendatang
  • tags / 1.0.0 - versi rilis 1.0.0

Setelah Anda menemukan cukup bug (atau mungkin satu bug penting), 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, bagasi akan berisi apa yang akan menjadi 1,1, dan cabang "1.0" berisi kode 1.0.1. Saat berikutnya Anda merilis pembaruan ke 1.0, itu akan menjadi 1.0.2.

  • trunk / - versi pengembangan, segera menjadi 1.1
  • cabang / 1.0 - rilis 1.0.2 mendatang
  • tags / 1.0.0 - versi rilis 1.0.0
  • tag / 1.0.1 - versi rilis 1.0.1

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

  • trunk / - versi pengembangan, segera menjadi 1,2
  • branches / 1.0 - rilis 1.0.2 mendatang
  • branches / 1.1 - rilis 1.1.0 yang akan datang
  • tags / 1.0.0 - versi rilis 1.0.0
  • tag / 1.0.1 - versi rilis 1.0.1
  • tag / 1.1beta1 - versi rilis 1.1 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 ingin, memetakan perbaikan bug di antara ketiga cabang (1.0, 1.1, dan trunk). Yang penting adalah bahwa untuk setiap versi utama dari perangkat lunak yang Anda pertahankan, Anda memiliki cabang yang berisi kode versi terbaru untuk versi itu.


Penggunaan lain dari cabang adalah untuk fitur. Di sinilah Anda cabang batang (atau salah satu cabang rilis Anda) dan bekerja pada fitur baru dalam isolasi. Setelah fitur selesai, Anda menggabungkannya kembali dan menghapus cabang.

  • trunk / - versi pengembangan, akan segera menjadi 1.2
  • branches / 1.1 - rilis 1.1.0 yang akan datang
  • cabang / ui-rewrite - cabang fitur eksperimental

Ide dari ini adalah ketika Anda sedang mengerjakan sesuatu yang mengganggu (yang akan menahan atau mengganggu orang lain dari melakukan pekerjaan mereka), sesuatu yang eksperimental (yang mungkin tidak membuatnya dalam), atau mungkin hanya sesuatu yang membutuhkan waktu lama (dan Anda takut jika menahan rilis 1,2 saat Anda siap untuk cabang 1,2 dari trunk), Anda dapat melakukannya secara terpisah di cabang. Umumnya Anda menyimpannya dengan trunk dengan menggabungkan perubahan ke dalamnya setiap waktu, yang membuatnya lebih mudah untuk mengintegrasikan kembali (menggabungkan kembali ke trunk) ketika Anda selesai.


Juga perhatikan, skema versi yang saya gunakan di sini hanyalah salah satu dari banyak. Beberapa tim akan melakukan perbaikan bug / rilis pemeliharaan seperti 1.1, 1.2, dll., Dan perubahan besar seperti 1.x, 2.x, dll. Penggunaan di sini sama, tetapi Anda dapat menamai cabang "1" atau "1 .x "bukan" 1.0 "atau" 1.0.x ". (Ke samping, versi semantik adalah panduan yang baik tentang cara melakukan nomor versi).


536
2017-09-20 19:00



Selain apa yang dikatakan Nick, Anda dapat mengetahui lebih lanjut Streamed Lines: Branching Patterns untuk Pengembangan Perangkat Lunak Paralel

enter image description here

Di angka ini main adalah bagasi, rel1-maint adalah cabang dan 1.0 adalah sebuah tag.


92
2017-08-19 13:58



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

  • Bagasi adalah cabang utama direkomendasikan oleh Subversion, tetapi Anda sama sekali tidak dipaksa untuk membuatnya. Anda dapat menyebutnya 'utama' atau 'rilis', atau tidak memiliki satu sama sekali!

  • Cabang merupakan upaya pengembangan. Seharusnya tidak pernah diberi nama setelah sumber daya (seperti 'vonc_branch') tetapi setelah:

    • sebuah tujuan 'myProject_dev' atau 'myProject_Merge'
    • perimeter rilis 'myProjetc1.0_dev'atauProject2.3_Merge' atau 'myProject6..2_Patch1' ...
  • Menandai adalah cuplikan file agar mudah kembali ke keadaan itu. Masalahnya adalah tag dan cabang itu sama dalam 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 kecuali membuat salinan baru di area tag.

Tag adalah final. Isinya tidak boleh berubah. TAK PERNAH. Pernah. Anda lupa baris di catatan rilis? Buat tag baru. Usang atau hapus yang lama.

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

Dengan konvensi, cabang batang dapat mewakili keadaan saat ini dari perkembangan Anda, tetapi itu adalah untuk proyek sekuensial sederhana, yaitu proyek yang memiliki:

  • tidak ada pengembangan 'sebelumnya' (untuk menyiapkan versi berikutnya-berikutnya yang menyiratkan perubahan tersebut sehingga tidak kompatibel dengan pengembangan 'batang' saat ini)
  • tidak ada refactoring besar (untuk menguji pilihan teknis baru)
  • tidak ada perawatan jangka panjang dari rilis sebelumnya

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


73
2017-08-19 13:25



Dalam SVN tag dan cabang sangat mirip.

Menandai = irisan yang ditentukan dalam waktu, biasanya digunakan untuk rilis

Cabang = juga potongan waktu yang ditentukan bahwa pengembangan dapat dilanjutkan, biasanya digunakan untuk versi utama seperti 1.0, 1.5, 2.0, dll, kemudian ketika Anda melepaskan Anda menandai cabang. Ini memungkinkan Anda untuk terus mendukung rilis produksi sambil bergerak maju dengan memecah perubahan di bagasi

Bagasi= ruang kerja pengembangan, ini adalah tempat semua pengembangan harus terjadi, dan kemudian perubahan digabung kembali dari rilis cabang.


36
2017-08-19 13:27



Mereka tidak memiliki arti formal. Folder adalah folder ke SVN. Mereka adalah cara yang diterima secara umum untuk mengatur proyek Anda.

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

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

  • Dan folder tag adalah untuk membuat salinan dari penyimpanan Anda, biasanya di pos pemeriksaan rilis.

Tapi seperti yang saya katakan, untuk SVN, folder adalah folder. branch, trunk dan tag hanyalah sebuah konvensi.

Saya menggunakan kata 'copy' secara bebas. SVN tidak benar-benar membuat salinan lengkap dari hal-hal dalam repositori.


28
2017-08-19 13:37



Itu bagasi adalah jalur pengembangan yang menyimpan kode dan fitur sumber terbaru. Itu harus memiliki perbaikan bug terbaru di dalamnya serta fitur-fitur terbaru yang ditambahkan ke proyek.

Itu ranting biasanya digunakan untuk melakukan sesuatu yang jauh dari batang (atau jalur pengembangan lainnya) yang sebaliknya istirahat membangun. Fitur-fitur baru sering dibangun di cabang dan kemudian digabungkan kembali ke dalam bagasi. Cabang sering mengandung kode yang tidak harus disetujui untuk jalur pengembangannya. Sebagai contoh, seorang pemrogram dapat mencoba pengoptimalan pada sesuatu di cabang dan hanya menggabungkan kembali dalam jalur pengembangan setelah pengoptimalan memuaskan.

Itu tag adalah snapshot dari repositori pada waktu tertentu. Tidak ada pengembangan yang seharusnya 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:

Artikel-artikel di Wikipedia juga layak dibaca.


12
2018-06-30 11:50



Nah, itulah 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 pula.

Inilah cara saya yang sederhana,

bagasi - Direktori trunk berisi bagian kerja yang paling mutakhir, disetujui, dan digabungkan. Bertentangan dengan apa yang diakui banyak orang, belalaku hanya untuk pekerjaan yang bersih, rapi, disetujui, dan bukan bidang pengembangan, melainkan area rilis.

Pada suatu titik waktu tertentu ketika bagasi tampaknya semua siap untuk dilepaskan, maka itu ditandai dan dilepaskan.

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

Misalnya: Saya dapat memiliki iterasi-5 cabang untuk pengembangan ronde kelima pada produk, mungkin a prototipe-9 cabang untuk putaran kesembilan bereksperimen, dan seterusnya.

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

Saya kira dengan tag saya bisa melompat bolak-balik melalui waktu ke titik bunga dengan mudah.


10
2017-08-19 13:28



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

Direktori cabang adalah untuk menahan dahan 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 pada revisi ini dan "1.1" menjadi file-file ini pada revisi ini. Anda biasanya tidak mengubah tag setelah dibuat. Untuk informasi lebih lanjut tentang tag, lihat Bab 4. Bercabang dan Bergabung (di Kontrol Versi dengan Subversion).


8
2017-11-17 20:39