Shopify temasında sürüm yönetimi: kim, ne zaman, neyi değiştirdi?

Tema kütüphanesindeki “kopya 3 SON” temaları bir düzen değil. Kütüphane kopyasından Shopify CLI'a, oradan GitHub entegrasyonuna kadar üç düzeyi, hangi mağazanın hangisinde durması gerektiğini ve yayın akışını yazdık.

Bakım yazısında yayındaki temaya doğrudan dokunulmadığını, değişikliğin kopyada yapıldığını yazmıştık. Bu yazı o cümlenin arkasını dolduruyor: kopya nerede yetmiyor, yerine ne kuruluyor ve bunun mağazaya maliyeti ne?

Sorunun kendisi hemen her mağazada aynı biçimde ortaya çıkıyor. Tema kütüphanesinde birbirine benzeyen yedi tema var: “Dawn kopya”, “Dawn kopya 2”, “yeni kampanya SON”, “yedek 12.03”. Hangisinin yayındaki temayla aynı olduğunu, aradaki farkı kimin ne zaman yazdığını kimse bilmiyor. Bir sorun çıktığında geri dönülecek nokta belli değil; belli olsa bile o noktaya dönmenin bugünkü içerik ayarlarını da geri alacağı biliniyor.

Sürüm yönetimi, bu belirsizliği ortadan kaldıran düzenin adı. Büyük bir ekip işi değil; tek kişilik bir mağazada bile kurulabiliyor.

Üç düzey var, hepsi herkese gerekmiyor

Sürüm yönetimini tek bir şey olarak anlatmak yanlış olur. Pratikte üç düzey var ve mağazalar genellikle bir üstüne ihtiyaç duyduğunda değil, bir alt düzeyde canı yandığında yukarı çıkıyor.

Ayrımın ölçütü mağazanın cirosu değil, temaya kod yazılıp yazılmadığı ve temaya dokunan kişi sayısı. Tema koduna hiç dokunulmayan, tek kişinin panelden yönettiği bir mağazada birinci düzey yeterli. İki kişinin aynı hafta içinde aynı dosyaya dokunduğu bir mağazada birinci düzey artık düzen değil, kaza bekleme biçimi.

Düzey 1: kütüphane kopyası nereye kadar götürür?

Kopya yöntemi ücretsiz, hızlı ve çoğu mağaza için doğru başlangıç. Ama üç yerde tıkanıyor.

Buna rağmen ilk düzeyde kalmayı seçen mağazalarda tek bir kural farkı büyük iş görüyor: kopyaların adı tarih ve sebep içersin. “Dawn kopya 3” yerine “2026-08-14 kargo eşiği rozeti” yazılan bir kütüphane, altı ay sonra hâlâ okunabiliyor.

Düzey 2: yerel dosyalar ve Shopify CLI

Temaya kod yazılmaya başlandığı anda işin merkezi panelden çıkıp bilgisayara geçiyor. Shopify'ın komut satırı aracı bu akışın tamamını karşılıyor:

Bu düzeyin asıl kazancı komutlar değil, dosyaların bir depoda durması. Değişiklik satır satır görünür oluyor, her değişikliğin bir açıklaması ve sahibi oluyor, geri dönüş tek bir işleme dönüşüyor. Kütüphanedeki tema sayısı da kendiliğinden azalıyor; çünkü geçmişi tutan yer artık kütüphane değil.

Düzey 3: GitHub entegrasyonu

Shopify, bir Git deposundaki dalı doğrudan bir temaya bağlamanıza izin veriyor. Bağlantı çift yönlü çalışıyor ve pratikte en çok yanlış anlaşılan yer burası:

Bir uyarı da çakışma tarafında: kod editörü çakışma bildirmiyor, oradaki sürüm depodaki sürümün üzerine yazıyor. İki taraftan aynı anda düzenleme yapıldığında Shopify'ın ürettiği işlemin GitHub tarafından geride kaldığı gerekçesiyle reddedilmesi de mümkün. Bu yüzden entegrasyon kurulan mağazalarda basit bir kural koyuyoruz: kod tarafına yalnızca depodan girilir, panelden yalnızca içerik ve ayar düzenlenir.

Bu düzeyin en pratik faydası ise inceleme: değişiklik yayına girmeden önce bir başkasının okuyabileceği bir yerde duruyor. Tek kişilik ekiplerde bile bu, “yayına aldıktan sonra fark etme” alışkanlığını kırıyor.

Dal düzeni: sade tutun

Karmaşık dallanma şemaları e-ticaret temalarında genellikle işe yaramıyor. Kullandığımız düzen üç dallı:

Kampanya dönemlerinde bir kural daha ekliyoruz: kampanya başlamadan 48 saat önce ana dal kapanır, yalnızca hata düzeltmesi girer. Kampanya günü yapılan “küçük bir düzeltme”nin bedeli, kampanya dışı bir günde yapılanla aynı değil.

İçerik ve kod ayrımı

Sürüm yönetimini karıştıran asıl mesele şu: temanın içinde iki farklı şey var. Bir tarafta kod, diğer tarafta tema editöründen yapılan ayarlar ve sayfa içerikleri. İkisi aynı dosya yapısında duruyor ama aynı ritimde değişmiyor.

Bu yüzden geri alma her zaman “eski temayı yayınla” demek değil. Yalnızca kodu geri almak gerektiğinde depodaki değişikliği geri alıyoruz; içerik ayarları yerinde kalıyor. Eski temayı yayınlamak ise ancak tema bütünüyle bozulduğunda başvurduğumuz yöntem — çünkü o gün yapılan içerik düzenlemeleri de birlikte geri gidiyor.

Yayın akışı

Düzey ne olursa olsun yayın adımları aynı kalıyor; değişen yalnızca her adımın hangi araçla yapıldığı.

Son madde en sık atlanan ama en çok işe yarayan adım. Altı ay sonra “bu kod neden buraya konmuş?” sorusuna cevap veren şey, kodun kendisi değil o tek satır oluyor.

Devir teslim: asıl sınav

Sürüm yönetiminin kurulup kurulmadığını anlamanın en kısa yolu şu soruyu sormak: yarın başka bir ekip devralsa, ne kadar sürede çalışmaya başlar?

Bu maddeler bizde ilkesel: yaptığımız işin ajansta kilitli kalması müşteri için risk, ilişki için sağlıksız bir bağ. Depo müşterinin hesabında açılır, erişim iş bitiminde devredilir.

Yapmadığımız şeyler

Özet

Sürüm yönetimi bir araç seçimi değil, “geri dönebilir miyiz?” sorusuna önceden verilmiş bir cevap. Tema koduna dokunulmayan mağazada adı düzgün konmuş bir kopya yeterli; kod yazılan mağazada dosyalar depoya taşınıyor; birden fazla kişinin dokunduğu mağazada dal doğrudan temaya bağlanıyor. Üçünde de değişmeyen şey aynı: yayına giren her şeyin bir sahibi, bir sebebi ve bir geri dönüş yolu var.

Tema kütüphanenizin ekran görüntüsünü ve temaya son altı ayda kimlerin dokunduğunu paylaşın; hangi düzeyin size uygun olduğunu çıkaralım. Mevcut düzeniniz yetiyorsa bunu da açıkça söyleriz.