Git
Chapters ▾ 2nd Edition

5.1 Dağıtık Git - Dağıtık İş Akışları

Artık diğer geliştiricilerle ortak bir proje üzerinde çalışırken kodlarınızı paylaşmak üzere kurulmuş bir uzak Git deposuna sahipsiniz ve yerel bir iş akışında temel Git komutlarına aşina olduğunuz için, Git’in size sunduğu dağıtık iş akışlarını nasıl kullanacağınıza bakacaksınız.

Bu bölümde, dağıtık bir ortamda bir katkı sağlayıcı ve proje yöneticisi olarak Git ile nasıl çalışılacağını göreceksiniz. Yani, bir projeye başarılı bir şekilde kod eklemeyi ve hem siz hem de proje yürütücüsü için sürecin mümkün olduğunca kolay olmasını sağlamayı öğreneceksiniz. Ayrıca birçok geliştiricinin katkıda bulunduğu bir projeyi başarılı bir şekilde sürdürmeyi de öğreneceksiniz.

Dağıtık İş Akışları

Merkezi Sürüm Denetim Sistemleri (CVCS) ile karşılaştırıldığında, Git’in dağıtık yapısı, geliştiricilerin projelerde nasıl işbirliği yapacakları konusunda çok daha esnek olmalarını sağlar. Merkezi sistemlerde, her geliştirici merkezi bir dağıtım göbeğiyle (hub) neredeyse eşit olarak çalışan bir düğümdür (node). Ancak, Git’te her geliştirici potansiyel olarak hem bir düğüm hem de bir göbektir: yani, her geliştirici hem diğer repolara kod katkısında bulunabilir, hem de diğerlerinin çalışmalarını temel alabilecekleri ve katkıda bulunabilecekleri bir açık repoyu yürütebilir. Bu, projeniz ve/veya ekibiniz için geniş bir olası iş akışı yelpazesi sunar, bu esneklikten faydalanabileceğiniz birkaç yaygın paradigmayı ele alacağız. Her tasarımın güçlü yanlarını ve olası zayıflıklarını inceleyeceğiz. Kullanım amacıyla bunlardan tek birini seçebilir veya her birinden özellikleri bazı özellikleri alarak bir karma elde edebilirsiniz.

Merkezi İş Akışları

Merkezi sistemlerde genellikle tek bir işbirliği modeli bulunur: merkezi iş akışı. Merkezi bir dağıtım göbeği veya repo, kodları kabul edebilir ve herkes çalışmalarını onunla eşitler. Geliştiriciler (o göbeğin tüketicileri olan) düğümlerdir ve işlerini bu merkezi konumla eşitlerler.

Merkezi iş akışı.
Görsel 54. Merkezi iş akışı.

Bunun anlamı, iki geliştiricinin göbekten (hub/repo) kopyaladığı ve her ikisinin de değişiklikler yaptığı durumda, değişikliklerini ilk gönderen birinci geliştiricinin bunu herhangi bir sorun yaşamadan yapabileceğidir. İkinci geliştirici değişiklikleri göndermeden önce, birinci geliştiricinin çalışmasını birleştirmelidir. Böylece birinci geliştiricinin değişikliklerini üzerine yazmamış olur. Bu kavram, Subversion (veya herhangi bir başka CVCS) gibi Git’te de geçerlidir ve bu model Git’te mükemmel bir şekilde çalışır.

Şirketiniz veya ekibinizde merkezi iş akışından zaten memnunsanız, Git’i kullanarak bu iş akışını kolayca sürdürebilirsiniz. Tek bir repo kurun ve ekibinizdeki herkese itme erişimi verin. Git kullanıcıların birbirlerinin üstüne yazmasına izin vermez.

Ahmet ve Mehmet’in aynı anda çalışmaya başladıklarını varsayalım. Ahmet değişikliğini tamamlar ve onu sunucuya iter. Sonra Mehmet değişikliklerini iterlemeye çalışır, ancak sunucu bunları reddeder. Ona, ileri alınmayan değişikliklerini iterlemeye çalıştığı ve bunu yapamayacağı söylenir, çünkü önce çekme ve birleştirme yapması gerekmektedir. Bu iş akış modeli, birçok insanın aşina olduğu ve rahat hissettiği bir kavram olduğu için çoğu kişiye çekici gelir.

Bu sadece küçük ekiplerle sınırlı değildir. Git’in dallanma modeliyle, yüzlerce geliştiricinin aynı anda onlarca dal üzerinde başarılı bir şekilde çalışması mümkündür.

Birleşme Yöneticisi İş Akışı

