dvcs - "dalı klonla" ortak bir iş akışı mı?

9

Son zamanlarda dvcs'i bir iş arkadaşınızla tartışıyordum, çünkü ofisimiz TFS'den geçiş yapmayı düşünmeye başlıyor (biz bir MS mağazasıyız). Bu süreçte çok karıştım çünkü Mercurial'ı kullanmasına rağmen bir "şube" veya "ödeme" komutu duymadığını ve bu terimlerin ona yabancı olduğunu söyledi. Onları bilmediğini ve dvcs şubelerinin yerel dosyalarınızda nasıl "yerinde" çalıştığını açıkladıktan sonra oldukça karışıktı.

TFS'nin nasıl çalıştığına benzer şekilde, bir "şube" oluşturmak istediğinde bunu klonlayarak yaptığını, böylece repolarının tüm bir kopyasına sahip olduğunu açıkladı. Bu benim için gerçekten tuhaf görünüyordu, ama kabul etmem gereken fayda, dosyalar ayrı olduğu için aynı anda iki şubeye bakabilmeniz veya üzerinde çalışabilmeniz.

Bu sitede arama yaparken, birçok çevrimiçi kaynağın posterin dehşetine bu "şube klon" yöntemini tanıtan bir yorum görmeden önce sorulup sorulmadığını görmek için. Bu aslında dvcs topluluğunda yaygın mıdır? Ve bu şekilde gitmenin avantajları ve dezavantajları nelerdir? Bir kerede birden fazla dalı görmeye gerek olmadığım için hiçbir zaman yapmam, geçiş hızlıdır ve diskimi dolduran tüm klonlara ihtiyacım yok.

workflows dvcs branching

— Tesserex
kaynak

7

Bu CVS ve SVN iş akışlarından bir tutun, "bir çekiç için her şey bir çivi gibi görünüyor" unutmayın

1

@JarrodRoberson - Sadece çalışma şeklinizi kısıtlarsanız git. İle hgbu genellikle ilk iş akışı öğretilen ve hala çok yararlı bir tanesidir.

— Mark Booth

3

Her iki dalı da görebilmenin genel avantajı / dezavantajı dışında, bunu yapmanın Mercurial'a özgü bir avantajı olduğunu düşünüyorum.

Şube oluşturmak için klonlarsanız, değişikliklerinizi saklamak istemiyorsanız klonu daha sonra silebilirsiniz. Onları birleştirmeye karar verirseniz, değişikliklerinizi bu şekilde ayırmaya karar vermeniz başkaları tarafından görülemez.

Buna karşılık, hg branchyeni bir adlandırılmış dal oluşturmak için kullanırsanız , dal adı taahhütte bulunduğunuz tarihte kaydedilir, herkes tarafından görülebilir ve daha sonra olası karışıklığı önlemek için oldukça benzersiz olmalıdır. Şubeniz bazı deneysel özellikler geliştirmek veya küçük olabilecek bir değişiklik içinse bu uygun olmayabilir.

Yazılımınızın yayınlanmış sürümlerini korumak için adlandırılmış dalları kullanır ve kısa vadeli özellikler veya hata düzeltmeleri geliştirmek için de kullanırsanız, bu iki tür dalı ayrı tutmanın hiçbir yolu olmadığından (kuralların adlandırılmasının yanı sıra) karıştırılması kolaydır.

http://mercurial.selenic.com/wiki/StandardBranching bunu daha ayrıntılı olarak açıklamaktadır. Ayrıca Mercurial 1.8'den beri, hg bookmarkkısa ömürlü bir dal için tek kullanımlık bir isim olan bir yer imi ( ) oluşturmak mümkündür . Yer işaretleri itilebilir, çekilebilir, hareket ettirilebilir ve silinebilir.

— Benj
kaynak

2

Mercurial'ı çok kullanmadım ama Git'in bu sorunu yok. Gün boyu yerel olarak şubelere ayrılabilirim, gelişmekte olan branşta birleşebilir, itebilirim ve hiç kimse benim şube isimlerime bakmaya gerek duymaz.

— Andrew T Finnell

3

