Bagaimana cara menggunakan SVN, Cabang? Menandai? Bagasi?

Saya mencari-cari sedikit di sekitar dan tidak bisa menemukan panduan "pemula" yang bagus untuk SVN , bukan dalam arti "bagaimana cara menggunakan perintah"; Bagaimana saya mengontrol kode sumber saya?

Yang ingin saya jelaskan adalah topik berikut:

• Seberapa sering Anda berkomitmen? Sesering orang menekan Ctrl+ s?
• Apa itu Cabang dan apa itu Tag dan bagaimana Anda mengendalikannya?
• Apa yang masuk ke SVN? Hanya Kode Sumber atau apakah Anda juga membagikan file lain di sini? (Tidak dianggap file berversi ..)

Saya tidak tahu apa itu cabang dan tag jadi saya tidak tahu tujuannya, tetapi tebakan liar saya adalah bahwa Anda mengunggah barang ke bagasi dan ketika Anda melakukan pembangunan besar, Anda memindahkannya ke cabang? Jadi, apa yang dianggap sebagai bangunan utama dalam kasus ini?

The subversi buku adalah sumber informasi tentang strategi untuk meletakkan repositori Anda, bercabang dan penandaan.

Lihat juga:

Apakah Anda melanjutkan pengembangan di cabang atau di bagasi

Strategi percabangan

Saya bertanya pada diri sendiri pertanyaan yang sama ketika kami datang untuk mengimplementasikan Subversion di sini - sekitar 20 pengembang yang tersebar di 4 - 6 proyek. Saya tidak menemukan satu pun sumber yang bagus dengan '' jawabannya ''. Berikut adalah beberapa bagian dari bagaimana jawaban kami berkembang selama 3 tahun terakhir:

- Berkomitmen sesering mungkin; aturan dasar kami adalah komitmen setiap kali Anda telah melakukan pekerjaan yang cukup bahwa itu akan menjadi masalah harus melakukannya kembali jika modifikasi hilang; kadang-kadang saya komit setiap 15 menit atau lebih, kadang-kadang mungkin berhari-hari (ya, kadang-kadang butuh sehari untuk menulis 1 baris kode)

- kami menggunakan cabang, seperti yang disarankan salah satu dari jawaban Anda sebelumnya, untuk jalur pengembangan yang berbeda; saat ini untuk salah satu program kami, kami memiliki 3 cabang aktif: 1 untuk pengembangan utama, 1 untuk upaya yang belum selesai untuk memparalelkan program, dan 1 untuk upaya merevisinya untuk menggunakan input XML dan file output;

- kami jarang menggunakan tag, meskipun kami pikir kami harus menggunakannya untuk mengidentifikasi rilis untuk produksi;

Pikirkan pengembangan yang berjalan di satu jalur. Pada suatu waktu atau keadaan pengembangan pemasaran memutuskan untuk merilis versi pertama produk, sehingga Anda menanam bendera di jalur berlabel '1' (atau '1,0' atau apa pun). Pada waktu lain, beberapa percikan terang memutuskan untuk memparalelkan program, tetapi memutuskan bahwa itu akan memakan waktu berminggu-minggu dan bahwa orang-orang ingin terus menyusuri jalan utama sementara itu. Jadi, Anda membuat garpu di jalan dan orang-orang yang berbeda berkeliaran di berbagai garpu.

Bendera di jalan disebut 'tag', dan garpu di jalan adalah tempat 'cabang' membelah. Kadang-kadang, juga, cabang-cabang kembali bersama.

- kami menempatkan semua bahan yang diperlukan untuk membangun yang dapat dieksekusi (atau sistem) ke dalam repositori; Itu berarti setidaknya kode sumber dan membuat file (atau file proyek untuk Visual Studio). Tetapi ketika kita memiliki ikon dan file konfigurasi dan semua hal lainnya, itu masuk ke repositori. Beberapa dokumentasi menemukan jalannya ke dalam repo; tentu saja dokumentasi seperti file bantuan yang mungkin merupakan bagian integral dari program, dan ini merupakan tempat yang berguna untuk meletakkan dokumentasi pengembang.

