Git için ortak iş akışı (git akışı), her yeni özellik için ayrı bir dalın oluşturulduğu özellik dallarını kullanır. Geliştiriciler bu yalıtılmış dallara yeni işlevler uygular ve ardından değişikliklerini tekrar   veya   dalda birleştirir. main master  Bu iş akışının faydaları açıktır: QA ortamında ayrı bir şube uygun bir şekilde dağıtılabilir ve test edilebilir ve kritik hatalar tespit edilirse   şubeyle birleştirilmez. Aynı dalda sorunlar düzeltilebilir ve kod geliştirilebilir. main  Bu arada ana şube sürekli olarak konuşlandırılabilir durumda kalır ve bu sorunlardan korunur.  Ne yazık ki, bu stratejinin önemli bir dezavantajı var: birleştirme çatışmaları. Bir noktada kaçınılmaz olan uzun ömürlü dallarla bu çatışmaların çözümü çok zor olabilir ve daldan tamamen kurtulmak ve sıfırdan başlamak daha kolay hale gelebilir.  Ayrıca, çok sayıda çatışma olduğunda birleştirme sonucu tahmin edilemeyebilir.  Ancak olası tek strateji bu değildir ve bu makale, yukarıda listelenen dezavantajlar olmadan yeni ürün özelliklerini yönetmenin alternatif bir yolunu ele alacaktır.  Birleştirme Çatışmaları Neden Oluşur?  Git tasarımına göre, birleştirme sırasında dalların aynı dosya satırında farklı içeriğe sahip olması durumunda birleştirme çakışmaları meydana gelir.  Bunu açıklamak için, iki ekibin aynı hizmete yönelik güncelleştirmeleri uyguladığı bir senaryoyu ele alalım. A Takımı kredi kartı desteğini entegre ederken, B Takımı kullanıcı profili sayfasını yeniliyor. Bu özelliklerin birbiriyle hiçbir ilgisi yok gibi görünüyor.  Ancak ödemeyle ilgili kodun daha önce profil sayfası koduyla aynı yerde bulunduğu ortaya çıktı. Böylece her iki ekip de kodlarını ayrı dallara çıkardı ve entegrasyonu yeniden yazdı.  Şimdi soru şu: Diğer takım ortaya çıkan çatışmayı çözmeye çalışırken, değişikliklerini   dalda birleştiren ve sorun kendi tarafında değilmiş gibi davranan ilk kişi kim olacak?  main  Gövde Tabanlı Geliştirme  Birleştirme çatışmalarından tamamen kaçınmak imkansızdır, ancak aşağıdaki iyi bilinen kuralı kullanarak bunların çözülmesini kesinlikle daha kolay hale getirebiliriz:  Bir eylem zor ve korkutucuysa onu daha sık yapın  Git açısından bu, mümkün olduğu kadar sık birleşmemiz gerektiği anlamına gelir (ideal olarak her işlemde). Ve elbette bu durumda çatışmalar daha sık yaşanacaktır, ancak bunları çözmek çok daha kolay olacaktır.  Buna gövde tabanlı geliştirme denir ve değişiklikleri doğrudan   dala itmek ve gereksiz dalları kullanmaktan kaçınmak anlamına gelir. main  Yukarıdaki örnekte, eğer her iki takım da düzenli olarak değişikliklerini   şubeye gönderseydi, aynı dosyayı değiştirmeye çalıştıklarını hemen fark edeceklerdi. main  Dahası, sorunlardan tamamen kaçınabilirlerdi. İkinci takım, ilk takım bu güncellemeleri dikkate alarak dosyayı değiştirdikten sonra değişikliklerini yapmaya başlayacaktı.   Dikkatli bir okuyucu şunu merak edebilir: Her şey kulağa harika geliyor ama testi nasıl yapacağız? Özellik başına dallar, tüm yeni işlevselliğin yayınlanmadan önce ayrı ayrı test edilmesine olanak tanır; değişiklikleri sürekli olarak   şubeye entegre edersek bunun şansı kalmayacaktır. main  Özellik Bayraklarıyla Tanışın  Özellik bayrağı veya özellik geçişi, çalışma zamanında belirli bir özelliğin değiştirilmesine izin veren basit bir dinamik bayraktır. Genel olarak özellik bayrakları, QA mühendisleri, personel, belirli müşteriler vb. gibi belirli kullanıcı grupları için özelliklerin etkinleştirilmesine veya devre dışı bırakılmasına da olanak tanır.   Özellik bayraklarının birkaç ekstra avantajı vardır:  Risksiz dağıtım  Doğrudan üretimde daha güvenilir testler  Gerektiğinde değişiklikleri hızla geri alın.  Özellik bayraklarının kullanılması,   dalda yapılan değişiklikleri daha güvenli hale getirir. Özellik bayrağı kapalıyken değişiklikler kimseyi etkilemez. main  Bu teknik, doğrudan   dalla çalışmaya veya kısa ömürlü dallar oluşturmaya olanak sağlar. Bu nedenle, birleştirme çatışmaları oldukça nadir hale geliyor ve hızla çözülüyor. main  Çözüm  Özetle, özellik bayraklarıyla birleştirilmiş gövde tabanlı geliştirme, özellik dallarındaki çelişkili değişikliklerin yol açtığı birçok sorunun önlenmesine yardımcı olan mükemmel bir tekniktir.  Ancak her zaman olduğu gibi herkese uyacak tek bir kalıp yoktur. Aynı veri deposunda çalışan az sayıda ekip için işe yarar; bu sayının arttırılması genellikle bazı ayarlamalar gerektirir.  Üstelik her iki yöntemi de kullanmak her zaman mümkündür: belirli duruma ve göreve bağlı olarak özellik dallarını veya özellik bayraklarını kullanın.

Read My Stories

Bu ses hikayenin orijinal dilinde üretilmiştir!

Özellik Dalları Gidilecek Nihai Yol mu?

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

Sulara Yelken Açmak: Data Lakes ile Üretim Sınıfında RAG Uygulamaları Geliştirme

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

Forumlardan Feed'lere: Sosyal Medya Algoritmaları Dijital Etkileşimi Nasıl Şekillendiriyor

Sulara Yelken Açmak: Data Lakes ile Üretim Sınıfında RAG Uygulamaları Geliştirme

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

Forumlardan Feed'lere: Sosyal Medya Algoritmaları Dijital Etkileşimi Nasıl Şekillendiriyor

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps