Git Branch Stratejileri: Kurumsal Ekiplerde Doğru Rebase Yönetimi

Git kullanan ekiplerin büyük bölümü branch açmayı bilir, ancak branch geçmişini güvenli biçimde yönetmek çok daha farklı bir disiplindir. Özellikle aynı repository üzerinde onlarca geliştirici çalıştığında küçük bir rebase kararı bile code review akışını, CI sonuçlarını, audit kayıtlarını ve başka geliştiricilerin commitlerini etkileyebilir. On yıllık yazılım geliştirme ve ekip süreçleri deneyimimde gördüğüm en yaygın hata, rebase komutunun yalnızca history temizleme aracı olarak değerlendirilmesidir. Oysa Git Branch Stratejileri: Kurumsal Ekiplerde Doğru Rebase Yönetimi konusu branch yaşam süresinden protected branch kurallarına, force push politikasından merge queue kullanımına kadar geniş bir çalışma alanını kapsar. Bu rehberde kurumsal yazılım ekiplerinde Git branch ve rebase stratejisi nasıl belirlenir, Git rebase ne zaman kullanılmalı ve shared branch neden rebase edilmemeli, Git rebase merge ve squash merge yöntemleri arasındaki farklar ve GitFlow trunk-based development ve GitHub Flow branch stratejileri karşılaştırması gibi soruları uygulamaya dönük biçimde ele alacağız.

Git Branch Stratejisi Nedir?

Git branch stratejisi, bir ekibin kod değişikliklerini hangi branch üzerinde geliştireceğini, nasıl review edeceğini ve ana geliştirme hattına hangi kurallarla dahil edeceğini belirleyen çalışma modelidir. İyi bir strateji yalnızca branch isimlerini tanımlamaz. Branch ömrü, CI zorunlulukları, merge yöntemi ve history değişikliği gibi kararları da kapsar. Bir ekip için uygun olan model başka bir ekipte gereksiz işlem yükü yaratabilir. Bu nedenle branch strategy release modeli, takım yapısı ve otomasyon seviyesiyle birlikte değerlendirilmelidir.

Branch Kullanmanın Temel Amacı

Branch kullanmanın temel amacı geliştiricinin belirli bir değişiklik üzerinde ana geliştirme hattını doğrudan etkilemeden çalışabilmesidir. Branch, feature geliştirme, bug düzeltme veya release hazırlığı için geçici bir çalışma alanı sunar. Bu alan kod review sürecini de kolaylaştırır. Ancak branch çok uzun yaşarsa main ile fark büyür ve conflict olasılığı artar. Bu nedenle branch kullanımı izolasyon sağlarken entegrasyonu geciktirmeyecek biçimde planlanmalıdır.

Branch Stratejisi Neden Kurumsal Ekiplerde Önemlidir?

Kurumsal ekiplerde aynı repository üzerinde farklı sorumluluklara sahip birçok kişi çalışabilir. Branch stratejisi olmadığında herkes farklı merge ve rebase alışkanlığı geliştirebilir. Bu durum commit history, CI davranışı ve release izlenebilirliği açısından sorun çıkarır. Ortak politika geliştiricinin hangi durumda hangi işlemi yapabileceğini açık hale getirir. Böylece workflow kişisel tercihler yerine takım tarafından kabul edilmiş kurallarla ilerler.

Branch Strategy ile Merge Strategy Arasındaki Fark

Branch strategy branch'lerin nereden açılacağını, ne kadar yaşayacağını ve hangi amaçla kullanılacağını belirler. Merge strategy ise değişikliğin hedef branch'e nasıl entegre edileceğini tanımlar. Merge commit, squash merge ve rebase merge bu ikinci karar grubuna girer. Bir ekip GitHub Flow kullanırken squash merge tercih edebilir. Aynı branch strategy farklı merge yöntemleriyle uygulanabilir.

Rebase Neden Bir Branch Stratejisi Değildir?

Rebase tek başına branch yönetim modeli değildir. Rebase commit serisini farklı bir taban üzerine yeniden uygulayan Git operasyonudur. Bu işlem GitHub Flow veya Trunk-Based Development gibi bir workflow içinde kullanılabilir. Aynı zamanda bazı shared branch'lerde tamamen yasaklanabilir. Dolayısıyla rebase stratejinin tamamı değil, strateji içindeki kontrollü araçlardan biridir.

Git Workflow'un Dört Temel Kararı

Git workflow tasarlarken dört temel karar netleştirilmelidir. İlk olarak branch'in hangi tabandan açıldığı belirlenir. İkinci olarak branch'in beklenen yaşam süresi tanımlanır. Üçüncü karar code review ve CI sürecidir. Son karar ise değişikliğin main veya ilgili hedef branch'e hangi yöntemle entegre edileceğidir.

Nereden Branch Açılır?

Feature branch çoğu modern workflow'da güncel main üzerinden açılır. GitFlow kullanan ekiplerde feature branch çoğunlukla develop üzerinden başlayabilir. Hotfix ise production durumunu temsil eden branch veya tag'den türetilebilir. Yanlış tabandan açılan branch gereksiz commitleri PR içine taşıyabilir. Bu nedenle branch source repository politikasında açıkça tanımlanmalıdır.

Branch Ne Kadar Yaşar?

Branch ömrü conflict riski üzerinde doğrudan etkilidir. Birkaç saat veya birkaç gün yaşayan branch main'deki değişikliklerden fazla uzaklaşmaz. Haftalarca yaşayan feature branch ise entegrasyon maliyetini büyütür. Büyük işlerin tek uzun branch yerine daha küçük teslimatlara ayrılması faydalıdır. Branch age ekip tarafından takip edilebilen önemli bir süreç metriğidir.

Nasıl Review Edilir?

Branch değişiklikleri pull request veya merge request üzerinden review edilebilir. Küçük PR'lar reviewer'ın değişikliği daha kolay anlamasını sağlar. Required reviewer veya CODEOWNERS kuralları kritik dosyalar için uygulanabilir. Review sırasında history büyük ölçüde yeniden yazılırsa reviewer context'i kaybolabilir. Bu nedenle rebase politikası code review politikasıyla birlikte tasarlanmalıdır.

Main'e Nasıl Entegre Edilir?

Main'e entegrasyon için merge commit, squash merge veya rebase merge kullanılabilir. Her yöntemin history görünümü farklıdır. Squash merge bir PR'ı tek commit halinde main'e taşır. Rebase merge bireysel commitleri linear history içinde yeniden oluşturur. Merge commit ise branch topolojisini daha açık biçimde korur.

Kurumsal Ekiplerde En Yaygın Git Branch Stratejileri

Kurumsal ekiplerde tek bir doğru branch modeli yoktur. GitHub Flow basit ve hızlı teslimat yapan ekiplerde yaygınken GitFlow daha belirgin release hatları kullanan projelerde tercih edilebilir. Trunk-Based Development sürekli entegrasyon ve kısa ömürlü branch yaklaşımına dayanır. Release Flow ve GitLab Flow gibi modeller farklı release veya environment ihtiyaçlarına cevap verebilir. Seçim yapılırken branch sayısından çok teslimat modeli ve ekip davranışı dikkate alınmalıdır.

GitHub Flow

GitHub Flow genellikle main ve kısa ömürlü feature branch'ler üzerine kuruludur. Geliştirici güncel main üzerinden branch açar ve değişikliklerini push eder. Ardından pull request açılır, CI çalışır ve review alınır. Değişiklik onaylandığında main'e entegre edilir. Bu model sık deployment yapan ekipler için anlaşılır bir yapı sunar.

GitFlow

GitFlow main, develop, feature, release ve hotfix gibi farklı branch rollerine dayanır. Release hazırlığı develop branch'ten ayrılabilir. Production hotfix akışı ana geliştirmeden ayrı yönetilebilir. Model daha fazla branch coordination gerektirir. Çok sık deployment yapan ekiplerde bu ek branch yapısı gereğinden fazla süreç oluşturabilir.

Trunk-Based Development

Trunk-Based Development tek ana geliştirme hattına sık entegrasyonu teşvik eder. Feature branch kullanılıyorsa çok kısa ömürlü tutulur. Büyük geliştirmeler feature flag veya branch by abstraction gibi tekniklerle parçalara ayrılır. Ana hedef branch divergence süresini minimuma indirmektir. Güçlü CI ve otomatik test altyapısı bu yaklaşım için büyük önem taşır.

GitLab Flow

GitLab Flow feature branch yaklaşımını release veya environment ihtiyacıyla birleştirebilir. Main geliştirme hattı korunurken production branch veya release branch kullanılabilir. Ekip deployment modeline göre akışı uyarlayabilir. Ancak fazla environment branch kullanımı drift riskini artırabilir. Aynı artifact'i ortamlar arasında promote etmek çoğu durumda daha güvenli bir release modeli sunar.

Release Flow

Release Flow ana geliştirme hattına hızlı entegrasyon ile desteklenen release branch'leri bir arada kullanabilir. Yeni geliştirmeler main üzerinde ilerler. Belirli bir sürüm desteklenmeye devam edecekse release branch açılır. Fix'ler gerektiğinde ilgili sürüme backport edilir. Bu yaklaşım birden fazla desteklenen sürümü yöneten ekiplerde faydalıdır.

Forking Workflow

Forking Workflow özellikle açık kaynak projelerde sık görülür. Contributor ana repository üzerinde doğrudan branch açmak yerine kendi fork'unda çalışır. Değişiklik upstream repository'ye pull request olarak gönderilir. Bu yapı write permission gerektirmeden katkı yapılmasını sağlar. Rebase çoğu zaman contributor branch'ini upstream main ile güncellemek için kullanılır.

Branch-per-Environment

Branch-per-Environment yaklaşımında dev, staging ve production gibi branch'ler ortamları temsil eder. İlk bakışta anlaşılır görünse de aynı kodun ortamlar arasında merge edilirken değişebilmesi önemli risk yaratır. Environment branch'leri zamanla birbirinden uzaklaşabilir. Build artifact ile Git commit arasındaki bağlantı da zorlaşabilir. Daha güvenli yaklaşım çoğu zaman aynı build artifact'ini ortamlar arasında promote etmektir.

GitHub Flow Nasıl Çalışır?

GitHub Flow basit branch modeliyle hızlı entegrasyonu hedefler. Main her zaman deploy edilebilir durumda tutulmaya çalışılır. Feature branch güncel main üzerinden açılır ve mümkün olduğunca kısa yaşar. Pull request code review ve CI için ana çalışma alanını oluşturur. Rebase gerekiyorsa çoğunlukla kişisel feature branch üzerinde kontrollü biçimde uygulanır.

Main Branch

Main branch projenin temel entegrasyon hattıdır. Direct push çoğu kurumsal repository'de kapatılmalıdır. Değişiklikler pull request üzerinden gelmelidir. Required CI ve review kontrolleri main'i korur. Force push varsayılan olarak tamamen kapalı tutulmalıdır.

Short-Lived Feature Branch

Feature branch tek bir küçük değişikliği temsil etmelidir. Branch birkaç gün içinde tamamlanabilecek ölçüde dar tutulursa conflict azalır. Büyük feature'lar feature flag ile küçük parçalara ayrılabilir. Branch main'den uzun süre uzaklaşmamalıdır. Kısa branch ömrü rebase ihtiyacını da azaltır.

Pull Request

Pull request değişikliğin review edilebilir bir paket halinde sunulmasını sağlar. Açıklamada değişikliğin amacı ve test yöntemi belirtilmelidir. Büyük PR'lar reviewer'ın bağlamı korumasını zorlaştırır. Küçük ve odaklı PR'lar daha hızlı geri bildirim üretir. PR açıldıktan sonra history rewrite yapılacaksa reviewer bilgilendirilmelidir.

CI ve Code Review

Pull request açıldığında unit test, integration test, lint ve güvenlik kontrolleri otomatik çalıştırılabilir. Required status checks geçmeden merge engellenebilir. Review en az bir yetkili geliştirici tarafından yapılabilir. Kritik alanlar için CODEOWNERS uygulanabilir. Rebase HEAD SHA'yı değiştirdiğinde CI yeniden çalışmalıdır.

Production Deployment

Main'e merge edilen commit veya üretilen artifact production deployment için kaynak olabilir. Build ile commit SHA arasında net ilişki kurulmalıdır. Aynı artifact'in staging ve production'a taşınması izlenebilirliği artırır. Deployment kaydı hangi commitin canlıya çıktığını göstermelidir. History sonradan değiştirilmeyecek şekilde korunmalıdır.

Rebase GitHub Flow İçinde Nerede Kullanılmalı?

Rebase en güvenli biçimde kişisel feature branch'i güncel main üzerine taşımak için kullanılabilir. Branch başka geliştiriciler tarafından kullanılmıyorsa history rewrite riski sınırlıdır. PR öncesi commit cleanup için interactive rebase de uygulanabilir. Review başladıktan sonra büyük rewrite daha dikkatli yapılmalıdır. Main veya shared branch üzerinde rebase uygulanmamalıdır.

GitFlow Nasıl Çalışır?

GitFlow birden fazla uzun ömürlü ve kısa ömürlü branch tipini birlikte kullanır. Main production durumunu temsil ederken develop sonraki geliştirme hattını taşıyabilir. Feature branch'ler develop üzerinden açılır. Release branch yeni sürüm hazırlığı için, hotfix branch ise production düzeltmeleri için kullanılır. Bu yapı rebase politikasını branch rolüne göre ayrı ayrı tanımlamayı gerektirir.

main

Main production geçmişini temsil eden kritik branch'tir. History rewrite burada yüksek risk taşır. Direct ve force push kapalı tutulmalıdır. Release commitleri veya tag'leri bu branch üzerinde bulunabilir. Audit ve rollback açısından history'nin değişmez kalması değerlidir.

develop

Develop sonraki release için entegrasyon branch'i olarak kullanılır. Birden fazla geliştiricinin commit'i burada birleşebilir. Shared olduğu için rebase yapılması uygun değildir. Feature branch'ler develop üzerine rebase edilebilir, ancak develop'un kendisi yeniden yazılmamalıdır. CI ve review kuralları develop için de uygulanmalıdır.

feature/

Feature branch belirli geliştirme için oluşturulur. Tek geliştirici kullanıyorsa kişisel history üzerinde rebase uygulanabilir. Birden fazla kişi branch'i kullanmaya başladığında shared kabul edilmelidir. Shared feature branch history rewrite edilmemelidir. Branch tamamlandığında develop hattına repository politikasına göre entegre edilir.

release/

Release branch belirli bir sürümün hazırlık ve stabilizasyon sürecini taşıyabilir. Buraya test fixleri veya version değişiklikleri gelebilir. Birden fazla ekip bu branch üzerine çalışıyorsa public history oluşur. Rebase bu history'yi değiştirerek audit ve coordination sorunları çıkarabilir. Merge veya cherry-pick çoğu release senaryosunda daha güvenli olabilir.

hotfix/

Hotfix production'daki acil problemi düzeltmek için açılır. Branch production state veya main üzerinden türetilmelidir. Değişiklik küçük ve kontrollü tutulmalıdır. Fix production hattına girdikten sonra development hattına geri taşınmalıdır. Rebase politikası hotfix'in shared olup olmamasına göre belirlenebilir.

GitFlow'da Hangi Branch'ler Uzun Ömürlüdür?

Main ve develop GitFlow modelinde uzun ömürlü branch'lerdir. Release veya hotfix branch'ler geçici olsa da birden fazla geliştirici tarafından kullanılabilir. Feature branch'ler daha kısa ömürlü olmalıdır. Uzun ömürlü shared branch'lerde history rewrite güvenli değildir. Rebase yalnızca kişisel değişiklikleri hedef branch'in güncel hali üzerine taşımak için düşünülmelidir.

GitFlow'da Rebase Kullanmanın Riskleri

GitFlow'da fazla branch olması rebase hedefinin yanlış seçilmesi riskini artırır. Develop veya release history'sini yeniden yazmak birçok kişinin local branch'ini bozabilir. Commit SHA değişikliği release kayıtlarıyla uyumsuzluk oluşturabilir. Shared branch üzerinde force push ayrıca çalışma kaybına yol açabilir. Bu nedenle GitFlow kullanan ekiplerde branch bazlı açık rebase politikası önemlidir.

Trunk-Based Development Nasıl Çalışır?

Trunk-Based Development geliştiricilerin ana geliştirme hattına çok sık entegrasyon yapmasını hedefler. Değişiklikler küçük olduğu için conflict riski azalır. Feature branch kullanılıyorsa birkaç saat veya birkaç gün içinde main'e dönmesi beklenir. Uzun süre saklanan feature branch yerine feature flag ve backward-compatible değişiklikler kullanılır. Bu modelde rebase daha az dramatik hale gelir çünkü branch divergence zaten küçüktür.

Tek Ana Branch Yaklaşımı

Trunk çoğu zaman main branch ile temsil edilir. Bu branch sürekli geliştirmenin merkezi noktasıdır. Her değişiklik hızlı biçimde buraya yaklaşır. Uzun ömürlü develop branch bulunmayabilir. Ana branch güçlü CI ve branch protection ile korunur.

Çok Kısa Ömürlü Feature Branch'ler

Feature branch birkaç saat veya birkaç gün içinde merge edilmelidir. Uzun branch büyüyen conflict riskinin işaretidir. Büyük feature küçük entegrasyon parçalarına bölünür. Feature flag henüz tamamlanmamış davranışı kullanıcıdan gizleyebilir. Kısa branch rebase ihtiyacını önemli ölçüde azaltır.

Sürekli Entegrasyon

Geliştiriciler değişikliklerini sık biçimde main'e entegre eder. Bu nedenle CI hızlı ve güvenilir olmalıdır. Her pull request testlerden geçer. Main bozulduğunda ekip hızlı müdahale eder. Entegrasyon problemi haftalar sonra değil aynı gün görülür.

Feature Flags

Feature flag tamamlanmamış geliştirmeyi codebase içinde kapalı tutmayı sağlar. Böylece uzun feature branch ihtiyacı azalır. Flag lifecycle yönetilmeli ve artık gerekmeyen flag kaldırılmalıdır. Flag testleri açık ve kapalı davranışı kapsamalıdır. Production'da kill switch olarak da kullanılabilir.

Küçük Pull Request'ler

Küçük PR daha hızlı review edilir. Conflict çözümü kolaylaşır. CI sonucu daha hızlı anlamlandırılır. Reviewer tek bir değişiklik amacına odaklanabilir. Bu yaklaşım branch ömrünü de doğal olarak kısaltır.

Trunk-Based Development'ta Rebase'in Rolü

Rebase kısa feature branch'i en güncel main üzerine taşımak için kullanılabilir. Branch birkaç saatlikse conflict genellikle küçüktür. Main history'si yine rebase edilmemelidir. Merge queue kullanan ekiplerde geliştiricinin sürekli manuel rebase yapma ihtiyacı da azalabilir. Rebase burada workflow'un merkezi değil yardımcı aracıdır.

GitFlow mu Trunk-Based Development mı?

GitFlow ile Trunk-Based Development seçimi takımın release ritmi ve operasyon şekliyle yakından ilgilidir. Çok sık deployment yapan ve güçlü otomasyona sahip ekipler trunk modelinden daha fazla fayda görebilir. Uzun süre desteklenen sürümler veya ayrı release hazırlıkları bulunan ürünlerde release branch yapısı gerekli olabilir. Takım büyüklüğü tek başına karar vermek için yeterli değildir. CI/CD olgunluğu, test otomasyonu ve audit gereksinimleri birlikte değerlendirilmelidir.

Release Sıklığı

Günde birçok deployment yapan ekiplerde uzun release branch süreçleri yavaşlatıcı olabilir. Trunk yaklaşımı küçük değişiklikleri sürekli taşımayı kolaylaştırır. Aylık veya dönemsel release yapan ürünlerde ayrı stabilizasyon hattı gerekebilir. Release sıklığı branch yaşam süresini etkiler. Seçilen model gerçek teslimat pratiğiyle uyumlu olmalıdır.

Takım Büyüklüğü

Büyük takım daha fazla commit ve conflict ihtimali anlamına gelir. Ancak bu otomatik olarak GitFlow gerektirmez. Aksine kısa branch ve merge queue büyük ekiplerde entegrasyonu kolaylaştırabilir. Ownership ve CODEOWNERS gibi kurallar önem kazanır. Branch strategy ekip boyutuyla birlikte repository yapısını da dikkate almalıdır.

CI/CD Olgunluğu

Trunk yaklaşımı güvenilir CI olmadan riskli hale gelebilir. Main'e sık entegrasyon yapıldığı için testlerin hızlı feedback vermesi gerekir. GitFlow zayıf CI sorununu çözmez, yalnızca entegrasyonu geciktirebilir. Otomasyon ne kadar güçlü ise kısa branch modeli o kadar rahat uygulanabilir. Pipeline süresi ve reliability bu nedenle önemli karar verileridir.

Test Otomasyonu

Otomatik testler main'in deploy edilebilir durumda tutulmasına yardımcı olur. Unit, integration ve security testleri pull request aşamasında çalışabilir. Manuel regresyona ağır bağımlılık trunk akışını yavaşlatır. GitFlow kullanan ekipler de güçlü test otomasyonuna ihtiyaç duyar. Branch modeli test eksikliğinin yerine geçmez.

Feature Flag Kullanımı

Feature flag büyük geliştirmeleri küçük parçalara ayırmayı sağlar. Bu yetenek trunk modelini kolaylaştırır. Flag olmayan projelerde tamamlanmamış feature'ı main'e taşımak daha zor olabilir. Flag yönetimi yeni operasyon yükü getirir. Bu nedenle flag lifecycle ve cleanup süreci tanımlanmalıdır.

Desteklenen Eski Sürümler

Birden fazla eski sürüm destekleniyorsa release branch'ler gerekli olabilir. Security fix'in birkaç sürüme backport edilmesi gerekebilir. Trunk yine yeni geliştirme hattı olarak kullanılabilir. Eski sürümlere cherry-pick veya kontrollü merge yapılabilir. Branch strategy ürünün support policy'siyle birlikte tasarlanmalıdır.

Regülasyon ve Audit Gereksinimleri

Bazı ekiplerde hangi değişikliğin hangi approval ile production'a çıktığı açıkça izlenmelidir. Immutable release history bu durumda değerlidir. Force push ve history rewrite daha sıkı sınırlandırılabilir. Signed commit ve build provenance gereksinimleri eklenebilir. Branch modelinin audit izini koruması gerekir.

Karar Matrisi

Sık release, güçlü CI, kısa PR ve feature flag desteği trunk yaklaşımını güçlendirir. Belirgin release dönemleri ve uzun süre desteklenen sürümler release branch ihtiyacını artırır. Çok sayıda shared branch rebase riskini büyütür. Takım branch strategy kararını yıllarca değişmeyecek bir kural gibi görmemelidir. Ölçülen metrikler değiştikçe workflow da güncellenebilir.

Git Rebase Nedir?

Git rebase bir commit serisinin tabanını değiştirerek commitleri yeni base üzerine yeniden uygular. Bu işlem branch'i güncel main üzerine taşımak için kullanılabilir. Rebase sonrasında commit içerikleri benzer görünse bile commit SHA değerleri değişir. Çünkü Git açısından yeni parent bilgisiyle yeni commitler oluşur. Bu nedenle rebase private history üzerinde güvenli, public history üzerinde ise dikkat gerektiren bir işlemdir.

Rebase Nasıl Çalışır?

Git önce current branch üzerindeki farklı commitleri belirler. Ardından branch'i hedef base noktasına taşır. Commitlerin değişiklikleri sırayla yeni base üzerine uygulanır. Conflict oluşursa süreç durur ve çözüm bekler. Tamamlandığında history farklı commit SHA'larla yeniden oluşmuş olur.

Commit'lerin Yeniden Uygulanması

Rebase var olan commit nesnelerini fiziksel olarak başka yere taşımaz. Aynı patch'leri yeni parent commit üzerine tekrar uygular. Parent değiştiği için commit içeriği aynı olsa bile yeni commit oluşur. Bu ayrıntı public history riskini anlamak açısından önemlidir. Shared branch'teki kişiler eski ve yeni commit serisini farklı history olarak görür.

Commit SHA Neden Değişir?

Git commit kimliği commit içeriği yanında parent ve metadata bilgisine de bağlıdır. Rebase parent zincirini değiştirir. Bu nedenle SHA yeniden hesaplanır. Eski commit ve yeni commit Git açısından aynı nesne değildir. CI, deployment veya approval sistemi SHA kullanıyorsa bu değişiklik dikkate alınmalıdır.

Linear History Nasıl Oluşur?

Feature branch güncel main üzerine rebase edildiğinde commitler main'in sonundan devam ediyormuş gibi görünür. Böylece arada merge commit oluşmadan linear history elde edilebilir. Bu görünüm log okumayı kolaylaştırabilir. Ancak branch'in gerçek development topolojisi artık history'de görünmez. Linear history bir araçtır ve tek başına kalite hedefi değildir.

Rebase ile Merge Arasındaki Temel Fark

Merge iki history çizgisini yeni bir merge commit ile birleştirebilir. Rebase ise commitleri farklı base üzerine yeniden oluşturur. Merge geçmişte ne olduğuna daha sadık bir topology korur. Rebase daha linear bir görünüm sağlar. Public history güvenliği açısından merge daha az müdahaleci bir işlemdir.

Git Merge Nasıl Çalışır?

Git merge iki geliştirme hattının history'sini bir araya getirir. Branch'ler birbirinden ayrıldıysa Git ortak ancestor üzerinden değişiklikleri hesaplar. Sonuç çoğu durumda merge commit olabilir. Merge mevcut commitleri yeniden yazmadığı için shared history açısından güvenlidir. Bunun karşılığında commit graph daha dallanmış bir görünüm kazanabilir.

Three-Way Merge

Three-way merge iki branch tipini ve ortak ancestor durumunu karşılaştırır. Git iki tarafta yapılan değişiklikleri birleştirmeye çalışır. Aynı satırlar farklı değiştirilmişse conflict oluşabilir. Kullanıcı conflict'i çözüp merge'i tamamlar. Bu yöntem history'yi yeniden yazmadan entegrasyon sağlar.

Merge Commit

Merge commit iki parent taşıyabilir. Bu commit hangi branch'lerin hangi noktada birleştiğini history üzerinde gösterir. PR seviyesinde review edilen değişiklikler bu commit altında görülebilir. Fazla merge commit log'u yoğunlaştırabilir. Buna rağmen branch topology ve audit context korunur.

Non-Destructive History

Merge var olan commit SHA'larını değiştirmez. Bu nedenle başka geliştiricilerin local history'si bozulmaz. Deployment veya CI kayıtları eski SHA'ları geçerli biçimde tutar. Shared branch için bu özellik önemlidir. History rewrite gerektirmeyen entegrasyon daha güvenli kabul edilir.

Branch Topolojisinin Korunması

Merge graph feature branch'in nerede ayrıldığını ve nerede geri birleştiğini gösterebilir. Bu bilgi bazı ekiplerde audit veya debugging için değerlidir. Linear history isteyen ekiplerde ise fazla görsel gürültü oluşturabilir. Tercih repository politikasına göre belirlenmelidir. Topology'yi korumak veya sadeleştirmek bilinçli bir karardır.

Merge'in Avantaj ve Dezavantajları

Merge'in en büyük avantajı public history'yi değiştirmemesidir. Shared branch işbirliğinde güvenli davranır. Branch topology korunur ve audit izi daha açık olabilir. Dezavantaj olarak yoğun merge commit içeren log okunması zorlaşabilir. Squash veya rebase merge bu problemi farklı trade-off'larla çözebilir.

Merge mi Rebase mi?

Merge mi rebase mi sorusunun tek bir evrensel cevabı yoktur. Private feature branch'i güncel main üzerine taşımak için rebase oldukça kullanışlıdır. Shared veya release history için merge daha güvenli olabilir. Audit, review ve debugging beklentileri kararın önemli parçalarıdır. Git rebase ne zaman kullanılmalı ve shared branch neden rebase edilmemeli sorusunun temel cevabı history ownership sınırında bulunur.

History Traceability

Merge branch topology'yi daha açık biçimde korur. Rebase commitleri yeni base üzerine taşıdığı için gerçek development çizgisi sadeleşir. Audit ekipleri hangi commitin hangi branch'ten geldiğini önemseyebilir. Squash merge ise tüm PR'ı tek committe toplayabilir. Traceability gereksinimi merge yöntemini doğrudan etkiler.

Linear History

Linear history git log ve git bisect kullanımını sadeleştirebilir. Rebase veya squash merge bu görünümü kolaylaştırır. Ancak linear history için geliştiricileri sürekli force push yapmaya zorlamak doğru olmayabilir. Merge queue ve server-side merge yöntemleri daha güvenli alternatifler sunabilir. Görsel sadelik güvenlikten daha yüksek öncelik taşımamalıdır.

Conflict Yönetimi

Merge conflict çoğunlukla entegrasyon sırasında bir kez çözülür. Rebase ise commitleri tek tek uyguladığı için aynı alan için birden fazla conflict görülebilir. Bunun karşılığında rebase conflict'i daha küçük commit bağlamında çözme imkanı sağlayabilir. Çözüm sonrasında testler yeniden çalıştırılmalıdır. Semantic conflict yalnız Git marker'larını kaldırmakla çözülmüş sayılmaz.

Audit İhtiyacı

Audit gerektiren projelerde history rewrite daha sıkı kontrol edilmelidir. Merge commit hangi branch'lerin birleştiğini açıkça gösterebilir. Pull request approval ve build SHA kayıtları korunmalıdır. Rebase sonrası yeni SHA oluştuğu için eski kayıtlarla eşleme gerekebilir. Release branch'lerinde immutable history genellikle daha güvenlidir.

Code Review

Code review başlamadan önce history cleanup rebase ile yapılabilir. Review başladıktan sonra büyük interactive rebase yorum bağlamını bozabilir. Reviewer hangi commitin değiştiğini takip etmekte zorlanabilir. Range-diff bu durumda yardımcı olabilir. Repository stale approval politikasını açıkça belirlemelidir.

Debugging

Temiz commit history regression kaynağını bulmayı kolaylaştırabilir. Ancak aşırı squash ayrıntılı commit sınırlarını kaybettirebilir. Merge commit topology bilgisi bazı incident analizlerinde değerlidir. Rebase edilmiş atomic commit serisi ise iyi bir debugging deneyimi sunabilir. Seçim commit disiplinine bağlıdır.

git bisect

git bisect hatayı oluşturan commit aralığını binary search ile daraltır. Atomic ve build edilebilir commitler bisect deneyimini iyileştirir. Rebase ile commit serisi temizlenebilir. Ancak her commit test edilebilir durumda değilse linear history tek başına yeterli değildir. Squash merge bazen bisect için daha büyük değişiklik paketleri oluşturur.

Kullanım Senaryosuna Göre Karar Matrisi

Kişisel feature branch için rebase genellikle güvenlidir. Shared feature branch için merge veya normal pull daha güvenli olabilir. Main, develop ve release history üzerinde rebase varsayılan olarak yasaklanmalıdır. PR merge yöntemi repository'nin audit ve history beklentisine göre seçilmelidir. Git rebase merge ve squash merge yöntemleri arasındaki farklar bu karar matrisi içinde değerlendirilmelidir.

Squash Merge, Rebase Merge ve Merge Commit Arasındaki Fark

Bu üç yöntem aynı pull request'i main'e farklı history biçimleriyle taşır. Merge commit branch topology'yi korur. Squash merge PR içindeki tüm commitleri tek yeni committe birleştirir. Rebase merge commitleri sırayla main üzerine yeniden yazar. Hangi yöntemin uygun olduğu commit kalitesi, audit ihtiyacı ve ekip alışkanlığına bağlıdır.

Merge Commit

Merge commit ayrı branch'in varlığını history üzerinde görünür tutar. PR içindeki individual commitler korunur. Merge commit ayrıca entegrasyon noktasını açıkça gösterir. Log daha dallanmış olabilir. Shared history açısından destructive değildir.

Squash and Merge

Squash merge PR içindeki commitleri tek commit haline getirir. WIP ve fix typo gibi commitler main history'ye taşınmaz. PR tek business değişikliği temsil ediyorsa oldukça temiz sonuç verir. Buna karşılık review sırasında anlamlı hazırlanmış atomic commitler kaybolur. Revert işlemi çoğu zaman tek commit üzerinden kolaylaşır.

Rebase and Merge

Rebase merge PR commitlerini main'in güncel ucuna yeniden uygular. Merge commit oluşmaz. Individual commit sınırları korunabilir. Commit SHA'ları yeni history nedeniyle değişebilir. Repository policy signed commits veya approvals kullanıyorsa server davranışı ayrıca kontrol edilmelidir.

Her PR İçin Tek Commit Yaklaşımı

Her PR'ın tek business değişikliği temsil etmesi squash merge ile uyumludur. Main history feature bazında sade görünür. WIP history kişisel branch'te kalır. Revert genellikle tek commit üzerinden yapılabilir. Ancak çok büyük PR tek committe toplanırsa debugging değeri azalabilir.

Bireysel Commit'leri Koruma Yaklaşımı

Atomic ve anlamlı commitler korunacaksa rebase merge veya merge commit tercih edilebilir. Her commit kendi mantıksal değişikliğini temsil etmelidir. Build edilebilir commit serisi git bisect için değerlidir. Fixup commitler PR öncesinde temizlenebilir. Commit disiplini zayıfsa bu yöntem main history'yi gereksiz ayrıntıyla doldurabilir.

Hangi Strateji Ne Zaman Kullanılmalı?

Küçük feature PR'larında squash merge sade bir history sunar. Denetlenebilir atomic commitler önemliyse rebase merge düşünülebilir. Branch topology veya merge context gerekli olduğunda merge commit uygundur. Repository tek yöntem zorunlu kılabilir. Karar yalnız görsel tercihe değil operasyon ve audit beklentisine dayanmalıdır.

Rebase'in Altın Kuralı: Public History'yi Yeniden Yazmayın

Rebase kullanımındaki en önemli prensip public history'nin yeniden yazılmamasıdır. Bir commit başka bir geliştirici tarafından fetch edilmiş veya üzerine yeni çalışma yapılmışsa artık yalnız size ait değildir. Bu history'yi force push ile değiştirmek diğer kişilerin local branch'lerini sorunlu hale getirir. Recovery mümkün olsa bile gereksiz zaman ve risk oluşturur. Kurumsal politika private ve shared branch ayrımını açık şekilde tanımlamalıdır.

Public Branch Nedir?

Public branch birden fazla kişinin eriştiği ve referans aldığı branch olarak düşünülebilir. Main, develop ve release branch'leri tipik örneklerdir. Bu branch'lerdeki commit SHA'lar CI, deployment ve ticket kayıtlarında kullanılabilir. History rewrite bu bağlantıları bozabilir. Public branch üzerinde force push varsayılan olarak kapalı olmalıdır.

Shared Branch Nedir?

Shared branch iki veya daha fazla geliştiricinin aktif olarak üzerinde çalıştığı branch'tir. Feature branch bile bu durumda shared hale gelebilir. Başka geliştirici branch'ten yeni branch açmış olabilir. Rebase sonrasında herkesin history'si farklılaşır. Bu nedenle shared branch rebase edilmemelidir.

Private Feature Branch Nedir?

Private feature branch yalnızca tek geliştiricinin kullandığı çalışma branch'idir. Remote'a push edilmiş olsa bile başkası üzerine çalışma yapmıyorsa pratikte kişisel kabul edilebilir. Rebase ve interactive cleanup burada daha güvenlidir. Force push gerekiyorsa --force-with-lease kullanılmalıdır. Branch shared hale geldiğinde politika değişmelidir.

Bir Feature Branch Ne Zaman Shared Hale Gelir?

Başka bir geliştirici aynı branch'e commit göndermeye başladığında branch shared olur. Bir kişi branch'ten dependent child branch açtığında da history artık başka çalışmaları etkileyebilir. Pair programming sırasında ortak push kullanılıyorsa shared kabul edilmelidir. Pull request açılması tek başına her zaman shared anlamına gelmez, ancak reviewer context'i devreye girer. Ekip bu eşiği açıkça tanımlamalıdır.

Başkasının Commit Üzerine Çalışması Neden Kritik?

Diğer geliştirici sizin commit SHA'larınızı parent olarak kullanmış olabilir. Rebase bu SHA'ları değiştirir. Karşı taraf pull yaptığında duplicate commit veya conflict görebilir. Local work manuel olarak yeniden bağlanmak zorunda kalabilir. Bu yüzden history ownership rebase kararının temelidir.

Kurumsal Rebase Policy Matrix

Kurumsal rebase policy matrix hangi branch tipinde rebase ve force push yapılabileceğini herkes için net hale getirir. Kural branch adından çok history ownership üzerinden kurulmalıdır. Main ve release gibi public branch'ler en sıkı seviyede korunur. Kişisel feature branch'lerde daha esnek davranılabilir. Bu matris repository ruleset ve branch protection ile teknik olarak uygulanmalıdır.

Lokal Commit'lerde Rebase

Lokal commitler henüz paylaşılmadığı için history üzerinde tek sahibi vardır. Interactive rebase burada güvenli biçimde kullanılabilir. Commit mesajları düzenlenebilir ve fixup commitler birleştirilebilir. Yine de anlamlı atomic commit yapısı korunmalıdır. Rebase sonrası test çalıştırmak iyi bir alışkanlıktır.

Serbest

Paylaşılmamış local history üzerinde rebase genel olarak serbest bırakılabilir. Developer commit serisini review öncesinde düzenleyebilir. Yanlış işlem reflog ile çoğu zaman geri alınabilir. Lokal history'nin temiz olması PR deneyimini iyileştirebilir. Bu serbestlik public branch'e taşınmamalıdır.

Tek Kişilik Feature Branch'te Rebase

Tek geliştiricinin kullandığı feature branch kontrollü rebase için uygundur. Main değiştikçe branch güncellenebilir. Remote history değişeceği için push sırasında force gerekebilir. Normal --force yerine --force-with-lease kullanılmalıdır. PR review başladıysa history değişikliği reviewer'a bildirilmelidir.

Kontrollü Serbest

Rebase yapılabilir ancak branch'in gerçekten tek kişilik olduğu doğrulanmalıdır. Push öncesi remote fetch edilmelidir. Force-with-lease kullanımı zorunlu hale getirilebilir. Rebase sonrası CI yeniden çalışmalıdır. Büyük review sürecinde history rewrite sınırlı tutulmalıdır.

Paylaşılan Feature Branch'te Rebase

Birden fazla geliştiricinin aynı feature branch'e commit gönderdiği durumda rebase yüksek risklidir. Her commit SHA değişebilir. Diğer kişilerin local history'si eski çizgide kalır. Force push çalışma kaybı veya duplicate commit sorunlarına yol açabilir. Bu nedenle merge ile güncelleme daha güvenlidir.

Varsayılan Olarak Yasak

Shared feature branch için rebase varsayılan olarak yasaklanmalıdır. Zorunlu bir history rewrite gerekiyorsa tüm branch kullanıcıları koordine edilmelidir. Backup branch oluşturulabilir. Rewrite sonrasında herkes local branch'ini bilinçli biçimde yeniden senkronize etmelidir. Normal günlük workflow'da buna ihtiyaç duyulmaması hedeflenmelidir.

main Branch'te Rebase

Main repository'nin merkezi history'sidir. CI, deployment ve release kayıtları main commitlerine referans verebilir. History rewrite production traceability açısından sorun çıkarır. Başka geliştiricilerin local clone'ları da eski commit zincirini taşır. Main rebase edilmemelidir.

Yasak

Main üzerinde force push repository ruleset ile kapatılmalıdır. Admin bypass da yalnız olağanüstü kurtarma durumlarıyla sınırlandırılmalıdır. Normal geliştirme hiçbir zaman main history rewrite gerektirmemelidir. Yanlış commit revert ile geri alınabilir. History değişmeden düzeltme yapmak daha güvenlidir.

develop Branch'te Rebase

Develop GitFlow ekiplerinde shared integration branch'idir. Birçok feature buradan açılmış olabilir. History rewrite tüm bu branch'leri etkileyebilir. CI veya release kayıtları develop SHA'larına bağlanabilir. Bu nedenle develop üzerinde rebase uygulanmamalıdır.

Yasak

Develop için direct force push kapalı tutulmalıdır. Feature branch güncellemesi gerekiyorsa feature branch develop üzerine rebase edilebilir. Develop'un kendisi yeniden yazılmamalıdır. Conflict çözümü feature tarafında yapılabilir. Shared history'nin güvenilir kalması önceliklidir.

release Branch'te Rebase

Release branch bir sürüm adayının history'sini temsil edebilir. Test, approval ve deployment kayıtları commit SHA üzerinden tutulabilir. Rebase bu kayıtları geçersiz veya belirsiz hale getirebilir. Branch üzerinde birden fazla ekip çalışabilir. Bu nedenle history rewrite genellikle uygun değildir.