Kami bahkan menempatkan executable Windows untuk rilis produksi kami di sana, untuk menyediakan satu lokasi bagi orang yang mencari perangkat lunak - rilis Linux kami menuju ke server sehingga tidak perlu disimpan.

- kami tidak mengharuskan repositori setiap saat mampu memberikan versi terbaru yang dibuat dan dijalankan; beberapa proyek bekerja seperti itu, beberapa tidak; keputusan ada pada manajer proyek dan tergantung pada banyak faktor, tetapi saya pikir itu rusak ketika membuat perubahan besar pada suatu program.

* How often do you commit? As often as one would press ctrl + s?

Sesering mungkin. Kode tidak ada kecuali ada di bawah kendali sumber :)

Komitmen yang sering (setelah itu set perubahan yang lebih kecil) memungkinkan Anda untuk mengintegrasikan perubahan Anda dengan mudah dan meningkatkan peluang untuk tidak merusak sesuatu.

Orang lain mencatat bahwa Anda harus melakukan ketika Anda memiliki sepotong kode fungsional, namun saya merasa berguna untuk melakukan sedikit lebih sering. Beberapa kali saya perhatikan bahwa saya menggunakan kontrol sumber sebagai mekanisme undo / redo cepat.

Ketika saya bekerja di cabang saya sendiri, saya lebih suka melakukan sebanyak mungkin (secara harfiah sesering saya menekan ctrl + s).

* What is a Branch and what is a Tag and how do you control them?

Baca buku SVN - ini adalah tempat yang harus Anda mulai ketika mempelajari SVN:

• Apa itu Cabang?
• Tag

* What goes into the SVN?

Dokumentasi, binari kecil yang diperlukan untuk membangun dan hal-hal lain yang memiliki nilai masuk ke kontrol sumber.

Berikut adalah beberapa sumber daya tentang frekuensi komit, pesan komit, struktur proyek, apa yang harus diletakkan di bawah kendali sumber dan pedoman umum lainnya:

• Praktik Terbaik Kontrol Versi (blog saya sendiri)
• Check in Awal, Check in Sering (Coding Horror) (komentar di sini mengandung banyak saran bagus)
• Kebijakan komitmen KDE

Pertanyaan Stack Overflow ini juga mengandung beberapa informasi berguna yang mungkin menarik:

• Mengatur basis kode sumber saat mencampur dua atau lebih bahasa (seperti Java dan C ++)
• Saran untuk pesan komit yang baik: format / pedoman?
• Seberapa sering melakukan perubahan pada kontrol sumber?
• Belajar Kontrol Versi, dan mempelajarinya dengan baik

Mengenai konsep Subversion dasar seperti percabangan dan penandaan, saya pikir ini sangat baik dijelaskan dalam buku Subversion .

Seperti yang mungkin Anda sadari setelah membaca sedikit lebih banyak tentang masalah ini, pendapat orang tentang praktik terbaik di bidang ini sering bervariasi dan terkadang saling bertentangan. Saya pikir pilihan terbaik bagi Anda adalah membaca tentang apa yang dilakukan orang lain dan memilih pedoman dan praktik yang menurut Anda paling masuk akal bagi Anda.

Saya tidak berpikir itu ide yang baik untuk mengadopsi praktik jika Anda tidak memahami tujuan itu atau tidak setuju dengan alasan di baliknya. Jadi jangan ikuti saran apa pun secara membabi buta, tetapi putuskan sendiri tentang apa yang menurut Anda paling sesuai untuk Anda. Juga, bereksperimen dengan berbagai cara dalam melakukan sesuatu adalah cara yang baik untuk belajar dan mencari tahu bagaimana Anda paling suka bekerja. Contoh yang baik dari ini adalah bagaimana Anda menyusun repositori. Tidak ada cara yang benar atau salah untuk melakukannya, dan seringkali sulit untuk mengetahui cara mana yang Anda sukai sampai Anda benar-benar mencobanya dalam praktik.

