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


1193

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?


29
Inilah artikel bagus yang saya jumpai menjelaskan bagaimana / kapan menggunakan trunk, cabang, dan tag. Saya tidak pernah menggunakan kontrol sumber sebelumnya, tetapi artikel ini membuatnya cukup mudah untuk dipahami oleh pemula seperti saya. Sehari-hari dengan Subversi
badmoon

Jawaban:


910

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.


284
Kebingungan dengan tag dan cabang adalah bahwa di svn tidak ada perbedaan di antara mereka, selain nama direktori. Di svn Anda dapat melakukan perubahan pada sebuah tag, dan sebenarnya sulit untuk mencegahnya. Sebagian besar VCSes lainnya menganggap tag sebagai snapshot yang tidak dapat diubah (poin waktu).
Ken Liu

4
Tagsdirektori juga sering digunakan untuk pengujian dan verifikasi tonggak oleh pengguna biasa. Ini akan menjadi tempat yang baik untuk meletakkan prototipe juga (hanya beberapa ide di atas kepala saya).
Jeff Noel

6
@ KenLiu Ada kait yang bisa membuat tag tidak berubah. Artinya, Anda bisa membuat, dan checkout tag, tetapi tidak membuat perubahan. Tentu saja, sebuah tag yang hanya menjadi bagian dari repositori berarti riwayat lengkap tersedia. Jika seseorang mengubah tag, Anda dapat melacaknya dan alasannya. Di banyak VCS, jika Anda memodifikasi tag, mungkin tidak ada cara untuk mengetahuinya.
David W.

3
Mungkin cabang stabil harus disebutkan: perubahan yang dibuat di sana biasanya tidak digabungkan kembali ke bagasi .
Wolf

4
Pemahaman saya adalah bahwa di "dunia yang sempurna" tidak ada perkembangan yang seharusnya terjadi di bagasi, bagasi harus selalu menjadi kode yang tepat yang ada di live atau kode yang akan dirilis ke live. dengan demikian yang akan menjadikan cabang-cabang tubuh utama pembangunan.
MikeT

556

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).


6
@ Baruch - Itu benar-benar salah. Tag itu ringan dan (sejauh menyangkut Subversion sendiri) identik dengan cabang.
Josh Kelley

7
Sukai detail use case. Terima kasih @gregmac.
Jeromy French

2
Bisakah saya mendapatkan penawaran di mana dinyatakan bahwa tag / cabang ringan? Sepertinya tidak seperti itu ..
Cardin Lee JH

3
Ini seharusnya jawaban yang diterima yang jauh lebih baik ^^
Nam G VU

4
@Ardin Saya tidak punya referensi sekarang, tetapi penting untuk dicatat tag ringan di server, tetapi bukan klien. Jika Anda checkout semua tag, Anda akan mendapatkan banyak salinan lengkap. Namun, jika Anda melihat ukuran repositori di server, itu hanya akan meningkat beberapa byte per tag. Inilah sebabnya mengapa Anda tidak perlu memeriksa direktori root, secara umum.
gregmac

97

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

masukkan deskripsi gambar di sini

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


1
@ Serigala dia bisa - diagram itu cukup umum terlepas dari tooling. Semua SCM menggunakan kata-kata yang berbeda tetapi konsep yang sama, tidak ada perbedaan antara trunk dan Main; atau trunk dan master. Diagram itu menunjukkan bagaimana perusahaan saya saat ini menggunakan SVN.
gbjbaanb

@ gbjbaanb Terima kasih telah berbagi. ... dan tag tampaknya tidak ditanggapi oleh pertanyaan. Apakah ini kebetulan murni (juga di perusahaan Anda saat ini) bahwa tidak ada penggabungan yang beralih dari cabang utama ke cabang yang dikelola?
Wolf

@ Wolf Tidak kebetulan - hanya cabang dari bagasi, lakukan pekerjaan, bergabung kembali ke bagasi. Kemudian cabut batang ke cabang tag. Kami sedang mempertimbangkan 'trunk' lain yang disebut Integrasi yang telah menyelesaikan cabang yang digabung untuk pengujian yang bukan merupakan rilis, trunk masih digunakan untuk cabang-cabang yang kami putuskan untuk rilis berikutnya. Satu-satunya saat Anda menggabungkan dari trunk ke cabang adalah memperbarui cabang yang sudah berjalan lama, tetapi lebih baik (dan lebih mudah) untuk hanya membuat cabang baru dari trunk dan menggabungkan perubahan cabang lama Anda ke cabang jika Anda membutuhkannya.
gbjbaanb

75

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'.


38

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.


30

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.


13

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:

Artikel-artikel di Wikipedia juga layak dibaca.


12

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.


10

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 .


9

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 ).


9

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 .


8

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.


Perspektif alternatif adalah bahwa yang sebaliknya adalah benar, bahwa memaksakan konsep tag pada model objek subversi akan menjadi abstraksi yang bocor ke arah yang berlawanan. Seperti yang saya duga Anda tahu, subversi adalah reaksi terhadap CVS, upaya untuk "melakukan CVS dengan benar." Saya tidak dapat menemukan referensi, tetapi desainer subversi asli mengatakan mereka membuang konsep tag 100% dengan sengaja, bahwa perbedaan antara cabang dan tag adalah murni masalah kebijakan. Jika tim ingin menerapkan kebijakan dan konvensi di atas model objek subversi, maka jadilah itu. Itulah tepatnya yang kita miliki hari ini.
Darryl

6

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.


5

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. :)


4

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.


Ini adalah alur kerja khusus Anda , itu tidak berlaku secara umum.
Jason S

4

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.

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.