Varsayılan Olarak Yasak

Release branch'te rebase varsayılan olarak kapalı tutulmalıdır. Fix eklemek için merge veya cherry-pick kullanılabilir. Release candidate commitleri immutable tutulabilir. Audit gereksinimi varsa bu kural daha da önemlidir. İstisna yalnız kontrollü ve kayıtlı recovery sürecinde düşünülmelidir.

hotfix Branch'te Rebase

Hotfix branch bazen tek geliştiricinin kısa süreli çalışması olabilir. Bu durumda private history üzerinde rebase teknik olarak mümkündür. Ancak branch birden fazla kişi tarafından kullanılıyorsa shared kabul edilmelidir. Production fix sürecinde history istikrarı çoğu zaman daha değerlidir. Politika release ve incident yönetimiyle uyumlu olmalıdır.

Takım Politikasına Bağlı

Hotfix private ve henüz review edilmemişse sınırlı rebase yapılabilir. Review veya test başladıktan sonra SHA değişikliği koordinasyon gerektirir. Production tag veya deployment ile ilişki kurulmuşsa history rewrite yapılmamalıdır. Branch kısa tutulmalıdır. Fix sonrasında development hattına geri entegrasyon unutulmamalıdır.

Feature Branch Ne Zaman Rebase Edilmeli?

Feature branch rebase zamanlaması branch ömrü ve review durumuyla ilişkilidir. Her main commitinden sonra sürekli rebase yapmak gereksiz işlem yükü oluşturabilir. PR öncesinde güncel main üzerine rebase etmek çoğu küçük branch için yeterlidir. Review sırasında yalnız önemli conflict veya integration ihtiyacı varsa yeniden rebase düşünülebilir. Rebase sonrası yeni HEAD için CI sonuçları tekrar üretilmelidir.

Feature Branch Açıldıktan Sonra

Branch yeni açıldıysa hemen rebase yapmak genellikle anlamlı değildir. Zaten güncel main üzerinden başladıysa ek işlem gerekmez. Geliştirme birkaç gün sürecekse main değişiklikleri takip edilmelidir. Büyük conflict riski oluşuyorsa güncelleme yapılabilir. Ama sürekli history rewrite gereksiz churn yaratabilir.

Pull Request Açılmadan Önce

PR öncesi rebase en uygun zamanlardan biridir. Branch henüz reviewer context'i oluşturmadan temizlenebilir. Main ile conflict varsa geliştirici kendi bağlamında çözebilir. Interactive rebase ile fixup commitler düzenlenebilir. Sonrasında tüm testler çalıştırılmalıdır.

Code Review Sırasında

Review başladıktan sonra küçük rebase yapılabilir ancak reviewer bilgilendirilmelidir. Büyük interactive rewrite eski yorumların konumunu değiştirebilir. Commit SHA'lar değişir ve stale approval oluşabilir. Range-diff review değişikliğini anlatmaya yardımcı olabilir. Repository tekrar approval gerektiriyorsa yeni onay alınmalıdır.

Merge Öncesinde

Main önemli ölçüde değişmişse merge öncesinde son entegrasyon doğrulaması gerekebilir. Manuel rebase yerine merge queue bu işi otomatik yapabilir. Rebase uygulanırsa yeni HEAD üzerinde CI çalışmalıdır. Conflict çözümü reviewer tarafından yeniden incelenebilir. Eski CI sonucuyla merge yapılmamalıdır.

Main Çok Hızlı Değişiyorsa

Yüksek commit frekanslı repository'de sürekli manuel rebase döngüsü oluşabilir. Geliştirici rebase eder, CI çalışır ve bu sırada main tekrar değişebilir. Merge queue bu yarış problemini azaltır. Kısa branch ve küçük PR da divergence'ı düşürür. Süreç otomasyonla çözülmelidir.

Sürekli Rebase Etmenin Dezavantajları

Sık rebase aynı conflictlerin tekrar tekrar çözülmesine yol açabilir. CI gereksiz yere yeniden çalışabilir. Reviewer değişen SHA'ları takip etmekte zorlanabilir. Force push sayısı artar. Branch kısa tutulduğunda sık rebase ihtiyacı zaten azalır.

Feature Branch'i Main Üzerine Güvenli Şekilde Rebase Etmek

Güvenli rebase işlemi güncel remote bilgisini almakla başlar. Geliştirici local main yerine doğrudan origin/main referansını kullanabilir. Conflict oluşursa yalnız marker'ları kaldırmak yerine değişikliklerin anlamı değerlendirilmelidir. Rebase tamamlandıktan sonra test ve history kontrolü yapılmalıdır. Remote branch güncellenirken force-with-lease tercih edilmelidir.

Önce Remote'u Güncellemek

İlk adım git fetch origin ile remote referanslarını güncellemektir. Böylece en güncel main commit'i local repository tarafından bilinir. Eski local main üzerine rebase etmek beklenen entegrasyonu sağlamaz. Fetch history'yi değiştirmeyen güvenli bir işlemdir. Rebase kararı güncel bilgiyle verilmelidir.

origin/main Üzerine Rebase

Feature branch üzerinde git rebase origin/main kullanılabilir. Git feature commitlerini güncel remote main üzerine yeniden uygular. Branch private ise bu yöntem temiz bir entegrasyon sağlar. Shared branch'te aynı komut kullanılmamalıdır. Rebase öncesinde backup branch oluşturmak ek güven sağlayabilir.

Conflict Çözümü

Conflict oluştuğunda her dosyanın iki tarafındaki değişiklik anlaşılmalıdır. Otomatik olarak “ours” veya “theirs” seçmek semantic hata oluşturabilir. Gerekirse ilgili dosyanın owner'ından yardım alınmalıdır. Çözüm tamamlandıktan sonra dosya stage edilir. Ardından rebase devam ettirilir.

Testleri Yeniden Çalıştırmak

Rebase code content aynı görünse bile yeni main ile birlikte davranışı değiştirebilir. Bu nedenle unit ve integration testler yeniden çalışmalıdır. Critical security ve contract testleri de yeni HEAD üzerinde koşmalıdır. Conflict çözülmüşse test önemi daha da artar. CI eski SHA üzerindeki sonucu kullanmamalıdır.

Push Etmeden Önce History'yi Kontrol Etmek

git log veya grafik görünüm kullanılarak commit serisi kontrol edilmelidir. Beklenmeyen commit düşmüş mü incelenmelidir. Duplicate commit bulunmadığı doğrulanmalıdır. Gerekirse git range-diff eski ve yeni patch serisini karşılaştırabilir. Push ancak history beklendiği gibiyse yapılmalıdır.

Remote Branch'i Güncellemek

Rebase SHA'ları değiştirdiği için normal push reddedilebilir. Private feature branch için git push --force-with-lease tercih edilmelidir. Bu seçenek remote branch'in beklenmedik biçimde değişip değişmediğini kontrol eder. Başka commit geldiyse push reddedilebilir. Shared branch için force push kullanılmamalıdır.

git push --force Neden Risklidir?

git push --force remote branch'in mevcut durumunu dikkate almadan local history'yi yazabilir. Bu davranış başka bir geliştiricinin yeni commitini görünmez hale getirebilir. Pull request history ve CI referansları değişebilir. Main veya shared branch üzerinde kullanılması özellikle tehlikelidir. Kurumsal ekiplerde normal force push repository policy ile engellenmelidir.

Remote Commit'lerin Üzerine Yazma

Remote branch sizden sonra ilerlemiş olabilir. Normal force push bu commitleri kontrol etmez. Local branch remote'u kendi durumuna zorlayabilir. Kaybolan commit reflog veya başka clone'lardan kurtarılabilir, ancak bu gereksiz incident yaratır. Force-with-lease daha güvenli koruma sağlar.

Başka Geliştiricinin Çalışmasını Silme

Shared feature branch'te başka geliştirici yeni commit push etmiş olabilir. Siz eski local state ile force push yaparsanız remote pointer geriye gidebilir. Karşı tarafın commit'i branch history'sinden düşer. Veri tamamen yok olmasa bile recovery gerekir. Takım verimliliği ciddi biçimde etkilenir.

Pull Request History'sini Değiştirme

Force push PR commit listesi ve diff bağlamını değiştirebilir. Reviewer'ın önceki yorumları outdated hale gelebilir. Approval eski code state'e ait olabilir. Review sistemi değişiklikleri tam olarak eşleyemeyebilir. Büyük rewrite sonrası yeniden review gerekir.

Audit Trail Problemleri

Commit SHA ticket, build ve approval kayıtlarında kullanılabilir. Force push bu SHA'yı branch history'den çıkarabilir. Eski kayıt hala var olsa da ana history ile ilişki zorlaşır. Regulated ekiplerde bu durum audit sorusu oluşturur. Public history immutable tutulmalıdır.

CI ve Deployment Referanslarının Bozulması

CI sonucu belirli commit SHA üzerinde üretilir. Rebase sonrası branch HEAD farklı SHA'ya sahip olur. Eski pipeline yeni code state'i doğrulamış sayılmaz. Deployment sistemi commit referansı kullanıyorsa eski ve yeni history karışabilir. Rebase sonrası pipeline yeniden çalışmalıdır.

--force-with-lease Nedir ve Neden Kullanılmalı?

--force-with-lease force push yapmadan önce remote branch'in beklenen noktada olup olmadığını kontrol eder. Remote sizden habersiz ilerlemişse push reddedilebilir. Bu nedenle kişisel rebase edilmiş feature branch güncellenirken normal force push'a göre daha güvenlidir. Ancak shared branch rewrite riskini tamamen ortadan kaldırmaz. Kurumsal politika force push gerekiyorsa yalnız bu varyantı izinli kılabilir.

Normal Force Push ile Farkı

Normal force push remote branch'in yeni commitlerini dikkate almadan pointer'ı değiştirebilir. Force-with-lease beklenen remote state'i doğrular. Beklenmeyen değişiklik varsa işlem durur. Bu basit kontrol başka geliştiricinin commitini yanlışlıkla silme riskini azaltır. Yine de doğru branch üzerinde çalıştığınız kontrol edilmelidir.

Remote Branch Kontrolü

Lease mantığı remote tracking bilgisini kullanır. Bu nedenle push öncesi fetch yapmak faydalıdır. Remote state sizin bildiğinizden farklıysa operasyon reddedilebilir. Böylece karar tekrar kullanıcıya döner. Blind overwrite yerine kontrollü history update yapılır.

Beklenmeyen Commit Varsa Push'ın Reddedilmesi

Başka bir geliştirici branch'e commit eklediyse force-with-lease hata verir. Bu sonuç aslında koruyucu davranıştır. Önce remote değişiklik incelenmelidir. Branch shared hale geldiyse rebase politikasından vazgeçmek gerekebilir. Commit kaybından daha iyi seçenek push'ın durmasıdır.

Kurumsal Git Alias Oluşturmak

Ekip normal force push yerine güvenli alias tanımlayabilir. Dokümantasyon ve onboarding içinde aynı komut önerilebilir. Server-side branch protection yine ana güvenlik katmanı olmalıdır. Alias kullanıcı hatasını azaltır fakat yetki kontrolünün yerine geçmez. Tooling ortak politika ile uyumlu hale getirilmelidir.

Force-with-Lease'in de Çözemediği Riskler

Force-with-lease history rewrite gerçeğini değiştirmez. Reviewer context'i yine kaybolabilir. Child branch'ler eski commit SHA'larına dayanıyor olabilir. CI ve approval yeniden çalışmak zorunda kalabilir. Bu nedenle shared history için doğru çözüm force-with-lease değil history rewrite yapmamaktır.

Interactive Rebase Ne Zaman Kullanılmalı?

Interactive rebase commit serisini PR öncesinde düzenlemek için güçlü bir araçtır. Commit mesajları değiştirilebilir, fixup commitler birleştirilebilir ve gereksiz commitler kaldırılabilir. En güvenli kullanım alanı henüz paylaşılmamış veya tek geliştiriciye ait history'dir. Review başladıktan sonra büyük interactive rebase daha fazla koordinasyon gerektirir. Amaç history'yi yapay biçimde kusursuz göstermek değil anlaşılır commit serisi oluşturmaktır.

git rebase -i

git rebase -i seçilen commit aralığını interaktif düzenleme listesiyle açar. Kullanıcı her commit için uygulanacak eylemi seçebilir. Sıra değiştirilebilir veya commitler birleştirilebilir. Yanlış işlem yapılırsa reflog recovery sağlayabilir. İşlem öncesi backup branch faydalıdır.

pick

pick commitin olduğu gibi korunmasını sağlar. Interactive rebase listesindeki varsayılan davranıştır. Commit sırası değiştirildiğinde bile pick kullanılabilir. Seçilen commit yeni parent nedeniyle yeni SHA alabilir. Patch içeriği değişmeden kalabilir.

reword

reword commit içeriğini değiştirmeden mesajını düzenlemeye yarar. Anlamsız veya eksik commit mesajlarını PR öncesinde düzeltmek için kullanışlıdır. Ticket bağlantısı veya Conventional Commits formatı eklenebilir. Commit SHA mesaj değiştiği için yenilenir. Public history üzerinde kullanılmamalıdır.

edit

edit rebase'i ilgili committe durdurur. Geliştirici commit içeriğini değiştirebilir veya commit'i birkaç parçaya bölebilir. Atomic commit oluşturmak için faydalıdır. Değişiklik sonrasında amend yapılabilir. Ardından rebase devam ettirilir.

squash

squash bir commit'i önceki commit ile birleştirir. Commit mesajları üzerinde düzenleme yapılmasına izin verir. WIP veya küçük düzeltme commitlerini mantıksal commit altında toplamak için kullanılabilir. Fazla squash anlamlı development adımlarını gizleyebilir. Amaç okunabilir history olmalıdır.

fixup

fixup squash'a benzer ancak sonraki commit mesajını genellikle korumaz. “fix typo” veya “address review comment” gibi commitleri ana commit içine almak için kullanışlıdır. Autosquash akışıyla birlikte kullanılabilir. Private history için uygundur. Review sırasında kullanıldığında commit SHA'lar değişir.

drop

drop seçilen commit'i history'den çıkarır. Debug veya yanlışlıkla eklenmiş dosya commitleri için kullanılabilir. Committe benzersiz değişiklikler varsa bu değişiklikler de kaybolur. İşlemden önce içerik kontrol edilmelidir. Backup branch recovery için faydalıdır.

Commit Sırasını Değiştirme

Interactive rebase commit sırasını değiştirebilir. Ancak commitler birbirine bağımlıysa yeni sıra conflict veya build hatası yaratabilir. Her commit mümkünse bağımsız ve anlamlı olmalıdır. Sıra değişiminden sonra testler çalıştırılmalıdır. Review edilebilir patch serisi oluşturmak temel hedeftir.

Pull Request Öncesinde Commit History Nasıl Temizlenir?

PR öncesinde commit history'nin anlaşılır hale getirilmesi review kalitesini artırabilir. WIP, debug ve küçük typo commitleri uygun ana commitlerle birleştirilebilir. Commit mesajları business ve teknik amacı açık biçimde anlatmalıdır. Her commit mümkünse kendi başına anlamlı bir değişiklik taşımalıdır. Bu cleanup review başladıktan sonra değil mümkün olduğunca önce yapılmalıdır.

WIP Commit'leri

WIP commit geliştirme sırasında checkpoint olarak faydalıdır. Ancak main history'de kalması her zaman gerekli değildir. PR öncesinde ilgili mantıksal commit ile squash veya fixup yapılabilir. Böylece reviewer daha temiz değişiklik serisi görür. Geliştirici local çalışma özgürlüğünü de kaybetmez.

fix typo Commit'leri

Küçük typo düzeltmeleri ayrı history kaydı olarak düşük değer taşıyabilir. Eğer aynı PR içindeki önceki commitin düzeltmesiyse fixup yapılabilir. Bağımsız production fix ise ayrı commit olarak kalması mantıklı olabilir. Context önemlidir. Her küçük commit otomatik olarak squash edilmemelidir.

Debug Commit'leri

Geçici log veya debug configuration commitleri PR öncesinde kaldırılmalıdır. Interactive rebase drop veya edit ile yardımcı olabilir. Debug dosyası yanlışlıkla main'e taşınmamalıdır. Secret veya credential eklendiyse yalnız history rewrite yeterli değildir, credential da rotate edilmelidir. CI secret scan ek koruma sağlayabilir.

Mantıksal Commit Grupları

Bir commit tek mantıksal değişikliği temsil ettiğinde review kolaylaşır. Refactor ve behavior change mümkünse ayrı commitlerde tutulabilir. Test commit'i ilgili production change ile aynı veya takip eden anlamlı commit olabilir. Commit serisi reviewer'a geliştirme hikayesi anlatmalıdır. Aşırı parçalanmış history de okunabilirliği düşürür.

Commit Mesajlarının Düzeltilmesi

Commit mesajı ne değiştiğini ve gerekirse neden değiştiğini anlatmalıdır. “fix” veya “update” gibi tek kelimelik mesajlar düşük bilgi taşır. Conventional Commits ekip standardı olarak kullanılabilir. Ticket ID gerektiğinde eklenebilir. Reword ile PR öncesinde mesajlar düzenlenebilir.

Review Edilebilir Commit Serisi Oluşturmak

Reviewer ilk committen son commite ilerlediğinde değişikliğin mantığını takip edebilmelidir. Büyük mechanical refactor ile business behavior aynı committe karıştırılmamalıdır. Her commit mümkünse testleri geçmelidir. Bu yapı git bisect için de değerlidir. Commit history review aracına dönüşür.

Review Başladıktan Sonra Interactive Rebase Yapılmalı mı?

Review başladıktan sonra interactive rebase yapılabilir, ancak maliyeti artık yalnız geliştiriciyi etkilemez. Commit SHA'lar değişir ve reviewer'ın daha önce gördüğü patch serisi yeniden şekillenir. Küçük fixup işlemleri bazı ekiplerde kabul edilebilir. Büyük history rewrite reviewer context'ini kaybettirebilir. Böyle durumlarda rebase sonrası değişiklik açıkça bildirilmelidir.

Commit SHA'ların Değişmesi

Interactive rebase her yeniden yazılan commit için yeni SHA üretir. Review sistemi eski ve yeni commitleri farklı görebilir. Commit linkleri değişebilir. CI eski SHA üzerinde tamamlanmış olabilir. Bu yüzden rebase sonrası pipeline yeniden çalışmalıdır.

Reviewer Context'inin Kaybolması

Reviewer commitleri sırayla incelemiş olabilir. History değiştiğinde hangi kodun yeni olduğunu ayırmak zorlaşır. Özellikle büyük PR'larda bu ciddi zaman kaybı yaratır. Range-diff yardımcı olabilir. Yine de en iyi çözüm büyük cleanup işlemini review öncesinde yapmaktır.

Eski Diff Yorumları

Rebase satır konumlarını değiştirebilir. Eski review commentleri outdated olarak işaretlenebilir. Reviewer konuşmanın hangi code state'e ait olduğunu takip etmekte zorlanabilir. Critical yorumların çözüldüğünden emin olunmalıdır. Conversation resolution branch protection kuralı faydalıdır.

Büyük History Rewrite'ın Review Maliyeti

Büyük rewrite reviewer'ın önemli kısmı yeniden okumasını gerektirebilir. Önceki approval artık aynı code state'i temsil etmeyebilir. PR merge süresi uzar. Bu nedenle review başladıktan sonra yalnız gerekli history değişiklikleri yapılmalıdır. Cosmetic cleanup uğruna reviewer zamanını artırmak doğru olmayabilir.

Rebase Sonrası Reviewer'a Bildirim

Geliştirici PR yorumunda rebase yapıldığını açıkça belirtmelidir. Conflict çözümü veya commit sırası değişikliği özetlenebilir. Range-diff sonucu gerekirse paylaşılabilir. Reviewer hangi bölümlerin tekrar incelenmesi gerektiğini bilmelidir. Şeffaf iletişim review güvenini artırır.

Tekrar Approval Gereksinimi

Repository stale approval'ları otomatik düşürebilir. Büyük rebase sonrasında tekrar approval zorunlu olabilir. Security-sensitive repository'lerde bu daha güvenlidir. Sadece base değişti ve patch aynı kaldıysa ekip farklı politika uygulayabilir. Karar otomatik ruleset ile tutarlı hale getirilmelidir.