Frekuensi komitmen tergantung pada gaya manajemen proyek Anda. Banyak orang menahan diri dari melakukan jika itu akan merusak build (atau fungsionalitas).

Cabang dapat digunakan dalam satu dari dua cara, biasanya: 1) Satu cabang aktif untuk pengembangan (dan batang tetap stabil), atau 2) cabang untuk jalur dev alternatif.

Tag umumnya digunakan untuk mengidentifikasi rilis, sehingga tidak hilang dalam campuran. Definisi 'rilis' terserah Anda.

Saya pikir masalah utama adalah gambaran mental dari kontrol sumber bingung. Kami biasanya memiliki trunk dan cabang, tetapi kemudian kami mendapatkan ide yang tidak terkait dengan tag / rilis atau sesuatu yang mempengaruhi.

Jika Anda menggunakan gagasan pohon lebih lengkap, itu menjadi lebih jelas, setidaknya bagi saya itu.

Kami mendapatkan batang -> bentuk cabang -> menghasilkan buah (tag / rilis).

Gagasannya adalah Anda menumbuhkan proyek dari batang, yang kemudian membuat cabang setelah batang cukup stabil untuk menampung cabang. Kemudian ketika cabang telah menghasilkan buah Anda memetiknya dari cabang dan melepaskannya sebagai tag.

Tag pada dasarnya adalah kiriman. Sedangkan batang dan cabang menghasilkannya.

Seperti yang dikatakan orang lain, Buku SVN adalah tempat terbaik untuk memulai dan referensi hebat setelah Anda mendapatkan kaki laut Anda. Sekarang, untuk pertanyaan Anda ...

Seberapa sering Anda berkomitmen? Sesering orang menekan ctrl + s?

Seringkali, tetapi tidak sesering Anda menekan ctrl + s. Ini masalah selera pribadi dan / atau kebijakan tim. Secara pribadi saya akan mengatakan komit ketika Anda menyelesaikan sepotong kode fungsional, betapapun kecilnya.

Apa itu Cabang dan apa itu Tag dan bagaimana Anda mengendalikannya?

Pertama, trunk adalah tempat Anda melakukan pengembangan aktif. Ini adalah arus utama kode Anda. Cabang adalah beberapa penyimpangan dari jalur utama. Ini bisa menjadi penyimpangan besar, seperti rilis sebelumnya, atau hanya sedikit perubahan yang ingin Anda coba. Tag adalah snapshot dari kode Anda. Ini adalah cara untuk melampirkan label atau bookmark ke revisi tertentu.

Perlu juga disebutkan bahwa dalam subversi, trunk, cabang, dan tag hanya konvensi. Tidak ada yang menghentikan Anda dari mengerjakan tag atau memiliki cabang yang menjadi arus utama Anda, atau mengabaikan skema tag-branch-trunk secara bersamaan. Tetapi, kecuali Anda memiliki alasan yang sangat bagus, yang terbaik adalah tetap dengan kebiasaan.

Apa yang masuk ke SVN? Hanya Kode Sumber atau apakah Anda juga membagikan file lain di sini?

Juga pilihan pribadi atau tim. Saya lebih suka menyimpan apa pun yang terkait dengan build di repositori saya. Itu termasuk file konfigurasi, skrip bangun, file media terkait, dokumen, dll. Anda tidak boleh memeriksa file yang perlu berbeda pada setiap mesin pengembang. Anda juga tidak perlu memeriksa produk sampingan dari kode Anda. Saya berpikir sebagian besar membangun folder, file objek, dan sejenisnya.

Eric Sink, yang muncul di SO podcast # 36 pada Januari 2009, menulis serangkaian artikel yang sangat baik dengan judul Source Control How-to .

(Eric adalah pendiri SourceGear yang memasarkan SourceSafe versi plug-kompatibel, tetapi tanpa horribleness.)

