Git Stratejileri

Git Stratejileri

Yazılımcılar olarak projelerimizi yönetmek ve versiyonlamak için Git gibi versiyon kontrol sistemlerini kullanmaya her zaman ihtiyaç duyarız. Ancak çoğu zaman git kullanırken bir de geliştirme stratejisine sahip olmamız gerekir. Bu strateji, bizim geliştirme sürecinden beklentilerimize göre değişmekle birlikte temelde 3'e ayrılır.

Bunlar;

  1. Gitflow

  2. Feature Based Development

  3. Trunk Based Development

Aşağıda bu üç stratejinin detaylarını bulabilirsiniz.

Gitflow

Gitflow, ilk kez 2010 yılında yayınlanan bir blog gönderisinde Vincent Driessen tarafından popüler hale getirilen bir branching stratejisidir. develop ve master olmak üzere iki ana branche sahip olma fikrine dayanmaktadır. master branch productiona hazır kodu temsil ederken, develop branchi devam eden geliştirmeler için kullanılır.

Gitflow, geliştirme sürecini kolaylaştırmak için birkaç ek branch sunar:

Feature Branch: Yeni featurelar geliştirmek için kullanılır. Bir feature tamamlandığında, develop branchine merge edilir.

Release Branch: Yeni bir release deploy etmek için kullanılır. Release hazır olduğunda, hem develop hem de master branchine merge edilir.

Hotfix Branch: Productionda oluşan hataları hızlı bir şekilde fixlemek için kullanılır. Bu branch master branchten çıkılır ve fix tamamlandığında hem develop hem de master branchine merge edilir.

Gitflowun en önemli faydalarından biri, productiona hazır kod ile halen geliştirilmekte olan kod arasında açık bir ayrım sağlamasıdır. Bu, özellikle farklı featurelar üzerinde çalışan birden çok ekibin olabileceği daha büyük projelerde büyük faydalar sağlar.

Feature Based Development

Feature based development gitflowa benzeyen ancak birkaç temel farklılığa sahip olan bir branching stratejisidir. Gitflow gibi feature based development da, her feature için ayrı branchler oluşturmayı hedefler. Ancak tamamlanmış featurelar develop branchine merge edilmez, bunun yerine doğrudan master branche merge edilirler.

Bu, master branchin her zaman kodun en son sürümünü, tüm featureları ve hotfixleri içerdiği anlamına gelir. Master branchin her zaman kararlı olduğundan emin olmak için, feature branchler merge edilmeden önce test edilir ve gözden geçirilir.

Feature based developmentin bir avantajı, feature branchlerin master branchte birleştirilmesi için resmi bir production sürecini beklemesi gerekmediğinden, daha hızlı deploymentlara olanak sağlamasıdır. Ancak productiona hazır kod ile hala geliştirilmekte olan kod arasında daha az ayrım olduğu için bu yaklaşım bazı durumlarda daha riskli de olabilir.

Trunk Based Development

Trunk based development, ayrı feature branchlerini tamamen ortadan kaldıran bir branching stratejisidir. Bunun yerine yapılan tüm feature geliştirmeleri düzenli olarak master branche merge edilir.

Bu yaklaşım, master branchinde bulunan kodların her zaman çalışır durumda olduğundan ve yapıyı bozmadıklarından emin olunması gerektiği için geliştiricilerin son derece disiplinli olmalarını gerektirir. Bunu kolaylaştırmak için, trunk based developmentta kodlar master branche merge edilmeden önce sürekli test sürecinden geçmeli ve review edilmelidir.

Trunk based developmentin bir diğer avantajı ise feature branchler oluşturmaya ve dolayısıyla merge etmeye ihtiyaç duyulmadığı için daha hızlı geliştirmeye imkan sağlayabilmesidir. Ayrıca tüm değişiklikler tek bir branchte yapıldığından, kod geçmişini izlemeyi de kolaylaştırır. Ancak yapılacak olan tek bir hata potansiyel olarak tüm kodu bozabileceğinden bu yaklaşım da bazı durumlarda riskli olabilir.


Aslında bakıldığında tüm bu stratejiler belirli bir amaca yönelik hareket etmek üzere kurgulanmıştır ve birinin diğerinden daha iyi olduğunu söylemek bana göre pek de mümkün değil. Bu noktada hangisinin takıma ve projeye daha uygun olduğuna karar verip buna göre bir seçim yapmanın en doğrusu olacağını düşünüyorum.

Umarım faydalı bir içerik olmuştur, bir sonraki yazıda görüşmek üzere...