Rebase Code Review Approval'larını Nasıl Etkiler?

Rebase approval'ın verildiği commit SHA'yı değiştirebilir. Approval teknik olarak eski code state'e ait olduğu için yeniden değerlendirme gerekebilir. Repository platformları stale review dismissal gibi kurallar sunabilir. Kurumsal ekipler bu davranışı branch protection içinde tanımlamalıdır. Özellikle conflict çözümü yapıldıysa yeni approval daha güçlü güven sağlar.

Yeni Commit SHA

Rebase yeni commit nesneleri üretir. Reviewer eski SHA üzerinde approval vermiş olabilir. Yeni HEAD teorik olarak farklı code state'tir. Patch aynı görünse bile base değişmiştir. CI ve approval süreçleri yeni SHA'yı dikkate almalıdır.

Stale Approval

Stale approval artık güncel commit serisini tam temsil etmeyen onaydır. Yeni push sonrası approval otomatik geçersiz kılınabilir. Bu davranış security-sensitive değişikliklerde önemlidir. Küçük documentation PR'larında daha esnek politika uygulanabilir. Repository risk seviyesine göre ayar yapılmalıdır.

Dismiss Stale Reviews

Branch protection yeni commit geldiğinde eski approval'ları düşürebilir. Böylece code review mevcut HEAD üzerinde tekrar doğrulanır. Rebase ve force push yapılan PR'larda bu kural faydalıdır. Reviewer gereksiz tekrar yaşamaması için PR küçük tutulmalıdır. Otomasyon manuel takip ihtiyacını azaltır.

Rebase Yapan Kişinin Approval Yetkisi

Geliştirici kendi rebase ettiği değişikliği tek başına yeniden approve etmemelidir. Separation of duties gereken ekiplerde bu özellikle önemlidir. CODEOWNERS veya required reviewers bağımsız kontrol sağlar. Admin bypass sınırlanmalıdır. Approval gerçek peer review anlamını korumalıdır.

Re-Review Gerektiren Değişiklikler

Conflict resolution, code değişikliği veya commit drop gibi işlemler mutlaka tekrar review gerektirebilir. Salt base update daha düşük riskli olabilir. Repository otomatik olarak tüm push'larda approval düşürebilir. Kritik alanlar için daha katı politika uygulanabilir. Reviewer'a değişikliğin kapsamı açıkça anlatılmalıdır.

Rebase Sonrası CI/CD Pipeline Yeniden Çalışmalı mı?

Evet, rebase sonrası CI/CD pipeline yeni HEAD SHA üzerinde yeniden çalışmalıdır. Eski pipeline farklı commit zincirini doğrulamıştır. Main'in yeni değişiklikleri feature branch ile farklı etkileşime girebilir. Conflict çözümü de yeni bug üretebilir. Required status checks yalnız güncel SHA için geçerli sayılmalıdır.

Eski Commit Üzerindeki CI Sonuçları

CI sonucu belirli commit SHA'ya bağlıdır. Rebase bu SHA'yı değiştirir. Eski test sonucu yeni code state'i otomatik olarak doğrulamaz. Build cache kullanılabilir ama final status yeni HEAD üzerinde üretilmelidir. Audit kaydı da doğru commit ile eşleşmelidir.

Yeni HEAD SHA

Pull request'in merge edilecek son commitini yeni HEAD belirler. Tüm required checks bu SHA üzerinde tamamlanmalıdır. Rebase sonrası pipeline tetiklenmiyorsa configuration düzeltilmelidir. Merge queue kullanılıyorsa queue-generated commit de ayrıca test edilebilir. Deployment yanlış SHA'dan yapılmamalıdır.

Required Status Checks

Branch protection belirli CI job'larını merge için zorunlu kılabilir. Yeni push eski status check'i geçersiz hale getirmelidir. Unit, integration ve policy checks güncel code üzerinde çalışır. Bypass yetkileri sınırlı tutulmalıdır. Merge işlemi yalnız gerekli kontroller tamamlandığında yapılmalıdır.

Integration Test

Rebase özellikle main'deki yeni değişikliklerle entegrasyon davranışını etkileyebilir. Bu nedenle integration testlerin yeniden çalışması önemlidir. Unit testler geçse bile API veya database interaction bozulabilir. Conflict çözümü boundary davranışını değiştirmiş olabilir. Final pipeline entegrasyon güveni sağlar.

Security Scan

Dependency veya code değişikliği rebase sırasında farklı base ile birleşebilir. Security scan güncel dependency tree üzerinde çalışmalıdır. Secret scan ve static security check de yeni committe tekrar yapılabilir. Eski artifact yeniden kullanılacaksa provenance ilişkisi korunmalıdır. Security approval eski SHA'ya bağlı kalmamalıdır.

Merge Öncesi Son Pipeline

Merge öncesi final pipeline mümkün olduğunca target branch'in güncel haliyle çalışmalıdır. Merge queue bu ihtiyacı otomatik yönetebilir. CI başarılı olsa bile main değişmişse entegrasyon yeniden hesaplanabilir. Büyük ekiplerde sürekli manuel rebase yerine queue daha güvenilir olabilir. Final status merge kararının temel girdisidir.

Rebase Conflict Nedir?

Rebase conflict, Git bir commitin değişikliklerini yeni base üzerine otomatik uygulayamadığında oluşur. Aynı satırın iki tarafta farklı değiştirilmesi en bilinen örnektir. Ancak semantic, rename veya binary conflict daha zor durumlar yaratabilir. Conflict çözmek yalnız dosyayı compile eder hale getirmek değildir. Her iki değişikliğin business ve teknik niyeti korunmalıdır.

Text Conflict

Text conflict aynı satırlar veya yakın bölgeler iki history tarafından değiştirildiğinde oluşur. Git conflict marker ekleyerek kullanıcı kararı ister. Kullanıcı doğru kombinasyonu seçer. Marker'ların kaldırılması tek başına doğru çözüm anlamına gelmez. Test ve review gerekir.

Semantic Conflict

Semantic conflict Git'in otomatik merge edebildiği fakat davranışın yanlış hale geldiği durumdur. Örneğin iki taraf aynı API contract'ını farklı varsayımlarla değiştirmiş olabilir. Dosyada conflict marker bulunmayabilir. Testler bu tür hataları yakalamada kritiktir. Reviewer domain bağlamını değerlendirmelidir.

Rename Conflict

Bir branch dosyayı rename ederken diğer branch aynı dosyayı değiştirmiş olabilir. Git bazen rename'i otomatik eşleyebilir. Büyük rename veya refactor durumunda conflict oluşabilir. Dosyanın yeni konumu ve değişikliklerin tamamı kontrol edilmelidir. Test path ve import değişikliklerini doğrulamalıdır.

Delete/Modify Conflict

Bir taraf dosyayı silmiş, diğer taraf değiştirmiş olabilir. Burada teknik çözüm business kararına bağlıdır. Silinen dosyanın geri gelmesi yanlış olabilir. Değişiklik başka dosyaya taşınmalı olabilir. Dosya sahibiyle karar vermek güvenlidir.

Binary Conflict

Binary dosyalar satır bazlı birleştirilemez. Git çoğu durumda taraflardan birini seçmenizi ister. Generated artifact veya image gibi dosyalar repository'de tutuluyorsa bu durum görülebilir. Doğru versiyon ilgili kaynaktan yeniden üretilebilir. Binary conflict otomatik çözümden çok süreç kararı gerektirir.

Generated File Conflict

Generated file conflict çoğu zaman source değişiklikleri birleştirildikten sonra dosyanın yeniden üretilmesiyle çözülmelidir. İki generated sonucu manuel birleştirmek hata üretebilir. Lock file gibi dosyalarda package manager yeniden çalıştırılabilir. Generated file policy repository dokümantasyonunda yer almalıdır. CI dosyanın güncel üretildiğini kontrol edebilir.

Rebase Conflict Nasıl Güvenli Çözülür?

Güvenli conflict çözümü önce her iki tarafın değişikliğini anlamakla başlar. Conflict marker görmek otomatik seçim yapılması gerektiği anlamına gelmez. Gerekirse dosya sahibi veya ilgili feature geliştiricisiyle birlikte çözüm üretilmelidir. Rebase devam ettirilmeden önce doğru dosyalar stage edilmelidir. Tüm süreç tamamlandıktan sonra test ve review tekrarlanmalıdır.

Conflict'i Anlamak

Önce hangi commit uygulanırken conflict çıktığı incelenmelidir. Base tarafındaki değişiklik ve feature commitinin niyeti okunmalıdır. Git log ve diff yardımcı olabilir. Issue veya pull request context'i gerekirse kontrol edilmelidir. Doğru çözüm yalnız text farkından çıkarılamayabilir.

Dosya Sahibinden Destek Almak

Conflict bilmediğiniz bir modülde oluşuyorsa CODEOWNER veya ilgili geliştiriciden destek alınmalıdır. Özellikle business rule değişikliği semantic risk taşır. Pair review hızlı ve güvenli çözüm sağlayabilir. Tek başına tahmin yürütmek daha pahalı regression yaratabilir. Kurumsal ekipte ownership bu nedenle değerlidir.

git add

Conflict çözülen dosya git add ile stage edilir. Bu işlem Git'e ilgili conflictin çözüldüğünü bildirir. Tüm conflict dosyaları kontrol edilmelidir. Yanlışlıkla unrelated dosya stage edilmemelidir. Ardından rebase devam ettirilebilir.

git rebase --continue

git rebase --continue sıradaki commitin yeniden uygulanmasını sağlar. Yeni conflict oluşursa süreç tekrar durur. Her adımda commit bağlamı okunmalıdır. Rebase tamamlanana kadar süreç kontrollü ilerler. Final history sonrasında ayrıca incelenmelidir.

git rebase --skip Riski

git rebase --skip mevcut commitin uygulanmasını tamamen atlar. Bu komut yanlış kullanılırsa gerekli code değişikliği kaybolabilir. Sadece commit gerçekten gereksiz veya zaten uygulanmışsa kullanılmalıdır. Önce diff ve patch içeriği kontrol edilmelidir. Şüphe varsa abort daha güvenli seçenektir.

git rebase --abort

git rebase --abort işlemi başlamadan önceki branch durumuna dönmeye çalışır. Conflict beklenenden daha büyükse güvenli çıkış sağlar. Geliştirici farklı entegrasyon yöntemi seçebilir. Backup branch varsa ek recovery seçeneği oluşur. Abort başarısızlık değil kontrollü geri dönüş aracıdır.

Çözüm Sonrası Test

Conflict çözümü yeni code ürettiği için test zorunludur. Unit testler business behavior'ı kontrol eder. Integration testler main değişiklikleriyle gerçek entegrasyonu doğrular. Kritik conflictler yeniden code review almalıdır. CI güncel HEAD üzerinde tamamlanmalıdır.

Conflict Çözümü Neden Yeniden Code Review Gerektirebilir?

Conflict resolution iki branch'te daha önce ayrı ayrı review edilmiş koddan farklı bir üçüncü sonuç üretebilir. Git marker'ları kaldırılmış olsa bile davranış yanlış birleşmiş olabilir. Özellikle authorization, payment veya migration kodlarında bu risk yüksektir. Otomatik testler her semantic hatayı yakalamayabilir. Bu nedenle önemli conflict çözümü CODEOWNER veya ilgili reviewer tarafından yeniden incelenmelidir.

Conflict Resolution'ın Yeni Kod Üretmesi

Çözüm sırasında geliştirici iki tarafı manuel birleştirir. Ortaya çıkan kod daha önce hiçbir committe tam olarak bulunmamış olabilir. Eski approval bu yeni kombinasyonu kapsamamıştır. Review sisteminin stale approval kuralı burada faydalıdır. Yeni diff özellikle incelenmelidir.

Her İki Tarafın Mantığının Yanlış Birleştirilmesi

İki değişiklik ayrı ayrı doğru olabilir. Bir araya geldiklerinde aynı state'i iki farklı şekilde güncelleyebilirler. Bu semantic conflict compile aşamasında görünmeyebilir. Business test eksikse production'a ulaşabilir. Reviewer iki feature'ın niyetini birlikte değerlendirmelidir.

Otomatik Testlerin Yetersizliği

Test suite tüm davranış kombinasyonlarını kapsamayabilir. Conflict yeni bir interaction oluşturabilir. Testlerin geçmesi güçlü sinyaldir ama tek başına kesinlik sağlamaz. Riskli dosyalarda manual review devam etmelidir. Incident geçmişi hangi alanların daha fazla dikkat istediğini gösterebilir.

CODEOWNERS Review

CODEOWNERS belirli path'ler için sorumlu reviewer tanımlar. Conflict bu path'lerdeyse owner approval zorunlu tutulabilir. Böylece domain bilgisi olan kişi final birleşimi görür. Rebase sonrası approval otomatik yenilenebilir. Policy as code yaklaşımı manuel unutmayı azaltır.

git rerere ile Tekrarlanan Conflict'leri Yönetmek

git rerere daha önce çözülen conflict resolution bilgisini kaydederek benzer conflict tekrar oluştuğunda yeniden kullanabilir. Uzun rebase serileri veya backport süreçlerinde zaman kazandırabilir. Ancak otomatik yeniden kullanımın doğru olduğuna güvenmeden önce diff kontrol edilmelidir. Aynı text conflict farklı semantic bağlama sahip olabilir. Kurumsal kullanımda rerere destek aracı olarak görülmeli, review yerine kullanılmamalıdır.

rerere Nedir?

Rerere “reuse recorded resolution” fikrine dayanır. Git conflict şekli ve çözümünü local repository içinde hatırlayabilir. Aynı conflict tekrar oluştuğunda çözümü yeniden uygulamayı deneyebilir. Özellikle repeated rebase süreçlerinde faydalıdır. Kullanıcı final sonucu yine doğrulamalıdır.

Conflict Resolution Kaydı

Git conflict öncesi ve çözüm sonrası dosya durumunu kaydeder. Bu kayıt local geliştirme ortamında tutulur. Gelecekte eşleşen conflict görülürse çözüm önerilebilir. Sensitive repository'lerde local tooling policy değerlendirilmelidir. Kaydın otomatik doğruluk garantisi yoktur.

Repeated Rebase Senaryoları

Uzun feature branch main üzerine birkaç kez rebase ediliyorsa aynı conflict tekrar çıkabilir. Rerere önceki çözümü uygulayarak süreyi azaltabilir. Ancak asıl problem branch'in fazla uzun yaşıyor olması olabilir. Tooling semptomu azaltır. Branch lifetime metriği kök nedeni gösterebilir.

Release Branch Backport'ları

Aynı fix birkaç release branch'e taşındığında benzer conflictler oluşabilir. Rerere bazı tekrarları hızlandırabilir. Yine de her release farklı code context'ine sahip olabilir. Otomatik çözüm mutlaka test edilmelidir. Backport PR'ları bağımsız review alabilir.

Kurumsal Kullanım Riskleri

Rerere semantic doğruluk sağlamaz. Daha önceki çözüm yeni context için yanlış olabilir. Otomatik uygulandığında geliştirici conflict'i fark etmeden ilerleyebilir. CI ve code review bu riski azaltır. Ekip rerere kullanımını dokümante edebilir.

Rebase Sonrası Değişiklikleri git range-diff ile Kontrol Etmek

git range-diff iki commit serisini patch seviyesinde karşılaştırmaya yardımcı olur. Rebase öncesi ve sonrası commitlerin nasıl değiştiğini görmek için oldukça değerlidir. Reviewer büyük history rewrite sonrası yalnız normal diff'e güvenmek zorunda kalmaz. Yanlışlıkla düşen veya değişen commitler daha kolay fark edilebilir. Özellikle stacked branch veya uzun patch serilerinde kullanışlıdır.

Range-Diff Nedir?

Range-diff iki commit aralığının patch serilerini eşleştirir. Normal diff yalnız file state'i karşılaştırırken range-diff commit serisi ilişkisini göstermeye çalışır. Rebase sonucu yeni SHA oluştuğunda bu özellik değerlidir. Reviewer hangi commitin nasıl değiştiğini görebilir. Tool doğru range seçimi gerektirir.

Rebase Öncesi Patch Serisi

Rebase öncesi branch referansı backup branch ile korunabilir. Bu referans eski commit serisini temsil eder. Range-diff karşılaştırmasının ilk tarafı olarak kullanılabilir. Backup branch recovery için de faydalıdır. İş tamamlanınca silinebilir.

Rebase Sonrası Patch Serisi

Yeni feature branch rebase edilmiş commitleri taşır. Patchler çoğunlukla aynı görünmelidir. Conflict çözümü nedeniyle belirli commitler değişmiş olabilir. Range-diff bu farkları öne çıkarabilir. Beklenmeyen değişiklik varsa rebase yeniden değerlendirilir.

Yanlışlıkla Değişen Commit'leri Bulmak

Interactive rebase sırasında commit drop veya edit yanlış yapılabilir. Normal final diff bazı durumlarda sorunu gizleyebilir. Range-diff commit bazında beklenmeyen patch farkını gösterir. Bu kontrol force push öncesinde yapılabilir. Büyük rewrite için güçlü güvenlik adımıdır.

Reviewer İçin Kullanım

Reviewer rebase sonrası tüm PR'ı sıfırdan okumak zorunda kalmayabilir. Range-diff hangi commitlerin değiştiğini özetler. Yine de final code review tamamen atlanmamalıdır. Conflict resolution alanları ayrıca incelenmelidir. Tool reviewer context'ini korumaya yardımcı olur.

Yanlış Rebase Nasıl Geri Alınır?

Yanlış rebase çoğu durumda Git reflog sayesinde geri alınabilir. Git branch pointer hareketlerini bir süre kayıt altında tutar. Rebase öncesi state bulunup backup branch oluşturulabilir. ORIG_HEAD bazı senaryolarda eski konumu işaretleyebilir. Force push yapılmış olsa bile başka clone veya reflog recovery imkanı sağlayabilir.

git reflog

git reflog HEAD ve branch referanslarının geçmiş hareketlerini gösterir. Rebase öncesi commit buradan bulunabilir. Commit hash belirlendikten sonra yeni recovery branch oluşturmak güvenlidir. Doğrudan reset yapmadan önce bu branch alınmalıdır. Reflog remote için değil local repository için çalışır.

ORIG_HEAD

ORIG_HEAD bazı history-changing operasyonlardan önceki HEAD'i gösterebilir. Rebase recovery sırasında faydalı olabilir. Her durumda sonsuza kadar güvenilir tek referans olarak görülmemelidir. Reflog daha geniş geçmiş sağlar. Önemli operasyon öncesi manual backup branch en anlaşılır yöntemdir.

Backup Branch

Rebase öncesi backup/feature-name gibi geçici branch oluşturulabilir. Bu branch eski commit serisini sabit tutar. Rebase yanlış giderse hızlıca geri dönülebilir. Range-diff için de referans sağlar. İşlem doğrulandıktan sonra backup temizlenebilir.

git reset --hard

git reset --hard branch ve working tree'yi belirli commit'e taşır. Yanlış kullanıldığında uncommitted değişiklikleri kaybettirebilir. Bu nedenle hedef SHA kesinleşmeden uygulanmamalıdır. Önce recovery branch oluşturmak daha güvenlidir. Shared branch üzerinde force push ile birleştirilmemelidir.

Kaybolan Commit'i Bulmak

Commit branch history'den düşmüş olsa bile Git object database içinde bir süre bulunabilir. Reflog hash'i gösterebilir. Başka geliştiricinin clone'u da commit referansını taşıyor olabilir. Commit bulunduğunda branch veya tag ile korunmalıdır. Ardından doğru history yeniden oluşturulabilir.

Remote Force Push Sonrası Kurtarma

Yanlış force push remote history'yi değiştirmiş olabilir. Eski commit başka local clone'da veya CI checkout'ta bulunabilir. İlgili SHA recovery branch olarak push edilebilir. Main gibi protected branch'te force push zaten teknik olarak engellenmiş olmalıdır. Incident sonrasında policy eksikliği ayrıca düzeltilmelidir.

Protected Branch Kuralları Nasıl Tasarlanmalı?

Protected branch kuralları Git politikasını yalnız dokümanda bırakmak yerine teknik olarak uygular. Main gibi kritik branch'lerde pull request, review ve CI zorunlu tutulabilir. Force push kapatılabilir ve direct push sınırlandırılabilir. Signed commit veya linear history gibi ek gereksinimler proje ihtiyacına göre eklenebilir. Admin bypass çok geniş bırakılırsa policy kolayca anlamını kaybeder.

Pull Request Zorunluluğu

Main'e değişiklik doğrudan push edilmemelidir. Pull request değişikliğin review ve CI sürecinden geçmesini sağlar. Emergency durumlar için ayrı kontrollü bypass prosedürü bulunabilir. Normal günlük kullanımda tüm değişiklikler aynı akıştan geçmelidir. Bu kural traceability'yi güçlendirir.

Required Reviews

Belirli sayıda reviewer approval merge için zorunlu tutulabilir. Kritik modüller CODEOWNERS gerektirebilir. Geliştirici kendi PR'ını tek başına onaylayamamalıdır. Rebase sonrası stale approval policy devreye girebilir. Review sayısı risk seviyesine göre ayarlanmalıdır.

Required Status Checks

Unit test, integration test ve security scan gibi CI sonuçları required yapılabilir. Yeni commit geldiğinde eski status geçersiz sayılmalıdır. Merge yalnız güncel HEAD kontrolleri geçtiğinde yapılmalıdır. Merge queue kullanılıyorsa final integration commit de test edilebilir. Bu kural broken main riskini azaltır.

Conversation Resolution

Açık review commentleri çözülmeden merge engellenebilir. Böylece önemli geri bildirimler gözden kaçmaz. Rebase sonrası outdated commentler ayrıca kontrol edilmelidir. Reviewer'ın unresolved security veya design sorusu merge öncesinde cevaplanır. Otomasyon review disiplinini destekler.

Linear History

Repository yalnız squash veya rebase merge gibi linear yöntemlere izin verebilir. Bu tercih git log görünümünü sadeleştirir. Ancak geliştiriciyi shared branch üzerinde manuel rebase yapmaya zorlamamalıdır. Server-side merge ve merge queue daha güvenli çözüm olabilir. Linear history bir süreç tercihi olarak kalmalıdır.

Signed Commits

Signed commit belirli commitin doğrulanabilir bir imzayla oluşturulduğunu gösterebilir. GPG veya SSH signature kullanılabilir. Rebase commit SHA ve içeriğini yeniden oluşturduğu için eski imza korunmayabilir. Repository signature requirement kullanıyorsa workflow buna göre test edilmelidir. Server-side merge davranışı ayrıca incelenmelidir.

Restrict Push

Main'e kimlerin push yapabileceği sınırlandırılabilir. Normal geliştirici yalnız PR üzerinden değişiklik gönderebilir. Release automation için özel service account tanımlanabilir. Bot izinleri minimum tutulmalıdır. Yetki modeli least privilege prensibiyle uygulanmalıdır.

Force Push Yasaklama

Protected branch üzerinde force push kapalı tutulmalıdır. Bu ayar main history rewrite riskini teknik olarak engeller. Release branch için de benzer kural uygulanabilir. Personal feature branch'ler bu korumanın dışında kalabilir. Branch pattern ruleset ile kapsam belirlenebilir.

Admin Bypass Politikasını Sınırlandırma

Adminlerin tüm kuralları kolayca bypass edebilmesi governance riskidir. Emergency bypass kayıt altına alınmalıdır. Mümkünse yalnız belirli roller ve gerekçe ile kullanılmalıdır. Bypass sonrası audit log incelenebilir. Normal geliştirme süreci admin istisnasına dayanmaz.

Linear Git History Zorunlu Tutulmalı mı?

Linear history log okumayı ve bazı debugging işlemlerini kolaylaştırabilir. Ancak bu hedef yanlış uygulanırsa geliştiriciler sürekli rebase ve force push yapmak zorunda kalabilir. Branch topology kaybı bazı ekiplerde audit context'i azaltabilir. Server-side squash veya rebase merge daha kontrollü bir çözüm sunabilir. Linear history yalnız görsel sadelik amacıyla ekip güvenliğini riske atmamalıdır.

Avantajları

Linear history commit akışını tek çizgide gösterir. Git log okumak kolaylaşabilir. Revert ve bisect süreçleri sadeleşebilir. Merge commit gürültüsü azalır. Ancak bu avantaj commit kalitesiyle birlikte anlam kazanır.

Okunabilir History

Tek çizgide ilerleyen history yeni geliştiricinin değişiklik sırasını daha kolay görmesini sağlayabilir. Feature başına squash commit kullanılıyorsa log iş odaklı görünür. Atomic commit yaklaşımında daha ayrıntılı teknik hikaye korunabilir. Commit mesajı kalitesi yine belirleyicidir. Kötü mesajlı linear history de düşük değer taşır.

Daha Basit Revert

Squash merge kullanıldığında bir feature tek commit üzerinden revert edilebilir. Bu incident sırasında pratik olabilir. Atomic rebase merge kullanılıyorsa birkaç commitin geri alınması gerekebilir. Merge commit revert de mümkündür. Revert stratejisi merge yöntemiyle birlikte düşünülmelidir.

git bisect

Linear ve build edilebilir commit zinciri bisect sürecini kolaylaştırır. Hatalı commit aralığı daha net daralır. Ancak her commit bağımsız test edilemiyorsa avantaj azalır. Squash edilmiş büyük commitler bisect çözünürlüğünü düşürebilir. Commit tasarımı history biçiminden daha önemlidir.

Dezavantajları

Linear history branch'lerin gerçek birleşme noktalarını gizleyebilir. Geliştirici üzerinde sürekli history cleanup baskısı oluşabilir. Shared branch rebase gibi yanlış uygulamalar teşvik edilebilir. Audit ekibi gerçek integration context'ini kaybedebilir. Bu nedenle dezavantajlar repository ihtiyacına göre değerlendirilmelidir.

Branch Topolojisinin Kaybolması

Rebase merge feature branch'in nerede ayrıldığını history'de göstermez. Bazı ekipler için bu bilgi gereksizdir. Bazıları için incident veya audit analizi açısından değerlidir. PR kaydı topology bilgisinin bir kısmını koruyabilir. Git history tek bilgi kaynağı olarak görülmemelidir.

History Rewrite Baskısı

Linear history hedefi geliştiriciyi her main değişiminde rebase yapmaya zorlayabilir. Bu yaklaşım force push sayısını artırır. Review ve CI tekrar tekrar çalışabilir. Merge queue daha iyi otomasyon sağlayabilir. Süreç estetik hedefe kurban edilmemelidir.

Audit Context Kaybı

Merge commit belirli feature branch'in entegrasyon noktasını açıkça gösterebilir. Rebase bunu ortadan kaldırır. PR sistemi approval ve review context'ini ayrı kayıtta tutabilir. Regulated ekipler bu kayıtların retention süresini değerlendirmelidir. History modeli compliance ihtiyacıyla birlikte seçilmelidir.

Signed Commit ve Rebase Yönetimi

Commit signing source history'nin doğrulanabilirliğini artırmak için kullanılabilir. GPG veya SSH imzası commitin içeriği ve kimliğiyle bağlantılıdır. Rebase yeni commit oluşturduğu için önceki imza geçerli kalmayabilir. Server-side rebase merge de farklı imza davranışı gösterebilir. Signed commit zorunlu ekiplerde rebase policy bu teknik ayrıntıyı açık biçimde ele almalıdır.

Commit Signing Nedir?

Commit signing commitin bir private key ile imzalanmasını sağlar. Repository platformu imzayı verified olarak gösterebilir. Bu mekanizma author name alanından daha güçlü doğrulama sunar. Yine de account security ve key management önemlidir. Signing tek başına code review yerine geçmez.

GPG ve SSH Signatures

Git commit signing için GPG veya desteklenen SSH key yöntemleri kullanılabilir. Ekip mevcut identity altyapısına göre seçim yapabilir. Key rotation ve offboarding süreci tanımlanmalıdır. CI botlarının da signing ihtiyacı olabilir. Private key güvenli biçimde saklanmalıdır.

Rebase Sonrası İmza Durumu

Rebase commit nesnesini yeniden oluşturur. Eski commit signature yeni committe otomatik olarak geçerli kalmaz. Geliştirici yeni commitleri tekrar imzalayabilir. Interactive rebase birçok commit için bu davranışı etkileyebilir. Repository signed commit requirement kullanıyorsa push öncesi kontrol edilmelidir.

Server-Side Rebase Merge Davranışı

Repository platformu server-side rebase merge sırasında yeni commitler oluşturabilir. Bu commitlerin signature durumu platform davranışına bağlıdır. Regulated ekipler bunu test repository üzerinde doğrulamalıdır. Approval ve provenance kayıtlarıyla birlikte değerlendirilmelidir. Merge yöntemini seçerken signing gereksinimi unutulmamalıdır.

Regulated Ekiplerde Signature Policy

Regulated ekip signed commit, required reviewer ve immutable release history kombinasyonu kullanabilir. Rebase private feature branch ile sınırlandırılabilir. Main ve release history rewrite edilmez. Build provenance final commit veya artifact ile bağlanır. Policy as code ile teknik enforcement sağlanır.

Merge Queue Rebase Problemlerini Nasıl Azaltır?

Merge queue aynı anda çok sayıda PR'ın main'e girmeye çalıştığı repository'lerde entegrasyonu sıraya alır. Sistem PR'ı güncel main ile geçici olarak birleştirip CI çalıştırabilir. Böylece geliştiricinin sürekli manuel rebase yapma ihtiyacı azalır. Main değiştikçe PR yarışı kontrollü hale gelir. Büyük ekiplerde merge queue hem throughput hem güvenilirlik için güçlü araçtır.

Merge Queue Nedir?

Merge queue onaylanmış PR'ları sıraya alır. Her PR main'in uygun güncel haliyle test edilir. Required checks geçerse merge gerçekleştirilir. Başarısız PR sıradan çıkarılabilir. Böylece broken integration main'e ulaşmadan yakalanır.

Main Sürekli Değişirken PR Yarışı

İki PR aynı base üzerinde CI'ı geçebilir. İlk PR merge olduğunda ikinci PR'ın base'i artık değişmiştir. İkinci PR yeni main ile conflict veya test failure üretebilir. Merge queue bu final entegrasyonu tekrar doğrular. Manuel rebase yarışı azalır.

Rebase → CI → Main Değişti Döngüsü

Yoğun repository'de geliştirici branch'i rebase eder ve CI başlatır. Pipeline tamamlanmadan main yeniden ilerler. Strict up-to-date policy geliştiriciyi tekrar rebase etmeye zorlayabilir. Merge queue bu döngüyü merkezi olarak yönetir. Böylece force push ve gereksiz CI sayısı azalabilir.

Queue İçinde Son Entegrasyon Testi

Queue geçici merge veya rebase sonucu oluşturabilir. Unit ve integration testler bu final kombinasyon üzerinde çalışır. Status başarılıysa main'e entegrasyon yapılır. Başarısızsa ilgili PR düzeltilmek üzere geri döner. Main'in yeşil kalma olasılığı yükselir.

Büyük Ekiplerde Kullanım

Yüksek commit frekansı manual coordination'ı zorlaştırır. Merge queue merge sırasını otomatik yönetir. Repository policy tüm ekipler için aynı uygulanır. CI kapasitesi queue throughput'una göre ayarlanmalıdır. Monorepo ve büyük platform ekiplerinde ciddi fayda sağlayabilir.

Kısa Ömürlü Branch'ler Neden Önemlidir?

Kısa ömürlü branch yaklaşımı rebase ve merge conflict sorunlarını kökten azaltan en etkili yöntemlerden biridir. Branch main'den yalnız kısa süre uzak kaldığı için değişiklik farkı küçük kalır. PR boyutu küçülür ve review hızlanır. Feature flag gibi teknikler büyük geliştirmeyi parçalamaya yardımcı olur. Branch age metriği bu davranışın gerçekten uygulanıp uygulanmadığını gösterebilir.

Merge Conflict Riskinin Azalması

Branch bir gün yaşadığında main'deki değişiklik sayısı sınırlıdır. Aynı dosyaların iki tarafta değişme ihtimali azalır. Conflict çıkarsa bağlam hala geliştiricinin zihnindedir. Haftalar sonra yapılan büyük conflict çözümüne göre daha güvenlidir. Kısa branch entegrasyon maliyetini sürekli küçük tutar.

Daha Küçük Pull Request

Küçük branch genellikle küçük PR üretir. Reviewer daha az dosyayı daha hızlı anlayabilir. Feedback daha erken gelir. Hatalı yön günler sonra değil aynı gün fark edilebilir. PR rework oranı düşebilir.

Daha Hızlı Review

Küçük değişiklik review queue'da daha kolay ele alınır. Reviewer uzun süre context ayırmak zorunda kalmaz. Approval süresi kısalabilir. Developer da feedback beklerken başka büyük diverging branch geliştirmek zorunda kalmaz. Time to merge metriği iyileşir.

Daha Az Rebase İhtiyacı

Kısa branch main'den fazla geri kalmaz. Bu nedenle PR öncesinde hiç rebase gerekmeyebilir. Gerektiğinde conflict sayısı az olur. Force push kullanım ihtiyacı da düşer. Rebase policy basitleşir.

Branch Age Metric

Branch'in ilk commit veya creation tarihinden merge tarihine kadar geçen süre ölçülebilir. Ortalama ve yüzde 95 branch age ekip davranışını gösterebilir. Çok uzun branch'ler otomatik alert üretebilir. Metric performans baskısı aracı olarak kullanılmamalıdır. Ama süreç darboğazını anlamaya yardımcı olur.

Branch Lifetime İçin Kurumsal Standart Belirlemek

Branch lifetime standardı ekiplerin “kısa branch” ifadesini ortak biçimde anlamasını sağlar. Her repository için aynı süre zorunlu olmayabilir. Küçük web servisi ile büyük embedded release projesinin ritmi farklıdır. Yine de bir haftadan uzun feature branch'ler özel dikkat gerektirebilir. Stale branch alert ve otomatik cleanup süreçleri bu standardı destekleyebilir.

1 Günden Kısa Branch

Çok küçük değişikliklerde ideal model olabilir. Branch main'den hemen geri döner. Conflict riski düşüktür. Review ve CI hızla tamamlanmalıdır. Trunk-Based Development yaklaşımı bu davranışı teşvik eder.

1–3 Gün

Birçok feature ve bug fix için makul aralıktır. PR gün içinde veya birkaç gün içinde review edilebilir. Main ile divergence sınırlı kalır. Rebase gerekirse basit olur. Ekip bu aralığı hedef değer olarak kullanabilir.

1 Haftadan Uzun Branch

Bir haftayı aşan branch büyük scope veya blocker işareti olabilir. PR açılmamışsa erken draft review düşünülebilir. Feature küçük parçalara bölünebilir. Main'den fark hızla büyüyebilir. Rebase ve conflict maliyeti artar.

Stale Branch Alert

Belirli süre güncellenmeyen branch için otomatik bildirim gönderilebilir. Owner branch'in hala gerekli olup olmadığını değerlendirir. Açık PR varsa blocker sorulabilir. Alert suçlayıcı değil süreç destekleyici olmalıdır. Uzun branch'lerin görünür kalmasını sağlar.

Otomatik Branch Cleanup

Merge edilen feature branch otomatik silinebilir. Uzun süre kullanılmayan branch belirli grace period sonrası temizlenebilir. Protected ve release branch'ler cleanup dışında tutulmalıdır. Silme öncesi açık PR veya tag kontrol edilmelidir. Repository kalabalığı azalır.

İstisna Süreci

Bazı migration veya platform çalışmaları daha uzun branch gerektirebilir. Ekip bu durumda explicit istisna tanımlayabilir. Branch owner ve entegrasyon planı belirlenir. Main ile sık sync yöntemi kararlaştırılır. İstisna normal davranışa dönüşmemelidir.

Büyük Feature'lar Uzun Branch Olmadan Nasıl Geliştirilir?

Büyük feature'ın uzun süre tek branch'te kalması zorunlu değildir. Feature flags ve branch by abstraction değişikliklerin küçük parçalar halinde main'e taşınmasını sağlar. Backward-compatible database ve API değişiklikleri incremental delivery için önemlidir. Dark launch sayesinde feature kullanıcıya açılmadan production altyapısında doğrulanabilir. Kill switch ise beklenmeyen durumda davranışı hızlı kapatmayı sağlar.

Feature Flags

Feature flag incomplete behavior'ı kullanıcıdan gizler. Kod main'e küçük parçalar halinde merge edilebilir. Flag yalnız belirli kullanıcı veya ortam için açılabilir. Flag'lerin süresiz kalmaması gerekir. Feature tamamen yayınlandığında cleanup yapılmalıdır.

Branch by Abstraction

Eski ve yeni implementation ortak abstraction arkasında çalışabilir. Yeni davranış parça parça eklenir. Trafik veya configuration ile yeni implementation'a geçiş yapılabilir. Büyük bang branch yerine incremental entegrasyon sağlanır. Geçiş tamamlanınca eski abstraction temizlenir.

Incremental Delivery

Feature küçük, production-safe adımlara bölünür. İlk commit altyapı hazırlığı olabilir. Sonraki PR yeni behavior'ı feature flag arkasında ekler. Her adım ayrı review ve CI sürecinden geçer. Böylece branch ömrü kısa kalır.

Backward-Compatible Changes

API ve database değişiklikleri eski code ile geçici olarak uyumlu tasarlanabilir. Önce yeni field eklenir, sonra code kullanmaya başlar ve en son eski field kaldırılır. Bu expand-and-contract yaklaşımı branch bağımlılığını azaltır. Aynı zamanda rollback kolaylaşır. Release ve migration planı birlikte yürütülmelidir.

Dark Launch

Feature code production'a deploy edilir fakat kullanıcı trafiğine açılmaz. Internal veya küçük test grubuyla behavior gözlemlenebilir. Uzun feature branch ihtiyacı azalır. Observability ve feature flag sistemi önemlidir. Başarı doğrulandıktan sonra kontrollü rollout yapılabilir.

Kill Switch

Kill switch sorunlu feature'ı yeni deployment beklemeden kapatmayı sağlar. Özellikle external service veya yüksek riskli business flow'da faydalıdır. Switch güvenli default davranışa dönmelidir. Audit log kim tarafından değiştirildiğini gösterebilir. Feature flag altyapısının kritik parçası olabilir.

Stacked Branch ve Stacked Pull Request Yönetimi

Stacked PR yaklaşımı büyük değişikliği birbirine bağlı küçük pull request'lere böler. Child branch parent branch üzerindeki commitlere dayanabilir. Parent rebase edildiğinde child branch'in base SHA'ları da eski hale gelir. Bu nedenle cascading rebase gerekebilir. Stacked workflow rebase disiplinini ve dependency graph görünürlüğünü önemli hale getirir.

Stacked PR Nedir?

Stacked PR bir büyük feature'ı sıralı küçük PR serisine böler. İkinci PR birinci PR'ın branch'ini base alabilir. Reviewer her katmanı ayrı inceler. PR boyutu küçük kalır. Ancak merge ve rebase sırası doğru yönetilmelidir.

Parent ve Child Branch

Parent branch daha alt seviyedeki değişikliği taşır. Child branch parent commitlerini base olarak kullanır. Parent history değişirse child eski parent SHA'larına bağlı kalabilir. Bu nedenle dependency açıkça belgelenmelidir. Tooling stacked branch yönetimini kolaylaştırabilir.

Parent Rebase Edilince Child Ne Olur?

Parent rebase yeni commit SHA'ları üretir. Child branch eski parent commitlerini history'sinde taşır. Child ayrıca yeni parent üzerine rebase edilmezse duplicate patch görülebilir. Conflict riski oluşur. Bu nedenle parent rewrite cascading etki yaratır.

Cascading Rebase

Parent rebase edildikten sonra her child sırayla yeni parent üzerine rebase edilebilir. Stack büyüdükçe işlem maliyeti hızla artar. Review SHA'ları da sürekli değişir. Bu nedenle stacked workflow için özel tooling faydalıdır. Gereksiz parent rewrite azaltılmalıdır.

Dependency Graph

Hangi PR'ın hangisine bağlı olduğu görünür olmalıdır. Reviewer yanlış sırada merge yapmamalıdır. CI child PR'ı doğru base ile test etmelidir. Parent merged olduğunda child base main'e güncellenebilir. Dependency graph automation hatayı azaltır.

Review Sırası

Genellikle önce en alttaki parent PR review edilmelidir. Parent değişirse child diff de etkilenir. Reviewer üst katmana geçmeden temel değişikliğin stabil olması faydalıdır. Merge sırası dependency sırasını takip eder. Bu yöntem büyük feature'ı küçük review parçalarına böler.

Release Branch'lerde Rebase Kullanılmalı mı?

Release branch'lerde rebase çoğu kurumsal ekip için uygun değildir. Release candidate commitleri test, approval ve deployment kayıtlarıyla ilişkilidir. History rewrite bu kayıtların referansını değiştirir. Hotfix veya patch değişiklikleri merge veya cherry-pick ile eklenebilir. Immutable release history audit ve rollback için daha güvenilir bir yapı sağlar.

Immutable Release History

Release branch'e giren commitler sonradan yeniden yazılmamalıdır. Her build belirli SHA ile ilişkilendirilebilir. Tag ve release artifact aynı history üzerinde kalır. Incident sırasında hangi kodun yayınlandığı kolayca bulunur. Force push kapalı tutulmalıdır.

Release Candidate

Release candidate belirli commit state'inin test edilen sürümüdür. Rebase yapılırsa artık farklı SHA ve potansiyel olarak farklı code oluşur. Yeni candidate olarak yeniden test edilmesi gerekir. Bu nedenle candidate history sabit tutulmalıdır. Değişiklik yeni commit olarak eklenmelidir.

Hotfix

Release branch üzerinde acil fix gerekirse küçük commit eklenebilir. Fix ayrı PR ve review sürecinden geçmelidir. Commit SHA release record'a eklenir. Development hattına backport veya merge unutulmamalıdır. History rewrite gerekmez.

Patch Release

Patch release desteklenen eski sürüm için küçük düzeltme taşıyabilir. Fix ilgili release branch'e cherry-pick edilebilir. Yeni tag bu committen üretilir. Eski tag değiştirilmemelidir. Release history kronolojik olarak korunur.

Backport

Backport yeni main'deki belirli fix'in eski release branch'e taşınmasıdır. Cherry-pick bu işlem için genellikle uygundur. Tüm main history'sini release üzerine rebase etmek gereksiz ve risklidir. Conflict release context'ine göre çözülür. Backport PR bağımsız test edilmelidir.

Audit ve Traceability

Release commitleri change ticket ve deployment kaydıyla eşleştirilebilir. Rebase SHA değiştirirse bu bağlantı zorlaşır. Immutable branch traceability'yi basitleştirir. Signed tags ek güven sağlayabilir. Release süreci Git history ile deployment record'u birlikte tutmalıdır.

Neden Merge veya Cherry-Pick Daha Uygun Olabilir?

Merge existing history'yi yeniden yazmaz. Cherry-pick yalnız gerekli fix'i yeni commit olarak release branch'e taşır. Her iki yöntem de release branch pointer geçmişini korur. Audit ve rollback daha anlaşılır olur. Rebase ise gereksiz geniş history değişikliği yaratabilir.

Backport İşlemlerinde Rebase mi Cherry-Pick mi?

Backport işlemlerinde çoğu zaman cherry-pick daha doğrudan bir araçtır. Amaç main history'nin tamamını eski branch'e taşımak değil belirli fix'i uygulamaktır. Cherry-pick yeni branch üzerinde yeni SHA üretir ancak mevcut release history'yi yeniden yazmaz. Merge belirli durumlarda bir dizi fix için uygun olabilir. Rebase eski release history'sini değiştirdiği için genellikle önerilmez.

Supported Release Branch'leri

Bir ürün aynı anda birkaç major veya minor sürümü destekleyebilir. Her sürüm için release branch bulunabilir. Security veya critical bug fix birden fazla branch'e taşınabilir. Backport policy hangi sürümlerin desteklendiğini açıkça belirtmelidir. EOL branch'lere gereksiz fix yapılmamalıdır.

Tek Bir Fix'in Eski Sürüme Taşınması

Fix main üzerinde geliştirilip test edilmiş olabilir. Eski sürümde aynı bug varsa ilgili commit seçilir. Cherry-pick patch'i release branch'e uygular. Conflict eski code context'ine göre çözülür. Yeni test pipeline release branch üzerinde çalıştırılır.

Cherry-Pick

git cherry-pick belirli commit patch'ini current branch üzerine yeni commit olarak uygular. Original commit ile yeni commit SHA farklı olur. Commit mesajına source SHA veya backport bilgisi eklenebilir. Release branch history korunur. Backport automation bu süreci standardize edebilir.

Merge

Bir maintenance branch içindeki birden fazla fix birlikte taşınacaksa merge düşünülebilir. Merge history ilişkisini korur. Ancak hedef release branch'te gereksiz değişiklikler bulunmamalıdır. PR review kapsamı açık olmalıdır. Tek fix için cherry-pick çoğu zaman daha anlaşılırdır.

Rebase'in Riski

Release branch'i yeni main üzerine rebase etmek desteklenen eski sürüm history'sini baştan değiştirir. Bu işlem eski release commitlerini yeni SHA'larla yeniden oluşturabilir. Deployment ve tag referanslarıyla uyumsuzluk çıkar. Shared branch kullanıcıları etkilenir. Backport için çok daha geniş bir değişikliktir.

Backport Label ve Automation

Pull request üzerinde backport label kullanılabilir. Bot merged commit'i ilgili release branch'e cherry-pick edebilir. Conflict varsa manual PR oluşturabilir. CI her target release üzerinde çalıştırılır. Otomasyon backport unutma riskini azaltır.

Hotfix Branch Yönetimi

Hotfix branch production'daki kritik bir problemi hızlı ama kontrollü biçimde çözmelidir. Branch doğrudan production state'i temsil eden main veya release tag'den açılmalıdır. Fix küçük ve odaklı tutulur. Test ve review tamamen atlanmamalıdır. En sık yapılan hata hotfix'i production'a taşıdıktan sonra development hattına geri taşımayı unutmaktır.

Production'dan Hotfix Branch Açmak

Hotfix doğru production commitinden başlamalıdır. Main production ile eşleşmiyorsa ilgili release tag veya branch kullanılmalıdır. Yanlış base ekstra unreleased code taşıyabilir. Branch adı ticket veya incident ID içerebilir. Başlangıç SHA incident kaydına eklenebilir.

Fix'i Test Etmek

Acil durum testlerin tamamen atlanması anlamına gelmez. Bug reproduction testi mümkünse önce yazılmalıdır. Critical integration veya smoke test çalıştırılmalıdır. Pipeline hızlandırılabilir ama güvenlik kontrolleri korunmalıdır. Fix production riskini azaltırken yeni risk üretmemelidir.

Production Branch'e Entegrasyon

Hotfix PR üzerinden main veya release branch'e merge edilir. Direct force push kullanılmamalıdır. Approval emergency policy'ye göre hızlandırılabilir. Build artifact ilgili committen üretilir. Deployment record final SHA'yı göstermelidir.

Fix'i Development Hattına Geri Taşımak

GitFlow kullanılıyorsa hotfix develop hattına da alınmalıdır. Aksi halde sonraki release bug'ı geri getirebilir. Merge veya cherry-pick kullanılabilir. Conflict varsa yeni development context'ine göre çözülür. CI tekrar çalıştırılır.

Hotfix'in Kaybolmasını Önlemek

Hotfix için otomatik backport task oluşturulabilir. PR template gerekli target branch'leri hatırlatabilir. Release bot ilgili label'ı takip edebilir. Incident kapanmadan development entegrasyonu kontrol edilir. Böylece production fix sonraki sürümde kaybolmaz.

Branch-per-Environment Neden Riskli Olabilir?

Dev, staging ve production için ayrı branch kullanmak environment durumunu Git ile temsil etmeye çalışır. Ancak merge sırasında code değişebildiği için staging'de test edilen content production branch'e aynı haliyle gitmeyebilir. Branch'ler zamanla drift yaşayabilir. Build artifact ile commit SHA ilişkisi belirsizleşebilir. Daha güvenli yöntem çoğu zaman aynı immutable artifact'i ortamlar arasında promote etmektir.

dev Branch

Dev branch sürekli yeni değişiklik alabilir. Environment bu branch'ten otomatik deploy edilebilir. Ancak dev ile staging arasında merge gerektiğinde yeni conflict oluşabilir. Test edilen commit dizisi değişebilir. Bu nedenle branch'in environment değil development hattını temsil etmesi daha açık olabilir.

staging Branch

Staging branch dev'den değişiklik merge ederek güncelleniyorsa ekstra history oluşur. Merge conflict çözümü staging'e özgü code yaratabilir. Production'a farklı merge yapıldığında aynı test edilen code garanti edilmez. Release candidate SHA sabit tutulmalıdır. Artifact promotion bu problemi azaltır.

production Branch

Production branch yalnız deploy edilmiş history'yi temsil etmek için kullanılabilir. Ancak dev ve staging branchlerinden sürekli merge almak drift riskini artırır. Deployment record zaten commit ve artifact bilgisini saklayabilir. Branch'i environment pointer olarak kullanmak her zaman gerekli değildir. Tag veya release metadata daha açık olabilir.

Merge Sırasında Kodun Değişmesi

Staging'den production'a merge conflict çıkabilir. Conflict çözümü staging'de test edilmemiş yeni code üretir. Böylece “staging'de test edildi” varsayımı bozulur. Aynı artifact promotion modelinde bu risk yoktur. Build bir kez oluşturulup aynı digest taşınır.

Environment Drift

Environment branch'leri farklı commit setleri taşıyabilir. Bir hotfix production'a doğrudan girip staging'e dönmeyebilir. Sonraki merge eski behavior'ı geri getirebilir. Drift karşılaştırması sürekli operasyon yükü yaratır. Environment state configuration ve deployment sistemiyle yönetilmelidir.

Aynı Artifact'i Promote Etme Yaklaşımı

CI tek committen immutable artifact üretir. Aynı artifact önce test ortamına, sonra production'a taşınır. Container image digest değişmez. Environment farkı configuration üzerinden yönetilir. Böylece test edilen ve yayınlanan binary aynı kalır.

Git History ile Deployment Arasındaki İlişki

Kurumsal sistemlerde deployment yalnız “hangi branch deploy edildi?” bilgisiyle izlenmemelidir. Commit SHA, build artifact ve container image digest arasında açık bağlantı kurulmalıdır. Deployment kaydı production ortamında hangi artifact'in bulunduğunu göstermelidir. Rebase eski SHA'ları history'den çıkarabileceği için public branch rewrite bu traceability'yi bozar. Immutable main ve release history bu yüzden deployment güveni açısından değerlidir.

Commit SHA

Commit SHA source code state'ini işaretler. CI build bu SHA üzerinde çalıştırılır. Pull request approval aynı SHA ile ilişkilendirilebilir. Rebase SHA'yı değiştirir. Production deployment kaydı final merge commit veya release commitini göstermelidir.

Build Artifact

Build artifact belirli source committen üretilmelidir. Artifact version metadata commit SHA içerebilir. Aynı artifact ortamlar arasında promote edilir. Tekrar build edilirse dependency veya time farkı yeni binary üretebilir. Build-once yaklaşımı traceability'yi güçlendirir.

Container Image Digest

Container tag değiştirilebilir ancak digest immutable content kimliğidir. Deployment kaydı digest ve source SHA'yı birlikte tutabilir. Böylece production'daki binary kesin biçimde tanımlanır. Rollback aynı digest'e dönerek yapılabilir. Git branch adı tek başına bu garantiyi vermez.

Deployment Record

Deployment kaydı environment, artifact, commit ve zaman bilgisini taşımalıdır. Change ticket veya approver bilgisi de eklenebilir. Incident sırasında hangi değişikliğin ne zaman çıktığı hızlıca bulunur. Git history ile runtime state bağlanır. Rebase edilmemiş immutable commitler bu ilişkiyi kolaylaştırır.

Rebase Sonrası Eski SHA'ların İzlenmesi

Private feature branch rebase edildiğinde eski SHA genellikle deployment için kritik değildir. Public branch rebase edilirse eski CI ve ticket linkleri orphan hale gelebilir. Eski commit object bir süre bulunabilir. Ancak ana history içinde görünmez. Bu nedenle production ile ilişkilendirilmiş history yeniden yazılmamalıdır.

Production Traceability

Production'daki her deployment source commit ve artifact ile geri izlenebilmelidir. Rollback gerektiğinde hangi eski artifact'in güvenli olduğu bilinmelidir. Bu konu hakkında daha geniş bir sürüm kontrolü perspektifi için https://www.diyarbakiryazilim.com.tr/posts/kod-tabani-geri-alma-rollback-surecleri-ve-versiyon-kontrol adresindeki rollback ve versiyon kontrolü içeriği de değerlendirilebilir. Git history tek başına deployment gerçeğinin tamamı değildir. Artifact ve deployment kayıtlarıyla birlikte ele alınmalıdır.

Rebase ve Audit/Compliance

Rebase her durumda audit problemi değildir, ancak nerede kullanıldığı önemlidir. Private feature branch history cleanup çoğu compliance modelinde production history kadar kritik değildir. Main veya release gibi kayıtlarla ilişkilendirilmiş branch'lerde history rewrite daha büyük sorun oluşturabilir. Approval, signature, build provenance ve change ticket kayıtları final commit ile bağlantılı tutulmalıdır. Eski SHA ile yeni SHA arasında mapping gerekebilecek süreçler açıkça tanımlanmalıdır.

History Rewrite Bir Audit Problemi midir?

History rewrite'in etkisi audit modeline bağlıdır. Private draft commitlerin değişmesi her zaman önemli olmayabilir. Release commitinin değişmesi ise approval ve deployment kayıtlarını etkileyebilir. Audit scope hangi history'nin immutable olması gerektiğini tanımlamalıdır. Kurallar branch bazında uygulanabilir.

Pull Request Record

Pull request discussion, review ve approval history'sini saklar. Squash merge kullanıldığında bile PR bağımsız audit context sağlayabilir. Retention policy bu kaydın ne kadar süre tutulacağını belirlemelidir. Rebase sonrası stale approval davranışı görünür olmalıdır. Final merge commit PR ile ilişkilendirilir.

Commit Signature

Commit signature author doğrulaması için ek güven sağlar. Rebase yeni commit ürettiği için signature yeniden oluşturulabilir. Release policy signed commit veya signed tag zorunluluğu koyabilir. Key management audit sürecinin parçasıdır. Signature code review'un yerini almaz.

Approval Record

Approval belirli code state üzerinde verilmelidir. Rebase sonrası eski approval geçersiz hale gelebilir. Repository stale review dismissal kullanabilir. Critical change iki bağımsız approval gerektirebilir. Approval record final deployment ile ilişkilendirilebilir.

Build Provenance

Build provenance artifact'in hangi source, dependency ve process ile üretildiğini gösterir. Commit SHA bu kaydın temel girdilerinden biridir. Public history rewrite provenance bağlantısını zorlaştırır. Build pipeline final merge commit üzerinden çalışmalıdır. Artifact digest deploy kaydına eklenmelidir.

Eski SHA → Yeni SHA Eşlemesi

Review sırasında rebase yapılmışsa eski ve yeni patch serisi range-diff ile eşleştirilebilir. Sistem bazı platformlarda force push eventlerini audit logda saklayabilir. Regulated ekip bunu kayıt olarak tutabilir. Ancak bu mekanizma main history rewrite'i normalleştirmemelidir. En iyi çözüm kritik branch'i immutable tutmaktır.

Change Ticket Entegrasyonu

Commit veya PR ticket ID taşıyabilir. Deployment automation change record ile final SHA'yı eşleştirebilir. Rebase sonrası PR link'i sabit kalırken commit SHA değişebilir. Final approval ticket'a otomatik yazılabilir. Böylece Git, CI ve change management aynı kayıt zincirinde birleşir.

Monorepo'larda Rebase Yönetimi

Monorepo yüksek commit frekansı nedeniyle rebase yönetimini daha görünür hale getirir. Birçok takım aynı main branch'e değişiklik gönderir. Conflict hotspot olan shared dosyalar sık değişebilir. CODEOWNERS ve merge queue coordination yükünü azaltabilir. Büyük CI maliyeti nedeniyle gereksiz rebase ve pipeline tekrarları özellikle pahalıdır.

Yüksek Commit Frekansı

Main çok hızlı ilerlediğinde feature branch birkaç saat içinde geride kalabilir. Strict up-to-date policy sürekli rebase döngüsü yaratabilir. Merge queue bunu merkezi biçimde çözebilir. Kısa PR ve hızlı CI önemlidir. Developer'ın manuel senkronizasyon yükü azaltılmalıdır.

Çok Sayıda Takım

Monorepo onlarca ekip tarafından kullanılabilir. Shared ownership alanları conflict riskini artırır. Branch strategy repository genelinde ortak temel kurallara sahip olmalıdır. Takımlar modül bazında ek policy uygulayabilir. CODEOWNERS review yönlendirmesini otomatikleştirir.

Conflict Hotspots

Root configuration, dependency lock file veya ortak schema dosyaları sık conflict üretebilir. Bu alanlar metric ile belirlenebilir. Repository yapısı veya tooling conflict sayısını azaltacak şekilde değiştirilebilir. Generated file policy önemli hale gelir. Kök nedeni çözmek sürekli rebase yapmaktan daha değerlidir.

CODEOWNERS

CODEOWNERS belirli path'lerin review sorumlusunu tanımlar. Conflict resolution bu alanları etkiliyorsa owner review zorunlu tutulabilir. Büyük monorepo'da doğru reviewer bulmayı kolaylaştırır. Ownership güncel tutulmalıdır. Eski takım isimleri review akışını bloke edebilir.

Merge Queue

Monorepo'da merge queue yüksek PR trafiğini sıraya alabilir. Her PR güncel main ile final CI'dan geçer. Manuel rebase ihtiyacı azalır. Queue batching CI maliyetini optimize edebilir. Başarısız batch'in izolasyonu dikkatle tasarlanmalıdır.

Büyük CI Pipeline Maliyeti

Her rebase full CI'ı yeniden tetikliyorsa maliyet hızla büyür. Affected-tests yaklaşımı bazı job'ları seçici çalıştırabilir. Final merge queue yine critical testleri doğrulayabilir. Cache ve remote build sistemi süreyi azaltabilir. Branch strategy CI ekonomisiyle birlikte düşünülmelidir.

Açık Kaynak Projelerde Rebase ve İşbirliği

Açık kaynak projelerde contributor çoğu zaman fork üzerinden çalışır. Kendi feature branch'ini upstream main üzerine rebase etmek normal ve faydalı bir uygulama olabilir. Ancak maintainer tarafından paylaşılan veya başkalarının üzerine çalıştığı branch yeniden yazılmamalıdır. DCO, Signed-off-by veya CLA gibi katkı politikaları commit history ile ilişkilendirilebilir. Rebase bu metadata'yı etkileyebileceği için contributor yönergeleri açık olmalıdır.

Fork Workflow

Contributor upstream repository'yi fork eder. Kendi fork'unda feature branch açar. Değişikliklerini commit edip pull request gönderir. Upstream main değişirse kendi branch'ini rebase edebilir. Bu branch başkaları tarafından paylaşılmıyorsa history rewrite genellikle güvenlidir.

origin ve upstream

Contributor repository'sinde origin kendi fork'unu temsil edebilir. upstream ana proje repository'sine işaret eder. Güncel base için upstream fetch edilir. Feature branch upstream/main üzerine rebase edilebilir. Remote isimleri ekip dokümantasyonunda açıklanmalıdır.

Upstream/main Üzerine Rebase

Contributor önce git fetch upstream çalıştırır. Kendi branch'inde git rebase upstream/main uygulayabilir. Conflict çözülür ve testler tekrar çalıştırılır. Kendi fork branch'ine force-with-lease ile push edilebilir. Shared contribution branch'te aynı işlem dikkat gerektirir.

Contributor Pull Request

PR review başladıktan sonra maintainer ek değişiklik isteyebilir. Contributor normal yeni commit ekleyebilir veya proje policy'sine göre fixup yapabilir. Büyük history rewrite reviewer'a bildirilmelidir. CI yeni SHA üzerinde çalışır. Maintainer final merge yöntemini seçebilir.

Maintainer Workflow

Maintainer contributor branch'inin history'sini doğrudan yeniden yazmak yerine merge platformunu kullanabilir. Squash merge katkıyı tek commit halinde alabilir. Rebase merge atomic commit serisini koruyabilir. Project guidelines hangi yöntemin kullanıldığını açıklamalıdır. Contributor şaşırmamalıdır.

DCO / Signed-off-by

DCO workflow commit mesajında Signed-off-by satırı isteyebilir. Interactive rebase sırasında commit mesajları değişirse bu satırların korunması gerekir. Squash merge yeni commit için farklı davranabilir. CI DCO check çalıştırabilir. Contribution policy açık ve otomatik olmalıdır.

CLA