Hanya untuk menambah satu set jawaban:

• Saya berkomitmen setiap kali saya menyelesaikan pekerjaan. Terkadang ini adalah perbaikan bug kecil yang hanya mengubah satu baris dan membutuhkan waktu 2 menit untuk saya lakukan; lain kali keringat bernilai dua minggu. Juga, sebagai aturan praktis, Anda tidak melakukan apa pun yang merusak bangunan. Jadi jika Anda butuh waktu lama untuk melakukan sesuatu, ambil versi terbaru sebelum melakukan, dan lihat apakah perubahan Anda merusak build. Tentu saja, jika saya berjalan lama tanpa melakukan komitmen, itu membuat saya gelisah karena saya tidak ingin kehilangan pekerjaan itu. Di TFS saya menggunakan yang bagus ini sebagai "rak" untuk ini. Di SVN Anda harus bekerja dengan cara lain. Mungkin buat cabang Anda sendiri atau buat cadangan file-file ini secara manual ke komputer lain.
• Cabang adalah salinan dari seluruh proyek Anda. Ilustrasi terbaik untuk penggunaannya mungkin adalah versi produk. Bayangkan Anda sedang mengerjakan proyek besar (katakanlah, kernel Linux). Setelah berbulan-bulan berkeringat, Anda akhirnya tiba di versi 1.0 yang Anda rilis untuk umum. Setelah itu Anda mulai bekerja pada versi 2.0 dari produk Anda yang akan menjadi jauh lebih baik. Tetapi sementara itu ada banyak orang di luar sana yang menggunakan versi 1.0. Dan orang-orang ini menemukan bug yang harus Anda perbaiki. Sekarang, Anda tidak dapat memperbaiki bug di versi 2.0 yang akan datang dan mengirimkannya ke klien - sama sekali tidak siap. Alih-alih, Anda harus mengeluarkan salinan sumber 1.0 yang lama, perbaiki bug di sana, dan kirimkan ke orang-orang. Inilah gunanya cabang. Ketika Anda merilis 1. 0 versi Anda membuat cabang di SVN yang membuat salinan kode sumber pada saat itu. Cabang ini bernama "1.0". Anda kemudian melanjutkan bekerja pada versi berikutnya dalam salinan sumber utama Anda, tetapi salinan 1.0 tetap ada seperti saat rilis. Dan Anda dapat terus memperbaiki bug di sana. Tag hanya nama yang dilampirkan pada revisi tertentu untuk kemudahan penggunaan. Anda bisa mengatakan "Revisi 2342 dari kode sumber", tetapi lebih mudah untuk menyebutnya sebagai "Revisi stabil pertama". :)
• Saya biasanya meletakkan segala sesuatu di kontrol sumber yang berhubungan langsung dengan pemrograman. Misalnya, karena saya membuat halaman web, saya juga meletakkan file gambar dan CSS di kontrol sumber, belum lagi file konfigurasi dll. Dokumentasi proyek tidak masuk ke sana, namun itu sebenarnya hanya masalah preferensi.

Orang lain telah menyatakan bahwa itu tergantung pada gaya Anda.

Pertanyaan besar bagi Anda adalah seberapa sering Anda "mengintegrasikan" perangkat lunak Anda. Pengembangan yang digerakkan oleh uji, Agile dan Scrum (dan banyak, banyak lainnya) mengandalkan perubahan kecil dan integrasi berkelanjutan. Mereka berkhotbah bahwa perubahan kecil dilakukan, semua orang menemukan waktu istirahat dan memperbaikinya sepanjang waktu.

Namun pada proyek yang lebih besar (bayangkan pemerintah, pertahanan, 100k + LOC) Anda tidak dapat menggunakan integrasi berkelanjutan karena itu tidak mungkin. Dalam situasi ini mungkin lebih baik menggunakan percabangan untuk melakukan banyak komitmen kecil tetapi membawa kembali ke bagasi HANYA apa yang akan bekerja dan siap untuk diintegrasikan ke dalam bangunan.