@AndrewFinnell: Bu soruya tam olarak uymadı, ancak bunun mutlaka bir sorun olmadığını söylemek istedim - Mercurial çalışmasında şubeler olarak adlandırılan yolun bazı avantajları da var. Örneğin, bir taahhüdün aslen hangi dalda yapıldığını, hangisinin bilmek yararlı olabileceğini görebilirsiniz.

— benj

1

@AndrewFinnell - Adlandırılmış dallar, onlara alıştığım gerçekten özlediğim bir şey . Ayrıca, her şube oluşturmak istediğimde açık bir şekilde hatırlamak zorunda kalmak , adsız şubelerin otomatik olarak oluşturulmasına kıyasla sinir bozucu . githggit branchhg

— Mark Booth

Yine de şubenizi hg cinsinden silmek için birlikte gelen şerit uzantısını kullanabilirsiniz. Mercurial "aşamaları" kullanarak bu gün geçmiş modifikasyonunu daha iyi destekler

— dukeofgaming

2

Bir DVCS'de her taahhütte bulunduğunuzda, teknik olarak tarihte bir dal yapıyorsunuz, onu geri entegre ettiğiniz mübarek depoya her geri ittiğinizde, ilginç kısım geliyor:

Taahhüdünüz sırasında kimse değişiklik yapmazsa, DAG'daki bir şube gibi görünmeyecektir (yönlendirilmiş döngüsel grafik)
Taahhüdünüz sırasında başka biri değişiklik yaptıysa, DAG'da yalnızca adsız bir şube gibi görünecektir

Bitbucket / github'daki "fork" düğmesini hatırlayın, çatallama dallanmanın eş anlamlısı olarak kabul edilebilir ve "fork" düğmesinin yaptığı şey, hesabınız için bu havuzun bir klonudur.

"Şubeye klonlamanın" tek avantajı, tarihin iki noktasında eşzamanlı olarak çalışabilmesidir ve ironik olarak iş arkadaşınız için, aynı anda farklı dallarda (ileri geri gitmek zorunda kalmadan) çalışmak için yaygın bir iş akışıdır. ).

Öğrenmek için iş arkadaşınız söyle dalı , çok kolay bir öğretici var, burada,:

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

"Şubeye klonlama" , aynı anda farklı dallarda çalışırken veya geçmişte kalıcı bir dal oluşturmadan bir denemeyi denemek istediğinizde ve yine de zaten var olan bir şubeye entegre edebileceğinizde mantıklıdır .

Şahsen bu uygulamayı sevmiyorum ve gerektiğinde şubeler yapmayı ve kapatmayı tercih ediyorum. İşte, bunu nasıl yaparsınız:

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)

Umarım bu DVCS dallanma şüphelerinizi temizler, burada dallar artık korkutucu değil.

— dukeofgaming
kaynak

0

Şahsen kodumu diskimi doldurmaktan endişe etmem ... Birincisi, sadece kod ve ikincisi, tüm klonlarını sonsuza kadar saklamayacaksın.

Bu metodoloji, özellikle Hg için birçok çevrimiçi kaynakta desteklenmektedir. Üretimde kullanıldığını hiç görmedim, CI ortamlarında, kısa ömürlü özellik dallarına sahip olmak, ek depo klonlarından çok daha yaygın. Bunu yapmanın avantajını görmüyorum, eğer bir şey tarihinizi daha karmaşık hale getirecekse, daha az değil ve aynı zamanda size hiçbir şey kazandırmaz. Yeni kodunuza eski kodla yan yana bakmak isterseniz, değişikliklerinizin vurgulandığını göreceğiniz ek avantajla, birbirinin yanındaki iki işleme bakmak için bir fark / birleştirme aracı kullanabilirsiniz.

— philosodad
kaynak

Bunu üretimde yoğun olarak kullandım hg. Birden çok hgdepo arasında itme ve çekme yapabilmek gerçekten güçlü bir işbirliği aracı olabilir. Sadece çıplak olmayan depolardan çekebilmek , gitbu tür iş akışıyla seçeneklerinizi önemli ölçüde sınırlayabilir.

— Mark Booth