Contributor License Agreement çoğu zaman kullanıcı veya PR seviyesinde yönetilir. Rebase doğrudan CLA durumunu değiştirmeyebilir. Ancak platform entegrasyonunun nasıl çalıştığı doğrulanmalıdır. Yeni contributor eklenirse ek kontrol gerekebilir. Git history ve legal approval birbirinden ayrı ama bağlantılı süreçlerdir.

Açık Kaynak Commit History Etiği

Contributor'ın commitlerini izinsiz biçimde yeniden yazmak işbirliği açısından sorun yaratabilir. Maintainer merge policy'yi önceden açıklamalıdır. Attribution korunmalıdır. Squash yapılacaksa author ve co-author bilgisi doğru yönetilmelidir. Açık iletişim teknik kurallar kadar önemlidir.

Bot Branch'lerinde Rebase Politikası

Dependency update veya otomatik maintenance botları çok sayıda branch ve PR oluşturabilir. Bot'un branch üzerinde rebase veya force push yapma yetkisi kontrollü tanımlanmalıdır. Main üzerinde hiçbir bot normal şartlarda force push yapmamalıdır. Required checks bot PR'larında da çalışmalıdır. Auto-merge yalnız risk seviyesi ve policy uygun olduğunda açılmalıdır.

Dependabot

Dependency update botları branch'i yeni base ile otomatik güncelleyebilir. Repository platformu kendi kontrollü rebase mekanizmasını kullanabilir. CI dependency değişikliğini doğrular. Major version update için manual review gerekebilir. Bot yetkisi branch pattern ile sınırlandırılmalıdır.

Renovate

Dependency automation araçları birçok PR yönetebilir. Branch update strategy merge, rebase veya recreate olarak yapılandırılabilir. Seçim repository policy ile uyumlu olmalıdır. Bot shared human branch'leri değiştirmemelidir. Security update'leri için farklı priority uygulanabilir.

Automated PR

Generated code veya version bump otomasyonu PR açabilir. PR normal review ve CI sürecinden geçmelidir. Bot tarafından oluşturulması bypass gerekçesi değildir. Commit signing gerekiyorsa bot identity yönetilmelidir. Auto-generated branch kısa ömürlü tutulmalıdır.

Bot'a Force Push Yetkisi

Bot yalnız kendi oluşturduğu branch üzerinde force-with-lease benzeri kontrollü update yapmalıdır. Protected main ve release branch'lerinde force push tamamen kapalı kalmalıdır. Bot token minimum yetki taşımalıdır. Audit log bot işlemlerini göstermelidir. Human-owned branch'e yazma izni verilmemelidir.

Required Checks

Bot PR'ları da test ve security scan'den geçmelidir. Dependency update compile olsa bile runtime davranışını bozabilir. Integration testler önemlidir. Security botu tarafından açılan PR otomatik güvenli kabul edilmemelidir. Final merge policy aynı standardı korumalıdır.

Auto-Merge

Düşük riskli patch update'ler auto-merge edilebilir. Required checks ve approval policy sağlanmalıdır. Major dependency change manual review isteyebilir. Merge queue ile güvenli sıra sağlanabilir. Auto-merge kriterleri policy as code olarak tutulmalıdır.

Git Branch Naming Standardı

Branch naming standardı repository içindeki branch amacını hızlı anlamayı sağlar. İsimde feature, bugfix, hotfix veya release kategorisi bulunabilir. Ticket ID traceability için eklenebilir. Çok uzun ve kişisel branch isimlerinden kaçınmak faydalıdır. Naming rule CI veya repository policy ile otomatik kontrol edilebilir.

feature/

feature/ yeni business veya teknik feature için kullanılabilir. Ardından ticket ID ve kısa açıklama gelebilir. İsim branch'in amacını tek bakışta gösterir. Çok uzun slug gereksizdir. Takım aynı kalıbı tutarlı kullanmalıdır.

bugfix/

bugfix/ normal geliştirme hattındaki bug düzeltmeleri için kullanılabilir. Production acil fix'i hotfix kategorisinden ayrılabilir. Ticket ID eklemek izlenebilirlik sağlar. Branch kısa ömürlü tutulmalıdır. Merge sonrası otomatik silinebilir.

hotfix/

hotfix/ production incident için ayrılabilir. Branch doğru production base'den açılmalıdır. İsimde incident veya ticket numarası bulunabilir. Permission policy daha sıkı olabilir. Fix development hattına geri taşınmalıdır.

release/

release/ belirli sürüm hattını temsil edebilir. İsim version numarası içerebilir. Bu branch shared ve protected kabul edilmelidir. History rewrite kapalı tutulmalıdır. Tag ve deployment record ile ilişkilendirilebilir.

chore/

chore/ dependency, tooling veya bakım işleri için kullanılabilir. Business feature kategorisinden ayrım sağlar. Yine PR ve CI sürecinden geçmelidir. Değişiklik riskine göre reviewer seçilir. Branch tipinin düşük risk garantisi olmadığı unutulmamalıdır.

Ticket ID

Ticket ID branch, commit veya PR içinde bulunabilir. Bu bilgi change request ile source code arasında bağlantı kurar. Her yere aynı ID'yi tekrar yazmak zorunlu olmayabilir. Automation PR metadata üzerinden eşleme yapabilir. Naming standardı kullanılan ticket sistemine göre belirlenir.

İsimlendirme Politikasının Otomatik Kontrolü

CI regex ile branch adını kontrol edebilir. Repository event hook yanlış isimli branch'i uyarabilir. Otomasyon geliştiriciye açık hata mesajı vermelidir. Emergency branch'ler için tanımlı istisna bulunabilir. Policy dokümanda ve code içinde aynı kalmalıdır.

Commit Mesajı Standardı Rebase Yönetimini Nasıl Etkiler?

Anlamlı commit mesajları rebase ve review süreçlerini kolaylaştırır. Interactive rebase sırasında hangi commitlerin squash edileceğine karar vermek daha kolay olur. Atomic commitler conflict bağlamını küçültür. Conventional Commits veya ticket bağlantısı release automation için de kullanılabilir. Commit standardı yalnız estetik değil operasyonel fayda sağlar.

Atomic Commits

Atomic commit tek mantıksal değişikliği taşır. Rebase conflict çıktığında hangi davranışın uygulanmakta olduğu anlaşılır. Git bisect daha anlamlı sonuç verir. Reviewer commit commit ilerleyebilir. Çok büyük “everything” commitlerden kaçınılmalıdır.

Anlamlı Commit Mesajı

Commit mesajı neyin ve neden değiştiğini açıklamalıdır. “update” gibi genel ifadeler debugging sırasında yardımcı olmaz. İlk satır kısa ve açık tutulabilir. Gerekirse body içinde karar gerekçesi yazılabilir. Review ve audit değeri yükselir.

Conventional Commits

Conventional Commits belirli prefix'lerle commit türünü belirtir. Release notes ve semantic version automation için kullanılabilir. Her ekip için zorunlu değildir. Kullanılacaksa CI ile format kontrolü yapılabilir. Interactive rebase sırasında reword bunu düzeltmeye yardımcı olur.

Ticket Bağlantısı

Commit veya PR ticket ile ilişkilendirilebilir. Ticket business context'i taşır. Rebase SHA değiştirirse ticket'ın yalnız commit hash'e bağlı kalmaması faydalıdır. PR ID daha stabil referans olabilir. Final merge commit deployment kaydıyla eşlenebilir.

Squash Öncesi History Cleanup

Squash merge kullanılacaksa her local commitin kusursuz olması gerekmeyebilir. Yine de reviewer commit bazında çalışıyorsa anlamlı history değer sağlar. PR öncesi gereksiz debug commitleri temizlenebilir. Tek commit merge edilecek diye feature branch düzensiz bırakılmamalıdır. Cleanup reviewer deneyimini hedeflemelidir.

Git Policy as Code Nasıl Uygulanır?

Git policy as code branch ve merge kurallarının manuel hatırlatmalar yerine repository ayarları ve otomasyonla uygulanmasını ifade eder. Protected branch, required reviewer ve CI kontrolleri teknik olarak zorunlu hale getirilebilir. Allowed merge methods ekip standardını korur. Force push restriction public history'yi korur. Bu yaklaşım kurumsal Git workflow branch protection ve CI/CD süreç danışmanlığı çalışmalarında temel kontrol alanlarından biridir.

Repository Rulesets

Ruleset branch pattern ve event bazlı kurallar tanımlayabilir. Main, release ve feature branch'ler için farklı policy uygulanabilir. Force push veya direct push sınırlandırılabilir. Required check ve review şartları merkezi yönetilebilir. Policy değişiklikleri audit edilebilir olmalıdır.

Protected Branches

Main ve release branch'ler protected tanımlanmalıdır. Direct push kapatılabilir. Force push yasaklanabilir. Merge yalnız pull request üzerinden yapılabilir. Admin bypass sınırlı tutulmalıdır.

Required Reviewers

Belirli reviewer sayısı veya CODEOWNER approval zorunlu olabilir. Security-sensitive path için daha yüksek kontrol uygulanabilir. Rebase sonrası stale reviews düşürülebilir. Bot approval insan review'un yerine geçmemelidir. Reviewer listesi organizasyon değiştikçe güncellenmelidir.

Required CI

Unit, integration ve security job'ları required yapılabilir. Yeni commit geldiğinde check yeniden çalışmalıdır. Merge queue final integration state üzerinde test yapabilir. Flaky required testler hızlıca düzeltilmelidir. Aksi halde ekip bypass aramaya başlar.

Allowed Merge Methods

Repository yalnız squash merge veya belirli merge yöntemlerine izin verebilir. Ekip tek tutarlı history modeli oluşturur. Rebase merge signing policy ile uyumlu mu kontrol edilmelidir. Merge commit gerekli release branch'lerde ayrıca izinli olabilir. Tek global ayar yerine repository bağlamı düşünülmelidir.

Signed Commit Requirement

Signed commit zorunluysa local ve server-side workflow test edilmelidir. Bot ve automation identity'leri de signing yapabilmelidir. Rebase sonrası yeni commitler imzalanmalıdır. Key management prosedürü bulunmalıdır. Signature validation merge gate'e eklenebilir.

Force Push Restrictions

Main, develop ve release branch için force push kapalı olmalıdır. Personal feature branch'lerde kullanıcıya esneklik verilebilir. Shared feature branch için daha sıkı pattern uygulanabilir. Server policy local alias'tan daha güvenlidir. Olağanüstü bypass audit logda görünmelidir.

Branch Naming Rules

Branch pattern CI veya server hook ile kontrol edilebilir. Feature, bugfix ve hotfix prefix'leri standardize edilir. Ticket ID gerektiğinde zorunlu tutulabilir. Bot branch'leri ayrı namespace kullanabilir. Naming policy geliştirici deneyimini gereksiz zorlaştırmamalıdır.

Örnek Kurumsal Rebase Politikası

Örnek bir kurumsal rebase politikası private history'de esnek, public history'de ise korumacı olmalıdır. Main üzerinde direct ve force push tamamen kapatılır. Shared feature ve release branch'lerde history rewrite varsayılan olarak yasaklanır. Personal feature branch rebase edilebilir ancak force-with-lease kullanılmalıdır. Rebase sonrası CI ve gerekli review tekrar güncellenmelidir.

main

Main repository'nin güvenilir entegrasyon hattıdır. Her değişiklik PR üzerinden gelmelidir. History immutable tutulmalıdır. CI ve review merge için zorunlu olabilir. Emergency süreçler bile kayıtlı bypass kullanmalıdır.

Direct Push Yasak

Developer main'e doğrudan commit push etmemelidir. PR review ve CI olmadan kod ana hatta girmemelidir. Service account gerekiyorsa yalnız belirli automation işi için yetkilendirilmelidir. Direct push yasağı repository server tarafından uygulanmalıdır. Dokümantasyon tek başına yeterli değildir.

Force Push Yasak

Main pointer hiçbir normal workflow'da geriye veya farklı history'ye zorlanmamalıdır. Yanlış değişiklik revert ile düzeltilmelidir. Force push deployment traceability'yi bozar. Branch protection teknik engel koymalıdır. Admin override olay kaydına girmelidir.

PR Zorunlu

Main entegrasyonu pull request üzerinden yapılmalıdır. Required reviewer ve CI burada devreye girer. PR business context'i de saklar. Ticket ve deployment kayıtları PR ile bağlanabilir. Merge method repository policy'ye göre seçilir.

release/

Release branch belirli sürüm history'sini taşır. Birden fazla kişi ve pipeline bu commitlere referans verebilir. History rewrite yüksek risklidir. Fix'ler yeni commit olarak eklenmelidir. Release tag immutable tutulmalıdır.

History Rewrite Yasak

Rebase ve force push release branch için kapalı tutulmalıdır. Cherry-pick veya merge backport için kullanılabilir. Yeni release candidate yeni SHA olarak test edilir. Eski candidate history'den silinmez. Audit izi korunur.

Shared feature/

İki veya daha fazla geliştiricinin kullandığı feature branch shared kabul edilir. Bu branch'in commitleri başka local history'lerin parent'ı olabilir. Rebase coordination maliyeti yaratır. Normal merge veya pull ile güncelleme tercih edilmelidir. Branch mümkün olduğunca kısa tutulmalıdır.

Force Push Varsayılan Olarak Yasak

Shared feature branch üzerinde force push başka kişinin commitini kaybettirebilir. Server policy bunu engelleyebilir. Özel recovery gerekiyorsa ekip koordinasyonu şarttır. Backup branch alınmalıdır. Günlük workflow'da force push gerekmemelidir.

Personal feature/

Tek geliştiricinin kullandığı feature branch daha esnek policy alabilir. Developer PR öncesi history cleanup yapabilir. Main üzerine rebase edebilir. Branch shared hale geldiğinde bu esneklik sona erer. Ownership kuralı açık olmalıdır.

Rebase Serbest

Kişisel branch üzerinde rebase yapılabilir. Interactive cleanup PR öncesinde tercih edilebilir. Rebase sonrası testler çalıştırılmalıdır. Review başladıysa reviewer bilgilendirilmelidir. History rewrite yalnız branch owner'ını etkilediği sürece güvenlidir.

Force-with-Lease Zorunlu

Remote branch güncellenecekse normal force push kullanılmamalıdır. Force-with-lease remote'un beklenmedik biçimde ilerlemediğini kontrol eder. Push reddedilirse önce remote değişiklik incelenmelidir. Branch artık shared olabilir. Bu kontrol veri kaybı riskini azaltır.

Merge Öncesi

Merge öncesi final code state güncel target branch ile doğrulanmalıdır. Rebase yapıldıysa yeni SHA ortaya çıkmıştır. CI ve security checks yeniden çalışmalıdır. Conflict çözümü önemliyse review yenilenmelidir. Merge queue bu final aşamayı otomatikleştirebilir.

CI Yeniden Çalışmalı

Eski pipeline yeni HEAD'i doğrulamaz. Unit ve integration testler tekrar çalışmalıdır. Required checks current SHA ile eşleşmelidir. Security scan de gerekiyorsa yenilenmelidir. Merge yalnız güncel status ile yapılmalıdır.

Gerekirse Approval Yenilenmeli

Rebase sırasında patch değiştiyse eski approval geçersiz sayılmalıdır. Conflict çözümü review gerektirebilir. Repository stale review dismissal kullanabilir. Küçük base update için risk bazlı policy uygulanabilir. Reviewer hangi değişikliklerin yeni olduğunu görmelidir.

Kurumsal Ekiplerde Önerilen Git Workflow

Kurumsal ekipler için pratik Git workflow mümkün olduğunca kısa branch ve otomatik quality gate üzerine kurulabilir. Geliştirici güncel main üzerinden feature branch açar ve küçük atomic commitlerle ilerler. PR öncesinde gerekiyorsa kişisel history temizlenir ve main üzerine rebase edilir. CI ve review tamamlandıktan sonra repository politikasına uygun merge yöntemi kullanılır. Branch merge sonrasında silinerek repository temiz tutulur.

1. Güncel Main'den Feature Branch Aç

İşe başlamadan önce remote main fetch edilir. Feature branch güncel referans üzerinden oluşturulur. Yanlış veya eski base conflict riskini artırabilir. Branch adı naming standardına uymalıdır. Ticket ID gerekiyorsa isimde bulunabilir.

2. Küçük Atomic Commit'ler Yap

Her commit tek mantıksal değişikliği temsil etmelidir. Refactor ve feature behavior mümkünse ayrılmalıdır. Anlamlı mesaj kullanılmalıdır. Commitler mümkünse testleri geçer durumda tutulmalıdır. Review ve bisect deneyimi iyileşir.

3. Branch'i Kısa Ömürlü Tut

Feature birkaç küçük PR'a bölünebilir. Branch birkaç gün içinde merge edilmeye çalışılır. Büyük feature feature flag arkasında incremental taşınabilir. Main divergence düşer. Rebase ve conflict ihtiyacı azalır.

4. PR Öncesi Lokal History'yi Temizle

WIP ve debug commitleri düzenlenebilir. Interactive rebase yalnız private history üzerinde yapılır. Commit mesajları review edilebilir hale getirilir. Gereksiz dosyalar çıkarılır. Testler cleanup sonrasında çalıştırılır.

5. Main Üzerine Rebase Et

Gerekliyse feature branch origin/main üzerine rebase edilir. Branch shared ise bu adım kullanılmamalıdır. Conflictler dikkatle çözülür. Range-diff ile patch serisi kontrol edilebilir. New HEAD üzerinde testler tekrar çalıştırılır.

6. Force-with-Lease ile Güncelle

Remote personal feature branch history'si değiştiği için controlled force push gerekebilir. --force-with-lease kullanılmalıdır. Remote beklenmedik biçimde ilerlemişse işlem durur. Normal force push kullanılmaz. Branch shared olduysa ekip farklı entegrasyon yöntemi seçer.

7. CI ve Security Testlerini Çalıştır

Unit, integration ve gerekli security checks yeni HEAD üzerinde çalışır. Pipeline sonucu merge için zorunlu olabilir. Flaky testler retry ile saklanmamalıdır. Dependency veya secret scan repository riskine göre eklenir. Final artifact build aynı source state'e bağlı olmalıdır.

8. Code Review Al

Reviewer PR'ın business ve teknik amacını görür. Küçük PR review hızını artırır. CODEOWNERS gerekli alanlara otomatik atanabilir. Rebase sonrası önemli değişiklik varsa reviewer bilgilendirilir. Approval güncel commit serisi üzerinde verilmelidir.

9. Repository Politikasına Göre Merge Et

Squash, rebase merge veya merge commit repository standardına göre kullanılır. Geliştirici kişisel tercihle yöntem değiştirmemelidir. Merge queue varsa PR sıraya alınır. Final integration CI'dan geçer. Main history protected kalır.

10. Feature Branch'i Sil

Merge tamamlandıktan sonra feature branch artık gerekli değildir. Remote branch otomatik silinebilir. Local branch cleanup geliştirici tarafından yapılabilir. Açık child branch varsa önce dependency kontrol edilmelidir. Stale branch sayısı böylece düşük tutulur.

Git Branch Stratejisi İçin Takım Olgunluk Modeli

Takımın Git olgunluğu yalnız hangi branch modelini kullandığıyla ölçülmez. Asıl fark kuralların ne kadar açık, otomatik ve ölçülebilir olduğunda görülür. İlk seviyede herkes farklı alışkanlıkla çalışabilir. Daha ileri seviyelerde protected main, CI, rebase policy ve merge queue devreye girer. En olgun yapı gerçek metriklere göre workflow'u sürekli iyileştirir.

Seviye 0 — Kuralsız Branch Kullanımı

Developer istediği branch'ten branch açar. Direct push ve force push yaygın olabilir. Merge yöntemi kişiye göre değişir. CI zorunlu değildir. Incident sonrası hangi commitin ne yaptığını anlamak zorlaşabilir.

Seviye 1 — Feature Branch + PR

Takım feature branch ve pull request kullanmaya başlar. Review ortak süreç haline gelir. Ancak main protection veya required CI henüz zayıf olabilir. Rebase davranışı kişilere göre değişebilir. Bir sonraki adım server-side policy eklemektir.

Seviye 2 — Protected Main + CI

Main direct push ve force push'a kapatılır. PR zorunlu hale gelir. Required testler merge öncesinde çalışır. Reviewer approval gerekir. Public history daha güvenilir hale gelir.

Seviye 3 — Standart Rebase/Merge Policy

