dvcs - apakah “clone to branch” merupakan alur kerja yang umum?

9

Saya baru-baru ini membahas DVD dengan rekan kerja, karena kantor kami mulai mempertimbangkan beralih dari TFS (kami adalah toko MS). Dalam prosesnya, saya menjadi sangat bingung karena dia mengatakan bahwa meskipun dia menggunakan Mercurial, dia belum pernah mendengar tentang perintah "cabang" atau "checkout", dan istilah-istilah ini tidak dikenalnya. Setelah bertanya-tanya bagaimana mungkin dia tidak tahu tentang mereka dan menjelaskan bagaimana dvc cabang bekerja "di tempat" pada file lokal Anda, dia cukup bingung.

Dia menjelaskan bahwa, mirip dengan cara TFS bekerja, ketika dia ingin membuat "cabang" dia melakukannya dengan kloning, jadi dia memiliki seluruh salinan dari repo-nya. Ini tampak sangat aneh bagi saya, tetapi manfaatnya, yang harus saya akui, adalah Anda dapat melihat atau bekerja pada dua cabang secara bersamaan karena file-file tersebut terpisah.

Dalam mencari situs ini untuk melihat apakah ini telah ditanyakan sebelum saya melihat komentar bahwa banyak sumber daya online mempromosikan metodologi "clone to branch" ini, membuat poster itu kecewa. Apakah ini sebenarnya umum di komunitas DVD? Dan apa saja pro dan kontra dari cara ini? Saya tidak akan pernah melakukannya karena saya tidak perlu melihat beberapa cabang sekaligus, beralih cepat, dan saya tidak perlu semua klon mengisi disk saya.

workflows dvcs branching

— Tesserex
sumber

7

ini merupakan pegangan dari alur kerja CVS dan SVN, ingat "ke palu semuanya terlihat seperti paku"

1

@JarrodRoberson - Hanya jika Anda membatasi diri pada cara gitkerjanya. Dengan hgini biasanya alur kerja pertama diajarkan dan itu masih sangat berguna.

— Mark Booth

3

Terlepas dari keuntungan / kerugian umum karena bisa melihat kedua cabang, saya pikir ada keuntungan khusus Mercurial untuk melakukan itu.

Jika Anda mengkloning untuk membuat cabang, Anda dapat menghapus clone nanti jika Anda tidak ingin menyimpan perubahan Anda. Jika Anda memutuskan untuk menggabungkan mereka, maka fakta bahwa Anda memutuskan untuk memisahkan perubahan Anda dengan cara ini tidak terlihat oleh orang lain.

Sebaliknya, jika Anda menggunakan hg branchuntuk membuat cabang bernama baru, nama cabang dicatat dalam sejarah ketika Anda melakukan, terlihat oleh semua orang, dan harus cukup unik untuk menghindari potensi kebingungan di kemudian hari. Ini mungkin tidak sesuai jika cabang Anda untuk mengembangkan beberapa fitur eksperimental, atau untuk perubahan yang ternyata kecil.

Jika Anda menggunakan cabang bernama untuk memelihara versi yang dirilis dari perangkat lunak Anda dan juga menggunakannya untuk mengembangkan fitur jangka pendek atau perbaikan bug, mudah untuk menjadi bingung karena tidak ada cara (selain konvensi penamaan) untuk memisahkan kedua jenis cabang ini.

http://mercurial.selenic.com/wiki/StandardBranching menjelaskan ini secara lebih rinci. Perlu juga disebutkan bahwa sejak Mercurial 1.8, dimungkinkan untuk membuat bookmark (hg bookmark ) - nama sekali pakai untuk cabang yang berumur pendek. Penanda dapat didorong, ditarik, dipindahkan dan dihapus.

— benj
sumber

2

Saya belum pernah menggunakan Mercurial banyak tetapi Git tidak memiliki masalah ini. Saya bisa bercabang sepanjang hari secara lokal, bergabung menjadi mengembangkan cabang, mendorong dan tidak ada yang harus melihat nama cabang saya.

— Andrew T Finnell

3

@AndrewFinnell: Itu tidak benar-benar cocok dengan pertanyaan, tapi saya ingin mengatakan bahwa itu tidak selalu menjadi masalah - ada juga beberapa keuntungan dengan cara bernama cabang dalam pekerjaan Mercurial. Misalnya, Anda dapat melihat di mana komit awalnya dibuat, yang dapat berguna untuk diketahui.

— benj

1

@AndrewFinnell - Cabang yang diberi nama adalah sesuatu yang saya sangat rindukan git, setelah terbiasa dengannya hg. Juga, harus ingat untuk secara eksplisit git branchsetiap kali saya ingin membuat cabang adalah menjengkelkan, dibandingkan dengan hgpenciptaan otomatis dari cabang yang tidak disebutkan namanya.

