Kit geliştiğinde kopyanızı güncelleyin

1. Nereden başladığınızı kaydedin

Bir güncellemeyi yapıştırma değil, küçük bir proje olarak ele alın: elinizdeki kit sürümünü daha yenisiyle karşılaştırır, değişiklikleri aktarır ve dağıtmadan önce bir dalda test edersiniz. Projeniz ister bir kit deposunun fork'u — GitHub'ın kaynağa bağlı tuttuğu bir kopya — olsun ister kendi uygulamanıza kopyaladığınız kod olsun, bu işe yarar.

Her şeyden önce, projenizde üç şeyi içeren bir not yazın: başladığınız kit commit'i — Git'in tam bir sürümü tanımlayan kısa kodu olan SHA — aldığınız depo (supastack-web, supastack-mobile, supastack-desktop veya Tüm Platformlar monorepo'su) ve zaten kendiniz yapmış olduğunuz değişiklikler.

Kit depolarının ve monorepo'nun farklı geçmişleri vardır, bu nedenle birinin dalını asla diğerinin fork'uyla birleştirmeyin. Başlangıç SHA'sını hiç kaydetmediyseniz, bir fork'ta git merge-base ile en yakın ortak sürümü bulun veya seçici benimsemede kopyaladığınız son dosyaları ve testleri belirleyin — ve tam başlangıç noktası belirsizken daha geniş bir diff'i gözden geçirin.

2. Yeni sürümü indirin ve birleştirin

Aşağıdaki komutları proje klasörünüzün içindeki bir terminalde, çalışmanız kaydedilmiş ve commit'lenmiş olarak çalıştırın — temiz bir çalışma ağacı, böylece yarım kalan hiçbir şey birleştirmeye karışmaz. Açılı ayraçlar içindeki kelimeler değiştirilecek şablonlardır: <thing> bütününün yerine kendi değerlerinizi koyun. Gösterilen GitHub adresi bir yer tutucudur; fork'ladığınız deponun adresini kullanın.

Satırların yaptığı: git remote add, kopyanıza kit-upstream adında ikinci bir adres — kit deposu — öğretir ve git fetch, dosyalarınıza dokunmadan en yeni durumunu indirir. git switch -c, incelerken ana dalınızın dokunulmaz kalması için ayrı bir yükseltme dalı oluşturur. git log almak üzere olduğunuz commit'leri listeler ve git diff --stat hangi dosyaların değiştiğini özetler; kullandığınız modüller için yalnızca commit başlıklarını değil, tam diff'i okuyun. git merge yeni kodu yükseltme dalına getirir.

Git, kit-upstream uzak deposunun zaten var olduğunu bildirirse remote add satırını atlayın ve git fetch ile devam edin. <previous-kit-sha>, 1. adımda kaydettiğiniz başlangıç SHA'sıdır.

# Upstream is the platform repository you forked — substitute its real URL
# (supastack-web shown; use supastack-mobile or supastack-desktop as fits).
git remote add kit-upstream https://github.com/<org>/supastack-web.git
git fetch kit-upstream
git switch -c upgrade/kit-update
git log --oneline <previous-kit-sha>..kit-upstream/main
git diff --stat <previous-kit-sha>..kit-upstream/main
git merge kit-upstream/main

3. Çakışmaları çalışmanızı kaybetmeden çözün

Çakışma, iki tarafın da aynı satırları değiştirmesi demektir: kit ilerledi ve siz aynı yeri özelleştirdiniz. Git birleştirmeyi duraklatır ve dosyayı işaretler — hasar bildirmiyor, sizden seçim yapmanızı istiyor.

İşaretli her dosyayı düzenleyicinizde açın ve satır satır karar verin: ürününüzün kendi metnini, adlarını ve ayarlarını koruyun; kitin düzeltmelerini ve yapısal değişikliklerini alın. Özelleştirdiğiniz bir dosyayı kitin yeni sürümünün tamamıyla değiştirerek asla çakışma çözmeyin — bu, çalışmanızı siler. Yükseltme dalının içinde çözün ve devam etmeden önce çözülen her alanın testlerini çalıştırın.

Birleştirme ters giderse, git merge --abort dalı birleştirme öncesi durumuna döndürür. Yükseltme dalını kendiniz birleştirene kadar bu akıştaki hiçbir şey ana dalınızı veya dağıtımınızı değiştirmez.

4. Veriyi güncelleyin ve doğru sırada dağıtın

Yeni kit sürümleri veritabanını değiştirebilir. packages/db/drizzle/ içindeki yeni dosyaları — geçiş klasörünü — okuyun ve geçişleri uygulamadan önce üretim verilerini yedekleyin; önce tek kullanımlık bir kopyada test edin. Uyumlu şema değişikliklerini, onlara ihtiyaç duyan koddan önce dağıtın: bir geçiş veriyi kaldırır veya yeniden şekillendirirse, yalnızca uygulama kodunu geri almak eski şemayı geri getiremez.

Yeni .env.example'ı kendi ayarlarınızla karşılaştırın ve yeni gerekli değerleri barındırma panonuza ekleyin. .env dosyaları sır taşır ve asla Git'e commit'lenmez — her makinede ve dağıtımda elle yeniden oluşturursunuz ve NEXT_PUBLIC_ ve EXPO_PUBLIC_ değerlerinin dışında kalırlar.

Dağıtmadan önce kitin kendi doğrulama kapılarını çalıştırın. Tüm Platformlar monorepo'sunda corepack pnpm check:local; lint, tür denetimi, birim testleri ve ücretli kimlik bilgisi gerektirmeyen bir biçim denetimi çalıştırır; corepack pnpm verify:local üretim derlemesini ve tarayıcı test paketlerini ekler. Tek yüzeyli bir fork'ta o deponun kendi test ve derleme komutlarını çalıştırın. Ardından bir hazırlık duman geçişi yapın: oturum açın, ikinci bir çalışma alanı deneyin ve ürününüzün ana kullanıcı yolculuğunu çalıştırın.

Her şey geçtiğinde, kabul edilen hedef SHA'yı ve çözdüğünüz çakışmaları yazın — bu not, bir sonraki güncellemenin başlangıç noktasıdır.

corepack pnpm check:local
# fuller gate: adds the production build and browser suites
corepack pnpm verify:local

5. Fork'lamak yerine parçalar kopyaladıysanız

Seçici benimseme — kit modüllerini mevcut bir uygulamaya kopyalamak — kitle ortak bir Git geçmişi paylaşmaz, bu nedenle git merge yardımcı olamaz. Bunun yerine eski kaynak SHA'sı ile hedef kaynak SHA'sını karşılaştırın ve yalnızca benimsediğiniz dilime dokunan değişiklikleri taşıyın.

Modülün genel türlerini, kalıcılık şemasını ve geçişlerini, sunucu çağıranını, yapılandırmasını, testlerini ve belgelerini tek birim olarak gözden geçirin — bir paketin içindeki değişiklik başka bir yerde eşleşen bir rota veya ortam değişikliği gerektirebilir ve tek bir yardımcıyı kopyalamak geri kalanı eskimiş bir sözleşmede bırakabilir. Kısa bir uyarlama notu tutun — hangi kit dosyalarını aldınız, hangilerini atladınız, neyi değiştirdiniz — böylece bir sonraki güncelleme seçimlerinizi tekrar uygulayabilir.

Bir güncelleme çalışan kopyanızda bir şeyi bozarsa, kendi değişikliklerinizi geri almadan önce sorun giderme kılavuzunu izleyin.

• Güncelleme sonrası bir sorunu düzeltin