Hangi branch'te rebase yapılabileceği açıkça tanımlanır. Personal ve shared branch ayrımı yapılır. Force-with-lease standart hale gelir. Allowed merge methods repository policy ile sınırlandırılır. Rebase sonrası CI ve approval kuralları belirlenir.

Seviye 4 — Merge Queue + Policy as Code

Repository rulesets policy'yi otomatik uygular. Merge queue main yarışını yönetir. CODEOWNERS ve stale review kuralları devreye girer. Bot ve service account yetkileri kontrollüdür. Manuel süreç hataları azalır.

Seviye 5 — Ölçülen ve Otomatik Yönetilen Git Workflow

Takım branch age, time to merge ve conflict rate gibi metrikleri izler. Workflow değişiklikleri veriyle değerlendirilir. CI maliyeti ve merge queue throughput'u ölçülür. Stale branch cleanup otomatikleşir. Git policy yaşayan engineering sistemi haline gelir.

Git Workflow İçin Hangi Metrikler Takip Edilmeli?

Git workflow iyileştirmesi yalnız geliştirici hissine bırakılmamalıdır. Ortalama branch yaşı ve pull request boyutu entegrasyon davranışını gösterir. Time to merge review ve CI darboğazlarını ortaya çıkarabilir. Conflict ve force push oranları rebase politikasının sağlığını gösterir. Change failure rate ise workflow'un production sonuçlarıyla bağlantısını kurar.

Ortalama Branch Yaşı

Branch'in açılış ile merge arasındaki süresi ölçülür. Yüksek değer uzun divergence işaretidir. Ortalama yanında dağılım ve yüzde 95 değerine bakılabilir. Bazı release branch'ler metric dışında tutulmalıdır. Feature branch trendi ana sinyaldir.

Ortalama Pull Request Boyutu

Changed lines ve file count PR büyüklüğünü gösterebilir. Çok büyük PR review süresini artırır. Ancak generated code metric'i bozabilir. Modül bazında normal değerler farklı olabilir. Trend küçük değişiklik kültürünü ölçmek için kullanılabilir.

Time to Merge

PR açılışından merge'e kadar geçen süre ölçülür. Uzun süre reviewer eksikliği, CI yavaşlığı veya scope büyüklüğünü gösterebilir. İlk review süresi ayrıca ölçülebilir. Metric geliştiriciyi acele merge etmeye zorlamamalıdır. Ama darboğazları görünür kılar.

Merge Conflict Rate

Kaç PR'ın merge öncesinde conflict yaşadığı takip edilebilir. Yüksek oran branch'lerin fazla uzun yaşadığını gösterebilir. Monorepo hotspot dosyalar da nedeni olabilir. Ekip dosya bazlı analiz yapabilir. Conflict rate düşüşü kısa branch stratejisinin faydasını gösterebilir.

Rebase Conflict Rate

Rebase sırasında conflict yaşayan branch oranı ayrıca izlenebilir. Çok sık rebase ve yüksek conflict birlikte kötü sinyal olabilir. Branch age ile korelasyon incelenebilir. Kök neden büyük feature veya sık shared file değişimi olabilir. Metric process improvement için kullanılır.

Force Push Sayısı

Force push eventleri audit log üzerinden ölçülebilir. Main ve release için sayı ideal olarak sıfır olmalıdır. Personal feature branch sayısı normal olabilir. Normal force ve force-with-lease ayrımı mümkünse takip edilmelidir. Ani artış rebase policy sorunu gösterebilir.

Stale Branch Sayısı

Belirli süredir commit almayan branch'ler stale kabul edilebilir. Fazla stale branch repository hygiene sorununu gösterir. Owner'lara otomatik bildirim gönderilebilir. Merge edilmiş branch'ler hızlı silinmelidir. Release ve long-lived maintenance branch'ler farklı sınıflandırılmalıdır.

PR Rework Rate

Review sonrası ne kadar yeniden çalışma gerektiği ölçülebilir. Büyük PR veya belirsiz requirement yüksek rework üretebilir. Rebase sonrası repeated review de metric'e etki edebilir. Hedef reviewer feedback'ini azaltmak değil daha erken almak olmalıdır. Draft PR bu konuda yardımcı olabilir.

Change Failure Rate

Production'a çıkan değişikliklerin ne kadarı incident, rollback veya hotfix gerektiriyor ölçülebilir. Bu metric Git workflow'un gerçek sonuç kalitesiyle ilişkisini gösterir. Branch strategy tek neden değildir. Test, review ve deployment süreçleri birlikte değerlendirilmelidir. Düşük conflict oranı tek başına başarılı delivery anlamına gelmez.

En Sık Yapılan Rebase Hataları

Rebase hatalarının büyük bölümü komutun kendisinden değil yanlış history üzerinde uygulanmasından kaynaklanır. Main veya shared branch'i rebase etmek en yüksek riskli davranışlardan biridir. Normal force push veri kaybına yol açabilir. Review başladıktan sonra büyük history rewrite reviewer zamanını boşa çıkarabilir. En iyi rebase politikası rebase ihtiyacını kısa branch ve otomasyonla mümkün olduğunca azaltan politikadır.

main Branch'i Rebase Etmek

Main public history'dir ve yeniden yazılmamalıdır. CI, deployment ve ticket kayıtları SHA'lara bağlı olabilir. Rebase tüm bu referansları etkiler. Yanlış commit revert edilmelidir. Branch protection force push'u engellemelidir.

Shared Branch History'sini Yeniden Yazmak

Shared branch başka geliştiricilerin local history'sinin temelidir. Rebase SHA'ları değiştirir. Force push diğer çalışmalarla uyuşmazlık oluşturur. Merge veya normal update daha güvenlidir. Shared branch mümkün olduğunca kısa ömürlü tutulmalıdır.

git push --force Kullanmak

Normal force push remote değişikliği kontrol etmez. Başka commitleri branch history'sinden düşürebilir. Personal rebase branch için force-with-lease kullanılmalıdır. Public branch'te ikisi de kapalı olmalıdır. Server-side protection asıl güvenlik katmanıdır.

Rebase Sonrası Test Çalıştırmamak

Rebase yeni main değişikliklerini feature ile birleştirir. Conflict olmasa bile semantic interaction oluşabilir. Eski CI sonucu yeterli değildir. Yeni HEAD test edilmelidir. Critical integration ve security checks tekrar çalışmalıdır.

Review Ortasında Büyük Interactive Rebase Yapmak

Büyük rewrite reviewer context'ini bozar. Eski commentler outdated hale gelir. Approval geçerliliğini kaybedebilir. Cleanup mümkünse PR öncesinde yapılmalıdır. Zorunlu rewrite sonrası reviewer açıkça bilgilendirilmelidir.

Conflict'i Anlamadan Çözmek

Conflict marker'larını kaldırmak doğru çözüm anlamına gelmez. İki tarafın business niyeti anlaşılmalıdır. Semantic conflict testlerde bile kaçabilir. CODEOWNER yardımı gerekebilir. Çözüm sonrası review ve test yapılmalıdır.

Rebase Sonrası Approval'ları Olduğu Gibi Kabul Etmek

Approval eski SHA üzerinde verilmiş olabilir. Conflict çözümü yeni code oluşturabilir. Stale review policy bu nedenle önemlidir. Riskli değişiklik tekrar onaylanmalıdır. Final approval güncel HEAD ile eşleşmelidir.

Signed Commit Politikasını İhmal Etmek

Rebase eski signature'ları korumayabilir. Yeni commitler yeniden imzalanmalıdır. Server-side merge davranışı kontrol edilmelidir. Bot ve automation identity'leri de policy'ye uymalıdır. Signature requirement CI veya repository tarafından doğrulanmalıdır.

Release Branch'ini Rebase Etmek

Release history deployment ve audit kayıtlarıyla ilişkilidir. Rebase bu commitlerin SHA'larını değiştirir. Backport için cherry-pick daha uygundur. Release branch protected ve immutable tutulmalıdır. New fix yeni commit olarak eklenmelidir.

Çok Uzun Ömürlü Feature Branch Kullanmak

Uzun branch main'den hızla uzaklaşır. Conflict ve rebase maliyeti büyür. Review scope genişler. Feature küçük parçalar ve flags ile main'e taşınabilir. Branch age metriği problemi görünür hale getirir.

Branch Stratejisini Release Modelinden Bağımsız Seçmek

Branch strategy deployment ve support modelinden ayrı düşünülemez. Günde birçok release yapan ekip ağır GitFlow süreçleriyle zorlanabilir. Uzun süre desteklenen sürümler ise release branch gerektirebilir. CI ve feature flag kapasitesi de kararı etkiler. Workflow gerçek ürün akışıyla uyumlu olmalıdır.

Linear History'yi Amaç Haline Getirmek

Linear log kullanışlı olabilir ama nihai kalite hedefi değildir. Bu hedef uğruna shared branch rebase edilmemelidir. Server-side squash ve merge queue daha güvenli seçenekler sunabilir. History güvenilir ve izlenebilir olmalıdır. Görsel sadelik ikinci plandadır.

Sık Sorulan Sorular

Git Branch Stratejileri: Kurumsal Ekiplerde Doğru Rebase Yönetimi hakkında en çok sorulan sorular genellikle rebase'in güvenli sınırı, merge yöntemi ve branch koruma kuralları etrafında toplanır. Rebase güçlü bir araçtır fakat her branch için uygun değildir. Private feature history ile public main history aynı kurallarla yönetilmemelidir. CI, review ve deployment kayıtları commit SHA değişikliklerini doğru ele almalıdır. Aşağıdaki cevaplar ekiplerin günlük kararlarında kullanabileceği kısa bir referans sunar.

Git rebase nedir?

Git rebase commitleri farklı bir base üzerine yeniden uygulayan history değişikliği işlemidir. Commit parent bilgisi değiştiği için yeni SHA'lar oluşur. Private feature branch'i güncel main üzerine taşımak için kullanışlıdır. Public history üzerinde risklidir. Rebase sonrasında test ve history kontrolü yapılmalıdır.

Merge ile rebase arasındaki fark nedir?

Merge mevcut commitleri değiştirmeden history çizgilerini birleştirir. Rebase commitleri yeni base üzerinde yeniden oluşturur. Merge branch topology'yi korur. Rebase daha linear history oluşturabilir. Shared history için merge daha güvenlidir.

Rebase ne zaman kullanılmalıdır?

Rebase en güvenli biçimde kişisel feature branch üzerinde kullanılmalıdır. PR öncesinde main ile güncelleme veya history cleanup için uygundur. Shared branch'te varsayılan olarak kullanılmamalıdır. Review başladıktan sonra büyük rewrite sınırlanmalıdır. Her rebase sonrası CI yeniden çalışmalıdır.

Main branch rebase edilir mi?

Hayır, kurumsal workflow'da main branch rebase edilmemelidir. Main public history olarak kabul edilir. Deployment ve CI kayıtları bu commitlere bağlıdır. History rewrite traceability sorununa yol açar. Force push branch protection ile kapatılmalıdır.

Feature branch main üzerine nasıl rebase edilir?

Önce remote git fetch origin ile güncellenir. Feature branch üzerinde git rebase origin/main çalıştırılır. Conflict varsa dikkatle çözülür ve git rebase --continue ile ilerlenir. Testler tamamlandıktan sonra history kontrol edilir. Private remote branch --force-with-lease ile güncellenebilir.

Rebase neden commit SHA'yı değiştirir?

Commit SHA yalnız file content'e bağlı değildir. Parent commit ve metadata da hash hesaplamasının parçasıdır. Rebase parent zincirini değiştirir. Bu nedenle yeni commit nesneleri oluşur. Eski ve yeni commit patch açısından benzer olsa bile Git açısından farklıdır.

Force push neden tehlikelidir?

Force push remote branch pointer'ını local history'ye zorlayabilir. Başka geliştiricinin yeni commitleri branch'ten düşebilir. Review ve CI history'si değişebilir. Main ve shared branch'te kullanılmamalıdır. Personal branch için bile force-with-lease tercih edilmelidir.

Force-with-lease nedir?

Force-with-lease push öncesinde remote branch'in beklenen durumda olup olmadığını kontrol eder. Başka commit gelmişse push reddedilebilir. Normal force push'a göre daha güvenlidir. Ancak history rewrite gerçeğini ortadan kaldırmaz. Shared branch için yine uygun değildir.

Rebase sonrası CI tekrar çalışmalı mı?

Evet, yeni commit SHA farklı code state olarak değerlendirilmelidir. Main değişiklikleri feature ile yeni interaction oluşturabilir. Eski pipeline sonucu yeni HEAD için geçerli kabul edilmemelidir. Required checks yeniden çalışmalıdır. Merge ancak güncel CI sonucu başarılı olduğunda yapılmalıdır.

Rebase sonrası code review tekrar edilmeli mi?

Bu karar değişiklik kapsamına bağlıdır. Conflict çözümü veya interactive rewrite varsa yeniden review güçlü biçimde önerilir. Salt base update daha düşük riskli olabilir. Repository stale approval policy uygulayabilir. Reviewer rebase sonrası farklar konusunda bilgilendirilmelidir.

Squash merge mi rebase merge mi daha iyi?

Tek bir evrensel seçim yoktur. Squash merge PR başına tek temiz commit sağlar. Rebase merge anlamlı atomic commitleri koruyabilir. Commit disiplininin zayıf olduğu ekiplerde squash daha sade olabilir. Audit ve debugging ihtiyacı seçimde dikkate alınmalıdır.

GitFlow'da rebase kullanılmalı mı?

GitFlow'da rebase yalnız kişisel feature history'de kontrollü kullanılabilir. Develop, main ve release gibi shared branch'ler rebase edilmemelidir. Feature branch develop üzerine güncellenebilir. Shared feature branch için merge daha güvenlidir. Policy branch rolüne göre açıkça tanımlanmalıdır.

Trunk-Based Development'ta rebase gerekli midir?

Trunk yaklaşımında branch'ler çok kısa yaşadığı için rebase ihtiyacı doğal olarak azalır. Kısa feature branch güncel main üzerine rebase edilebilir. Ancak main rebase edilmez. Merge queue manuel rebase döngüsünü daha da azaltabilir. Asıl hedef sık entegrasyondur.

Protected branch üzerinde force push yapılmalı mı?

Normal durumda hayır. Main ve release gibi protected branch'lerde force push kapalı tutulmalıdır. Emergency recovery için çok sınırlı admin bypass düşünülebilir. Bu işlem audit loga girmelidir. Günlük workflow force push'a ihtiyaç duymamalıdır.

Yanlış rebase nasıl geri alınır?

git reflog ile rebase öncesi commit bulunabilir. Önce recovery branch oluşturmak güvenlidir. Ardından gerekirse branch eski commit'e reset edilebilir. ORIG_HEAD bazı durumlarda yardımcı olabilir. Remote force push yapılmışsa başka clone'lar recovery kaynağı olabilir.

Kurumsal ekipler için en iyi Git branch stratejisi hangisidir?

Tek bir en iyi model yoktur. Sık deployment ve güçlü CI kullanan ekipler kısa branch veya Trunk-Based Development yaklaşımından fayda görebilir. Birden fazla eski sürüm destekleyen ekipler release branch kullanabilir. GitFlow, GitHub Flow ve Trunk-Based Development seçimi release modeli, test otomasyonu ve audit ihtiyacına göre yapılmalıdır. İyi strateji en az branch sayısına değil güvenli ve hızlı entegrasyona odaklanır.

Git Branch Stratejileri ve Rebase Yönetimi Hakkında Ek Sorular

Kurumsal ekiplerde branch ve rebase yönetimi yalnız Git komutlarını bilmekten ibaret değildir. Repository protection, CI/CD, review, release ve deployment traceability aynı çalışma modelinin parçalarıdır. Git Branch Stratejileri: Kurumsal Ekiplerde Doğru Rebase Yönetimi yaklaşımında en önemli ayrım private history ile shared history arasındaki sınırdır. Bu ayrım doğru yapıldığında rebase faydalı bir cleanup ve senkronizasyon aracına dönüşür. Yanlış yapıldığında ise force push, stale review ve audit sorunları ortaya çıkar.

Kurumsal yazılım ekiplerinde doğru Git branch stratejisi nasıl belirlenir?

Önce takımın release sıklığı, desteklenen sürümleri ve CI/CD kapasitesi değerlendirilmelidir. Sık deployment yapan ekiplerde kısa branch ve trunk yaklaşımı güçlü adaydır. Ayrı sürümlerin uzun süre desteklendiği ürünlerde release branch gerekebilir. Test otomasyonu ve feature flag desteği kararın önemli parçasıdır. Kurumsal yazılım ekiplerinde Git branch ve rebase stratejisi nasıl belirlenir sorusunun cevabı branch sayısından çok entegrasyon süresi ve release modelinde bulunur.

Git rebase ile merge arasındaki fark nedir ve hangi durumlarda rebase tercih edilmelidir?

Merge mevcut commit history'sini değiştirmeden iki geliştirme hattını birleştirir. Rebase commitleri yeni base üzerinde yeniden oluşturduğu için SHA değerlerini değiştirir. Rebase kişisel feature branch'i main üzerine taşımak veya PR öncesi history cleanup yapmak için uygundur. Shared, main veya release branch'lerde merge daha güvenli seçimdir. Git rebase merge ve squash merge yöntemleri arasındaki farklar değerlendirilirken history görünümünün yanında audit ve review etkileri de düşünülmelidir.

Paylaşılan branch’lerde rebase kullanırken commit geçmişinin bozulması ve merge conflict riskleri nasıl önlenir?

En güvenli yöntem shared branch history'sini rebase etmemektir. Birden fazla geliştiricinin kullandığı branch public history olarak kabul edilmelidir. Force push server tarafından engellenebilir. Branch kısa tutulmalı ve main değişiklikleri merge ile alınmalıdır. Zorunlu history rewrite yalnız tüm kullanıcıların koordinasyonu, backup branch ve açık recovery planıyla yapılmalıdır.

GitFlow, GitHub Flow ve Trunk-Based Development stratejilerinde rebase süreci nasıl yönetilmelidir?

GitFlow'da main, develop ve release branch'leri shared olduğu için rebase edilmemelidir. GitHub Flow'da kişisel feature branch güncel main üzerine rebase edilebilir. Trunk-Based Development'ta branch'ler çok kısa yaşadığı için rebase ihtiyacı daha sınırlıdır. Merge queue yoğun repository'lerde manuel rebase ihtiyacını azaltabilir. GitFlow trunk-based development ve GitHub Flow branch stratejileri karşılaştırması yapılırken rebase her modelin merkezi unsuru değil, branch ownership'e bağlı yardımcı operasyon olarak değerlendirilmelidir.

Git branch stratejileri ve rebase yönetimi konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Git branch rebase ve DevOps danışmanlığı yakınımda şeklinde araştırma yapan ekipler yalnız Git komutlarına değil gerçek repository politikalarına odaklanan çalışmaları tercih etmelidir. Diyarbakır Yazılım Topluluğu hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresi incelenebilir. Proje ve uygulama odaklı çalışmalar için https://www.diyarbakiryazilim.com.tr/projects sayfasına göz atılabilir. Kurumsal Git workflow branch protection ve CI/CD süreç danışmanlığı kapsamında özellikle protected main, force-with-lease, merge queue, stale approval ve deployment traceability birlikte değerlendirilmelidir. Teorik eğitimden sonra örnek repository üzerinde gerçek policy as code kuralları uygulamak öğrenme sürecini daha kalıcı hale getirir.

Sonuç: Git Branch Stratejileri: Kurumsal Ekiplerde Doğru Rebase Yönetimi

Sağlıklı Git yönetimi daha fazla branch veya daha fazla rebase yapmak anlamına gelmez. Asıl hedef geliştiricilerin kodu hızlı paylaşabildiği, review ve CI sürecinin güvenilir çalıştığı ve public history'nin kontrol altında kaldığı bir workflow kurmaktır. Git Branch Stratejileri: Kurumsal Ekiplerde Doğru Rebase Yönetimi için en uygulanabilir başlangıç noktası main ve release history'sini immutable tutmak, feature branch'leri kısa ömürlü hale getirmek ve kişisel branch rebase işlemlerinde force-with-lease kullanmaktır. Merge queue, protected branch, stale approval ve required CI gibi kontroller büyüyen ekiplerde bu yaklaşımı teknik olarak güçlendirir. Ekibinizde Git, DevOps, branch protection, rollback veya CI/CD süreçlerini proje üzerinden geliştirmek istiyorsanız https://www.diyarbakiryazilim.com.tr adresinden Diyarbakır Yazılım Topluluğu çalışmalarına ulaşabilirsiniz.