Maaf jika ini duplikat, saya melihat.
Kami pindah ke Git. Di Subversion, saya sudah terbiasa dengan folder \ trunk, \ branch dan \ tag.
Dengan Git, beralih antar cabang akan menggantikan konten direktori yang berfungsi, jadi apakah saya benar berasumsi bahwa cara kami dulu bekerja tidak berlaku dengan Git?
Dugaan saya adalah bahwa saya akan memiliki folder repo dengan mungkin gitignore dan readme.txt, lalu folder untuk proyek yang membentuk repo, dan hanya itu.
Jawaban:
Anda akan memiliki "trunk", sekarang disebut "master", Anda akan memiliki "cabang" sekarang disebut "kepala" dan Anda akan memiliki "tag", masih disebut "tag", tetapi mereka tidak akan menjadi folder , mereka akan menjadi " ref ", label untuk revisi yang tinggal di namespace terpisah di dalam repositori.
Subversion dan Git memiliki cara berbeda untuk melakukan percabangan. Model subversi dasar adalah memiliki pohon direktori dengan timeline global tunggal dan jika Anda ingin bercabang, Anda menyalin subtree di direktori lain.
Di sisi lain Git memiliki pohon direktori dengan revisi yang masing-masing mendefinisikan orang tuanya, tetapi setiap revisi dapat memiliki banyak orang tua (gabungan) dan beberapa anak (cabang). Jadi, alih-alih memiliki direktori untuk cabang, Anda mendapatkan revisi yang dibuat secara independen. "Referensi" hanyalah nama yang terkait dengan revisi terbaru untuk "cabang" yang diberikan.
Perbedaan ini mendasar untuk kontrol versi terdistribusi. Git (dan sistem terdistribusi lainnya) tidak memiliki otoritas pusat untuk menjaga sejarah tetap linear, sehingga revisi dapat dibuat secara independen pada beberapa repositori tanpa mengetahui satu sama lain dan sistem harus mengakomodasi mereka. Ternyata generalisasi membuat percabangan dan penggabungan jauh lebih mudah secara umum.
Perhatikan, bahwa di Git, revisi tidak ada di cabang mana pun. Mereka hanya ada dan cabang memuatnya. Tetapi begitu cabang digabung, atau terbukti jalan buntu, Anda bisa menghapus "ref" yang menunjuk padanya dan lupakan semuanya (jika Anda membuang percobaan lama, akhirnya akan dikumpulkan dengan sampah git gc). Ini membantu Anda menghindari kebanjiran eksperimen lama yang tak seorang pun ingat apa yang sedang mereka bicarakan.
Anggap saja Git sebagai tampilan 3D dari data yang sama yang Anda lihat dalam 2D di SVN - yaitu dengan SVN Anda bercabang root dan muncul sebagai salinan yang ditunjukkan sebagai folder baru di pohon. Dengan Git, ketika Anda bercabang muncul sebagai salinan yang ditampilkan sebagai "lapisan" di atas pohon yang ada. Setelah Anda menyadari bahwa itu cukup mudah untuk membuat perbedaan.
Dengan SVN Anda masih dapat bekerja dengan cara yang sama seperti Git - beralih antar cabang akan menggantikan tampilan tunggal basis kode dengan tampilan bercabang, ini berlaku apakah Anda menggunakan svn switch atau git checkout.
Jelas Anda bisa mendapatkan salinan cabang di SVN dengan memeriksa cabang ke lokasi foldernya, yang sama dengan mengkloning git repo ke lokasi lain di disk Anda.
Hal yang sama berlaku untuk tag - Anda dapat memberi label revisi git, atau Anda dapat membuat cabang untuk rilis. Tag SVN sama dengan cabang, satu-satunya konvensi yang mereka sebut 'tag'. Anda bisa memberi label (baik, catat nomor revisi) dari repo SVN untuk mendapatkan snapshot dari rilis juga.
Perbedaan antara git dan svn lebih berkaitan dengan bagaimana checkin dan checkout terjadi, bukan dengan dasar-dasar kontrol sumber. Tampilan kode bisa berbeda (Anda tidak akan pernah melihat satu tampilan pun dari kode pohon yang menyertakan cabang di git, dan Anda bisa membuat cabang repositori parsial di SVN, tetapi ini pada akhirnya merupakan perbedaan kecil)