Merkezi sürüm kontrolünde, sık sık güncelleme yapmak her zaman iyidir mi?

Varsayım:

• Ekibiniz merkezi sürüm kontrolünü kullanıyor.
• Tamamlanması birkaç gün sürecek daha büyük bir özellik üzerinde çalışıyorsunuz ve bundan önce taahhütte bulunamayacaksınız, çünkü yapıyı bozacaktır.
• Ekip üyeleriniz her gün üzerinde çalıştığınız bazı dosyaları değiştirebilecek bir şey yapar.

Bu merkezi sürüm kontrolü olduğundan, yerel kasanızın bir noktada güncellemeniz gerekir: yeni özelliği gerçekleştirmeden en az bir kez önce.

Taahhüdünüzden hemen önce yalnızca bir kez güncelleme yaparsanız, takım arkadaşlarınız tarafından yapılan birçok değişiklik nedeniyle birçok çatışma olabilir, bu da bir anda çözülmesi gereken bir acı dünyası olabilir.

Ya da, sık sık güncelleme yapabilirsiniz ve her geçen gün çözülmesi gereken birkaç çatışma olsa bile, bunu yavaş yavaş yapmak daha kolay olmalıdır.

Sık sık güncellemek her zaman iyi bir fikir olur mu?

Şahsen, yerel versiyonlarımı her gün güncelliyorum.

Açıkladığınız senaryoda,

• Yeni, uzun özellik için bir dal oluşturmak.
• Ana hattan bu yeni şubeye sık sık birleşin.

Bu yoldan,

• Kodunuzu sunucuda korumak için günlük olarak check-in yapabilirsiniz
• Check-in yaparak yapıyı kırmak konusunda endişelenmenize gerek yok.
• Daha önceki check-in'lerle gerektiğinde bazı işleri veya farklılıkları geri almak için havuzu kullanabilirsiniz.
• En son kod tabanı üzerinde çalıştığınızdan ve olası çakışan kod değişikliklerini erkenden algıladığınızdan emin olabilirsiniz.

Onları gördüğüm dezavantajlar

• Ana cihazdan birleştirme manuel olarak (veya komut dosyasıyla) yapılmalıdır.
• Daha fazla "yönetim" gerektirir

Evet, sık sık güncelleme yapmak iyi bir fikirdir. Zor birleştirme çakışmalarından kaçınmak için sık sık güncelleştirirsiniz ve bu, ıraksak değişiklik sorunu olan Yazılım Yapılandırma Yönetimi (SCM) bilgisinin temelidir.

Bu, merkezileştirilmiş veya dağıtılmış olsun; yukarı akış kaynağından ne kadar uzun süre ayrılırsanız (DVCS davasında bir gövde, dal veya başka bir havuz ise) birleştirme çakışmaları olasılığı o kadar yüksek olur. Evet, güncelleme sırasında ekibinizden kötü sürprizler gelebilir, ancak kötü sürprizin ertelenmesi daha da kötüleşir (ne kadar uzun beklerseniz, neden bir takım değişikliklerin yapıldığını daha az hatırlar).

Güncelleme çalışması için bu aynı zamanda kod üzerinde çalışan diğer programcıların asla bilerek yapmayı veya derlemeyi bozan yukarı akış kodunu zorlamaması gerektiği anlamına gelir . Bu nedenle, takım üyelerinizi ve diğer paydaşlarınızı, böyle bir durumun kaçınılmaz olarak ortaya çıkması durumunda kod kırılmasına karşı korumak için programcılar genellikle dallanır (veya SCM açısından yukarı akıştan ayrılır).

Hatırlamak için kullanabileceğiniz mantra şudur: "güncelleme, güncelleme, güncelleme, kaydetme". Taahhüt etmeden önce daima değişikliklerinizin başkalarıyla çalıştığından emin olun. Bu, kodun ilk kez kontrol edilmesinin de işe yaramasını sağlamak içindir.

Sorudaki 3. madde işareti yanlıştır :

• Tamamlanması için birkaç gün sürecek yeni bir özellik üzerinde çalışıyorsunuz ve bundan önce taahhütte bulunamayacaksınız, çünkü yapıyı bozacaktır.

Bir süre işleyemeyeceğiniz bir şey üzerinde çalışacağınızı biliyorsanız , bu dalları kullanmak için ders kitabı örneğidir.

Kendinizi bekleyen birçok değişikliğin olduğu duruma sokmayın. Eğer varsa bilmek size bir süre projenizin ana dal taahhüt mümkün olmayacaktır, sonra başka dal üzerinde çalışmak. Ve orada, sık sık taahhüt edin .

Zaten soruda açıklanan durumdaysanız, şu anda bir şubeye geçin , değişikliklerinizi yapın ve o şubede çalışmaya devam edin.

Normalde CVCS'de sık sık güncelleme yapmak iyi bir fikirdir. Ama bir dal üzerinde çalışıyorsanız, o zaman "sık sık güncelleme ya da değil" sorusu "sık sık birleştirme ya da değil" haline gelir. Ve cevap zaten evet. Başka bir şubeden birleştirmeden önce beklemedeki tüm değişiklikleri (şubede) yaptığınızdan emin olun, gerekirse birleştirmeyi güvenli bir şekilde geri alma seçeneğinize.