Satu peringatan dengan percabangan adalah bahwa jika mereka tidak dikelola dengan benar, itu bisa menjadi mimpi buruk di repositori Anda untuk mendapatkan pekerjaan ke dalam bagasi, karena semua orang berkembang dari tempat yang berbeda di bagasi (yang notabene merupakan salah satu argumen terbesar untuk integrasi berkelanjutan).

Tidak ada jawaban pasti untuk pertanyaan ini, cara terbaik adalah bekerja dengan tim Anda untuk menghasilkan solusi kompromi terbaik.

Kontrol Versi dengan Subversion adalah panduan untuk pemula dan tua.

Saya tidak berpikir Anda dapat menggunakan Subversion secara efektif tanpa membaca setidaknya beberapa bab pertama dari ini.

Untuk melakukan, saya menggunakan strategi berikut:

• komit sesering mungkin.

• Setiap perubahan fitur / perbaikan bug harus mendapatkan komit sendiri (jangan komit banyak file sekaligus karena itu akan membuat riwayat untuk file itu tidak jelas - misalnya Jika saya mengubah modul logging dan modul GUI secara independen dan saya melakukan keduanya sekaligus, kedua perubahan akan terlihat di kedua riwayat file. Ini membuat membaca riwayat file menjadi sulit),

• jangan memecah build berdasarkan komit apa pun - itu mungkin untuk mengambil versi repositori dan membangunnya.

Semua file yang diperlukan untuk membangun dan menjalankan aplikasi harus dalam SVN. File uji dan semacamnya tidak boleh, kecuali jika itu adalah bagian dari unit test.

Banyak komentar bagus di sini, tetapi sesuatu yang belum disebutkan adalah komit pesan. Ini harus bersifat wajib dan bermakna. Apalagi dengan percabangan / penggabungan. Ini akan memungkinkan Anda untuk melacak perubahan apa yang relevan dengan fitur bug mana.

misalnya svn commit . -m 'bug #201 fixed y2k bug in code'akan memberi tahu siapa pun yang melihat sejarah untuk apa revisi itu.

Beberapa sistem pelacakan bug (mis. Trac) dapat melihat di repositori untuk pesan-pesan ini dan menghubungkannya dengan tiket. Yang membuat mengetahui perubahan apa yang terkait dengan setiap tiket sangat mudah.

Kebijakan di tempat kerja kami berjalan seperti ini (tim multi-pengembang bekerja pada kerangka berorientasi objek):

• Perbarui dari SVN setiap hari untuk mendapatkan perubahan hari sebelumnya

• Berkomitmen setiap hari jadi jika Anda sakit atau tidak ada hari berikutnya, orang lain dapat dengan mudah mengambil alih dari tempat Anda tinggalkan.

• Jangan komit kode yang merusak apa pun, karena itu akan berdampak pada pengembang lain.

• Kerjakan potongan-potongan kecil dan lakukan setiap hari DENGAN KOMENTAR YANG BERARTI!

• Sebagai tim: Jaga cabang Pengembangan, lalu pindahkan kode pra-rilis (untuk QA) ke cabang Produksi. Cabang ini seharusnya hanya memiliki kode yang berfungsi penuh.

Manual TSVN TortoiseSVN didasarkan pada buku subversi , tetapi tersedia dalam lebih banyak bahasa.

Saya pikir ada dua cara untuk melakukan frekuensi:

1. Berkomitmen sangat sering, untuk setiap metode yang diterapkan, sebagian kecil kode, dll.
2. Komit hanya menyelesaikan bagian kode, seperti modul, dll.

Saya lebih suka yang pertama - karena menggunakan sistem kontrol sumber sangat berguna tidak hanya untuk proyek atau perusahaan, yang pertama itu berguna untuk pengembang. Bagi saya fitur terbaik adalah memutar kembali semua kode sambil mencari implementasi tugas yang ditugaskan terbaik.