Dalları yalnız bir geliştirici olarak kullanmanın avantajları nelerdir?

Öncelikle, VCS hakkında kişisel bir geliştirici olarak birçok soru sorulduğunu biliyorum, ancak genellikle çok genişler. Bu sadece dallanma ile ilgilidir ve hala bir kopya olarak işaretlendi ... sözde kopya, yine, çok geniş ve özel bir dallanma ile ilgili olmayan başka bir sorunun başka bir kopyası olarak işaretlendi. Benim sorum böyle.

Dallandırmayı solo geliştirici olarak kullanmanın avantajları nelerdir? Sık sık bir solo-dev bağlamında bile tavsiye edildiğini gördüm, ancak görebildiğim kadarıyla, geliştirme için 'ana' bir bagaj kullanmanın ve çalışmak için ayrılmanın, kullanıma hazır kodun ötesinde, nasıl olduğunu göremiyorum. Tüm gelişim sürecini fazla karmaşık hale getirmeden dallanma gücünü (örneğin, yeni özellikleri bölümlendirmek için) kullanabilirim.

Avantajları çoğunlukla geliştirici grupları ile aynıdır. Her zaman bırakılmaya hazır bir ana dal ve yeni özellikler geliştirmek için özellik dallarını kullanarak, her zaman master'i serbest bırakabilirsiniz. Bir özellik üzerinde çalışırken önemli bir hata mı buldunuz? Şubeyi değiştirin, düzeltin, bırakın, geri geçin ve geliştirmeye devam edin.

Ya da belki bu bir hobi projesi ve ruh hali sizi etkilediğinde, bu özellik üzerinde biraz çalışabilmeyi seviyorsunuz. Temelde, zaman dilimlemeyle birden fazla kişili bir takımı taklit ediyorsun.

DVCS'lerin klonlar üzerinde yaptığı gizli dallanma, yetkili havuzdaki resmi dalların insanları koordine etmekten daha az, geliştirme yönlerini koordine etmekten daha fazla olduğu ve hatta tek bir kişinin bile çoğunu yapabileceği anlamına gelir.

Uzun süreli gelişim

Tek kişilik bir ekibin branşlaşması, aksi takdirde piyasaya sürülme döngünüze uymayan uzun süren bir geliştirme özelliği için faydalı olacaktır.

Çok aylık yayılma değişikliğiniz için bir şube açabilir ve yine de günlük hata düzeltmelerini veya ana şubenizdeki değişiklikleri düzenli aralıklarla ne kadar zorlayabilirseniz uygulayabilirsiniz.

Bu, ana şubenizin her zaman konuşlandırılabilir bir durumda olması ve tek bir dalda 'anahtarlama' avantajına sahiptir ve uzun süre çalışan bir özellikteki hiçbir şeyin önceden test edilmiş diğer kodlar üzerinde bir etkisi olmadığı garanti edilir.

Deneysel özellikler

Bir dal, prototip oluşturmak isteyebileceğiniz, ancak dağıtılan kodunuzda asla yapamayacağınız özellikler için de yararlı olabilir. Bunları nihayetinde atılmam gereken bir dalda tamamlamak, ana kod tabanınızı gereksiz yere asla kirletmeyeceğiniz anlamına gelir.

Kritik web sitelerinin bakımı için kullanıyorum. Ben tek geliştiriciyim, ancak bir dal, master ve geliştirme dalım var.

Site kurulumu için yaptığım iş süreci şöyle gözüküyor:

1. Uygulanabilir ana dal yap. İlk taahhüdünü yap.

2. Ödeme şube geliştirmek. Hiçbir şey yapmayın, master ile birleştirmek için bir test tamponu olarak fonksiyonlar geliştirin.

3. Ödeme konusu şubesi. Sorununuzu kodlayın, bittiğinde, geliştirmeye çekin, herhangi bir sorun çıkıp çıkmadığına bakın, çatışmaları birleştirin, vb. Düzeltin.

Bir sürüm için yeteri kadar sorun birleştiğinde ve geliştirme kararlılık açısından test edildiğinde, geliştirme konusunu usta hale getirin.

   Master
     |
   Develop  - E
   / |  \  \
 A   B   C  D

Bu sayede, Master'ı incitmek için risk almak zorunda kalmadan ve zarar vermeleri durumunda işleri geri almak zorunda kalmadan istikrarı, sorunları vb.