Bence daha sık taahhüt etmelisin . Birkaç gün gibi uzun bir süre çalışacaksanız, kodunuzu dallandırmalı ve doğrudan bagajda çalışmak yerine şubenizde çalışmalısınız. Şubeler olmadan çalışmaya başlamanın elverişli olduğunu biliyorum, ancak güncellemenizin / taahhüdünüzün kodunuzu kıracağından ya da kırmayacağından emin olamayacağınız için gerçekten esnek değil, bu da güncellemenizi / taahhüdünüzü işini yaptın. "Özellik dallanması", kodunuzu her zaman işleme koyabileceğiniz şekilde daha iyidir ve bittikten sonra tekrar birleştirebilirsiniz.

Dallanma stratejisinde, güncellemenin yerini bagajdan birleştirme alır. Deneyimlerime göre, beş günlük zaman dilimi gibi bir kodun çok fazla değişmeyeceği ve çatışmayı yalnızca bitirdiğinizde çözmek daha kolay olduğu için, bagajdan sık sık birleştirmeniz gerekmez.

Aslında yerel olarak dağıtılmış bir sürüm kontrolü kullanmayı daha uygun buluyorum. Yani git subversion istemcisi olarak kullanıyorum. Bunun avantajları vardır:

• Yerel değişiklikler güncellemeden önce kaydedilir, bu nedenle birleştirme işleminde hata yaparsam, her zaman geri dönüp tekrar yapabilirim.
• Daha büyük değişiklikler yaparken, bitmiş parçaları kaydedebilirim. Bu, devam eden değişikliklerin incelenmesini kolaylaştırır.
• Daha büyük bir çalışma sırasında bir hatayı düzelttiğimde, sadece bu düzeltmeyi yapabilir, geri kalanını geçici olarak yapabilir ve diğer çalışmayı yerel tutarken yıkım düzeltmesini "dcommit" edebilirim.

Yeni bir özellik ekliyorsanız, yeni bir tek kaynak dosya (ve eşleşen bir harici arayüz başlık dosyası) oluşturabilir misiniz?

"Yeni bir özelliğin" yaygın sonuçları olduğu konusunda endişeliyim? Nesne yönelimi artık eskisi gibi bir terim olmayabilir, ama o paradigmada hak vardır.

Bu şekilde çerçeveyi (dış arabirim artı saplama işlevleri) oluşturabilir ve geliştirmenin geri kalanını tamamlarken minimum üçüncü taraf etkisi olması gerektiğini taahhüt edebilirsiniz?

Açıkladığınız durumda, daha az büyük dosyadan daha küçük kaynak dosyalara sahip olmanın daha iyi olduğunu hissediyorum.

Merkezi sürüm kontrolü için dağıtılmış olandan farklı mıdır?

Her iki durumda da, başlattığınız içerikle karşılaştırıldığında içeriği taşınmış bir yere check-in yapmanız gerekir. Merkezi depodan çalışma yerinize birleşme sıklığında hiçbir fark görmüyorum (ve proje şubeniz çalışma yerinizdir).

Sıklıkla birleşme yolunda olma eğilimindeyim (en az günde bir kez, benim için uygun başka bir zamanda da veya birinin üzerinde çalıştığım şeyi etkileyen bir şeyi kontrol ettiğini bildiğimde) birleşebilirim. Küçük değişiklikleri absorbe etmek çok daha kolay ve bir sorununuz varsa, insanlar sadece kontrol ettikleri şeyleri sorduğunuzda bir hafta önce neleri kontrol ettiklerinden daha yararlıdır.

BTW, "Yapıyı kır" dediğin şeyi bilmiyorum. Nispeten küçük artışlarla çalışma eğilimindeyim, böylece bazı özellikleri bozsa bile derlenebilir bir durumda kalıyorum. Ve testleri bir araya getirerek çalışmanın yapılması gereken bir şeyi bozmadığını biliyorum. Yine, bir sorunu erken tespit edildiğinde düzeltmek daha kolaydır.

Başka biri yapıyı bozduğunda "taciz etmede" ne kadar iyi olduğunuza bağlıdır. Bir yandan, mümkün olduğunca küçük parçalar halinde güncellemek istiyorsunuz. Şahsen, neredeyse her güncelleme bulunduğumda güncelleme yaparım. Öte yandan, yapı bozulursa ve bir başkasının düzeltmesi bir gün sürecekse, bu arada yeni özelliğiniz üzerinde çalışmaya devam etmek istersiniz.

Bir güncelleme yapıldıktan sonra yedeklenmesi çok zor olan sürüm kontrol sistemleriyle çalıştım. Bunlarda, sadece check-in yapmadan hemen önce güncelleme eğilimindeyim. Daha iyi sürüm kontrol sistemleri ile günde birkaç kez güncelleme yapmamak için çok az neden var.