— Mark Booth

Anda masih dapat menggunakan ekstensi strip yang dibundel untuk menghapus cabang Anda di hg. Mercurial mendukung modifikasi riwayat dengan lebih baik hari ini melalui penggunaan "fase"

— dukeofgaming

2

Setiap kali Anda membuat komit dalam DVCS, Anda secara teknis membuat cabang dalam sejarah, setiap kali Anda mendorongnya kembali ke repositori diberkati yang Anda integrasikan kembali, inilah bagian yang menarik:

Jika tidak ada yang membuat perubahan selama komit Anda, itu tidak akan terlihat seperti cabang di DAG (grafik asiklik langsung)
Jika orang lain melakukan perubahan selama komit Anda, itu akan terlihat seperti cabang di DAG, hanya tanpa nama

Ingat tombol "fork" di Bitbucket / github ?, forking dapat dianggap sebagai sinonim dari percabangan, dan apa yang dilakukan tombol "fork" hanyalah tiruan dari repositori ke akun Anda.

Satu-satunya keuntungan dari "kloning ke cabang" adalah dapat bekerja secara bersamaan di dua titik dalam sejarah, dan ironisnya bagi rekan kerja Anda, itu adalah alur kerja yang umum untuk bekerja pada cabang yang berbeda pada saat yang sama (tanpa harus bolak-balik ).

Beritahu rekan kerja Anda untuk belajar bercabang , sangat mudah, di sini, memiliki tutorial:

D:\>mkdir lol

D:\>cd lol

D:\lol>hg init

D:\lol>hg branch
default

D:\lol>touch lol

D:\lol>hg add lol

D:\lol>hg commit -m "lol"

D:\lol>hg branch lol
marked working directory as branch lol
(branches are permanent and global, did you want a bookmark?)

D:\lol>hg branches
default                        0:35d562fafaf2

D:\lol>echo "lol" > lol

D:\lol>hg commit -m "New lol branch"

D:\lol>hg branches
lol                            1:9384f923e78d
default                        0:35d562fafaf2 (inactive)

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg update lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg merge lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

D:\lol>hg commit -m "lol merge"

D:\lol>hg branch
default

D:\lol>hg update lol
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

"Kloning ke cabang" masuk akal ketika Anda bekerja di cabang yang berbeda secara bersamaan , atau, ketika Anda ingin mencoba eksperimen tanpa membuat cabang permanen dalam sejarah dan masih dapat mengintegrasikannya kembali ke cabang yang sudah ada .

Saya pribadi tidak suka latihan ini dan lebih suka melakukan cabang dan menutupnya jika perlu. Di sini, ini adalah bagaimana Anda melakukannya:

D:\lol>hg branches
default                        2:46420aca1612
lol                            1:9384f923e78d (inactive)

D:\lol>hg branch
lol

D:\lol>hg commit --close-branch -m "Obai, glorious lol branch"

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branch
lol

D:\lol>hg update default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branches --closed
default                        2:46420aca1612
lol                            3:4b79c577e029 (closed)

Semoga ini menghapus keraguan DVCS Anda, di sini cabang tidak menakutkan lagi.

— dukeofgaming
sumber

0

Saya pribadi tidak akan khawatir tentang kode yang mengisi disk saya ... pertama, ini hanya kode, dan kedua, Anda tidak akan menyimpan semua klon Anda selamanya.

Metodologi ini dipromosikan dalam banyak sumber daya online, terutama untuk Hg. Saya belum pernah melihatnya digunakan dalam produksi, dalam lingkungan CI itu jauh lebih umum untuk memiliki cabang fitur berumur pendek daripada klon repositori tambahan. Saya tidak melihat keuntungan dari melakukan ini, jika apapun itu akan membuat sejarah Anda lebih membingungkan, tidak kurang, dan itu juga tidak memberi Anda apa-apa. Jika Anda ingin melihat kode baru Anda berdampingan dengan kode lama, Anda dapat menggunakan alat diff / merge untuk melihat dua komit di sebelah satu sama lain, dengan keuntungan tambahan bahwa Anda akan melihat perubahan Anda disorot.

— philosodad
sumber

Saya telah menggunakan ini secara ekstensif dalam produksi, dengan hg. Mampu mendorong dan menarik di antara beberapa hgrepositori dapat menjadi alat kolaborasi yang sangat kuat. Hanya dengan dapat menarik dari gitrepositori non-telanjang dapat secara substansial membatasi opsi Anda dengan alur kerja semacam ini.

— Mark Booth