Çünkü Git, birden çok uzak repoya sahip olmanıza izin verir ve her geliştiricinin kendi açık reposuna yazma erişimi ve diğer herkesin okuma erişiminin olduğu bir iş akışına sahip olmanız mümkündür. Bu senaryo genellikle, "resmi" projeyi temsil eden kanonik bir repo içerir. Bu projeye katkıda bulunmak için, projenin kendi açık kopyanızı oluşturur ve değişikliklerinizi ona itersiniz. Daha sonra, ana projenin bakıcısına değişikliklerinizi çekmesi için bir istek gönderebilirsiniz. Proje yürütücüsü daha sonra; reponuzu bir uzak repo olarak ekleyebilir, değişikliklerinizi yerel olarak test edebilir, bunları kendi dalına birleştirebilir ve reposuna geri itebilir. İşlem şu şekilde çalışır:

Süreç şöyle ilerler (bkz Birleşme yöneticisi iş akışı.):

  1. Proje yürütücüsü kendi acık reposuna iter.

  2. Bir katkılayıcı bu repoyu kopyalar ve değişiklikler yapar.

  3. Katkılayıcı bunu kendi açık kopyasına iter.

  4. Katkılayıcı yürütücüye değişiklikleri çekmesi için bir e-posta gönderir.

  5. Yürütücü katkıcının reposunu bir uzak repo olarak ekler ve yerel olarak birleştirir.

  6. Yürütücü birleştirilen değişiklikleri ana repoya iter.

Birleşme yöneticisi iş akışı.
Görsel 55. Birleşme yöneticisi iş akışı.

Bu, GitHub veya GitLab gibi dağıtım-göbeği tabanlı araçlarla çok yaygın bir iş akışıdır. Burada bir projeyi çatallamak (dal açmak) ve değişikliklerinizi herkesin görebilmesi için dalınıza itmek çok kolaydır. Bu yaklaşımın başlıca avantajlarından biri, ana repo yürütücüsünün herhangi bir zamanda değişikliklerinizi alabilmesidir. Katkılayıcılar değişikliklerinin projeye dahil edilmesini beklemek zorunda değillerdir: her taraf kendi hızında çalışabilir.

Diktatör ve Yardımcılar İş Akışı

Bu, çoklu repo iş akışının bir türüdür. Genellikle, Linux çekirdeği gibi, yüzlerce katılımcısı olan büyük projeler tarafından kullanılır. Çeşitli birleşim yöneticileri belirli repo parçalarından sorumludur ve bunlara yardımcılar denir. Tüm yardımcılar, "benevolent dictator" (yardımsever diktatör) olarak bilinen bir birleşim yöneticisine sahiptir. Tüm yardımcıların bu yardımsever diktatörün kendi dizininden referans repoya ittiği kodu çekmesi gereklidir. Süreç şöyle işler (bkz. Yardımsever diktatör iş akışı.):

  1. Normal geliştiriciler tematik dallarda çalışır ve çalışmalarını master üzerine temeller. master dalı yöneticinin ittiği referans reposunun dalıdır.

  2. Yardımcılar, geliştiricilerin konu dallarını kendi master dallarına birleştirir.

  3. Diktatör, yardımcıların master dallarını kendi master dalına birleştirir.

  4. Son olarak, diktatör bu master dalını referans reposuna iter, böylece diğer geliştiriciler bunun üzerine temelleme yapabilir.

Yardımsever diktatör iş akışı.
Görsel 56. Yardımsever diktatör iş akışı.

Bu tür bir iş akışı yaygın değildir, ancak çok büyük projelerde veya yüksek derecede hiyerarşik ortamlarda faydalı olabilir. Proje liderine (diktatöre) projenin büyük kısmını devretmesine ve bunları birleştirmeden önce bir çok noktada geniş kod altkümeleri toplamasına olanak tanır.

İş Akışı Özeti

Bunlar, Git gibi bir dağıtılmış sistemle mümkün olan bazı yaygın olarak kullanılan iş akışlarıdır, ancak gördüğünüz gibi, gerçek dünya iş akışınıza uyacak şekilde birçok değişiklik yapılabilir. Umarım artık sizin için hangi iş akışı karmasının daha uygun olduğunu belirleyebilirsiniz.

Bir sonraki bölümde bir projeye katkıda bulunmanın ana örüntüleri hakkında daha fazla bilgi sahibi olacak ve farklı iş akışları oluşturmak için ana rollerini nasıl gerçekleştireceğiniz hakkında daha belirgin örnekler göreceksiniz.

scroll-to-top