Ayrıca, taahhütte bulunmak için bireysel şubeler kullanarak, daha önce yapmış olduğunuz işleri "bırakabilir", daha acil bir sorunu çözmek için daha yeni bir şey başlatabilir ve daha sonra başarabilirsiniz.

Gerçek hayatta, genellikle bir sorun dalına sahibim ve onu geliştirmek için daha sonra da ustalığa çekiyorum. Bazen çok can sıkıcıdır, ancak en azından iki ayda bir, bir şapkayı düşürdüğümde işi bırakmam gerekiyor, çünkü birisi RightNow ™ yapmam gerektiğine dair bir fikrim vardı ve bu şekilde hızlı bir şekilde temel durumuna dönebilirim, şeyi yap ve sonra bulunduğum yerde devam et. Özellikle birkaç hafta süren büyük projelerle bu, dalları hızlı bir şekilde değiştirebildiğim bir nimettir.

Bu senaryoyu inceleyin: Her zaman bir ana branşta çalışıyorsunuz ve Master şubenizi açık kalp cerrahisinde bırakan çalışmalarda AwesomeCodeThing ™ 'e sahipsiniz ve acil olarak düzeltilmesi gereken bir YugeBug ™ çıkar. Aksi takdirde binlerce kullanıcı size BigProblems hakkında şikayet eder
. Böyle bir senaryoda sorununuzu hızlıca çözmenin tek yolu,

1. önceki komisyonlarınızı kontrol edin,
2. son kararlı taahhüdünüzün ne zaman yapıldığını görün (küfür etmek isteğe bağlıdır)
3. bu taahhüde geri dön
4. düzeltme yapmak, üretimi düzeltmek
5. Şimdi AwesomeCodeThing ™ durumuna geri dönmeye çalıştığınız tüm çatışmaları ve sorunları çözme
6. pes et, ağla ve çalışmaya başla. (isteğe bağlı)

Dallar kullanıyorsanız:

1. Ödeme yöneticisi
2. şube UrgentFix ™ oluşturun ve işleri düzeltin
3. UrgentFix ™ 'i master'a çekin
4. üretime itmek
5. Master'ı birleştirmek için geliştirin
6. Birleşmeyi AwesomeCodeThing ™ 'e dönüştürün
7. bir bira al ve çalışmaya devam et.

Şubeler, bir kerede birden fazla özellik üzerinde çalışmayı kolaylaştırır; bu, bir proje sırasında öncelikler değiştiğinde oldukça yardımcı olabilir.

Bir özelliğin şimdi daha önemli olduğuna karar verdiğinizi varsayalım. Belki de canlı bir sistemde kritik bir hatayı acilen düzeltmeniz gerekiyor. Bir müşteri ile uzun bir süre boyunca birden fazla özellik üzerinde çalışıyor olabilir ve her bir özelliğin ilerlemesini ayrı ayrı göstermek isteyebilirsiniz. Belki de sıfır günlük kötü bir istismar hakkında bir şeyler okudunuz ve müşteri bunu okumadan önce bunun üzerine gelmek istemiştiniz.

Her özellik / düzeltme için dallar kullanıyorsanız, her şey için tek bir dal kullanmak yerine, bu değişiklikleri izole etmek ve dağıtmak genellikle daha kolay, daha temiz ve daha hızlı olacaktır. Bu, tek bir geliştirici veya bir ekibin parçası olsanız da geçerlidir.

Gerçek bir süreç için git akışının iyi çalıştığını görüyorum. Daniel Kummer'in git akış kopya kağıdı harika bir kaynak, git kullanmasanız bile bakmaya değer.

Diğer posterlerde de belirtildiği gibi, avantajlar takımlarda çalışmakla büyük ölçüde benzerlik göstermektedir: Özellikleri bağımsız olarak geliştirme ve test etme, düzeltmeler / üretim uygulamaları için ayrı bir ana branş oluşturma, deneme yeteneği.

Şahsen ben, üzerinde çalıştığım alanı çok iyi tanıyorsam, ustalıkla çalışma eğilimindeyim, sadece şubeye ek yüklendi çünkü onları yine de birleştireceğim.

Ancak, yaptığım değişiklikler hakkında herhangi bir tereddütüm varsa , şube beklerim ve genel olarak tam olarak test edildiğinde dallanacağım ve yalnızca PR / birleştirme. Bu şekilde, geri dönüşün en iyi eylem şekli olduğu bir sorun keşfedersem, tüm bir dizi yerine tek bir işlemdir (bir dizi işin geri alınmasına ilişkin sözdizimini asla hatırlayamıyorum, ancak tek bir işlem kolaydır).