Git'te Fork'u Upstream ile Senkronize Etme: 3 Güvenli Yöntem

TL;DR: git fetch upstream && git merge upstream/main && git push origin main çalıştırın, fork’unuz güncellenir. “git sync fork with upstream” iş akışının tamamı budur — fork’ladığınız projenin değişikliklerini çekin, sonra kendi kopyanıza itin. Doğrusal geçmiş tercih ediyorsanız merge yerine git rebase upstream/main kullanıp force-push yapın. upstream remote’unu hiç bağlamadıysanız aşağıdaki 1. adımla başlayın, çünkü eksik remote, bir fork’un “senkronlanmamasının” bir numaralı sebebidir. Gerisi — rebase, GitHub’ın senkron düğmesi, itilemeyen ayrışmış branch’ler — bu üç komutun üstüne detaydır.

Fork’u upstream ile senkronize etmek ne demek?

Fork, başkasının GitHub deposunun sizin kopyanızdır. Orijinal upstream‘dir; sizin kopyanız origin. GitHub fork’ları kendiliğinden güncellenmez — maintainer’lar bir pull request merge ettiğinde, sizin kopyanız dünkü kodda kalır. Fork senkronlamak, upstream’in yeni commit’lerini fork’unuza çekmek demektir; böylece branch’iniz projenin güncel haliyle eşleşir, ya da en azından onu içerir.

Bu iki sebeple önemli. Birincisi katkı: bayat bir fork’tan açtığınız her pull request ekstra gürültü taşır ve maintainer’lar merge’den önce güncellemenizi ister. İkincisi self-hosting ya da inceleme: bir fork’u üretimde çalıştırıyorsanız ya da sadece kodu okuyorsanız, bir aylık fork, elinizde olmayan bir aylık hata düzeltmesidir.

Fork’u upstream ile komut satırından nasıl senkronlarım?

Üç adım: upstream’i bir kez tanımlayın, ondan fetch edin, sonra merge edip push edin. Bağlantı kalıcıdır — bir dahaki sefere yazacağınız tek şey 2. ve 3. adımlardır.

Adım 1 — upstream remote’unu ekleyin (her clone için bir kez).

# fork'un yerel klonunun içinde
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git
git remote -v   # doğrula: origin -> sizin fork'unuz, upstream -> orijinal

Doğru URL’yi orijinal deponun sayfasında bulun: yeşil Code düğmesi. Sık yapılan hata, iki remote’u da kendi fork’unuza çevirmektir — o zaman “senkron” sessizce hiçbir şey yapmaz, çünkü elinizdeki kopya kadar bayat bir kopyadan fetch etmiş olursunuz.

Adım 2 — upstream branch’ini fetch edip merge edin.

git checkout main
git fetch upstream
git merge upstream/main
git push origin main

“git sync fork with upstream command line” sorusunun standart cevabı budur. Normal sonuç fast-forward’dur — fork’unuzdaki main‘in yeni hiçbir şeyi yoktu, o yüzden düz bir şekilde upstream/main‘e kayar ve merge commit’i oluşmaz.

Adım 3 — ihtiyaç halinde tekrarlayın. git fetch upstream && git merge upstream/main && git push origin main dışında akılda tutulacak bir şey yok. Merge’den önce ne kadar geride kaldığınızı görmek için, fetch’ten sonra git rev-list --count main..upstream/main çalıştırın.

Fork senkronlarken rebase mi, merge mi?

İkisi de aynı kodu fork’unuza taşır; geride bıraktıkları geçmiş farklıdır. Repo başına tek politika seçin ve ona bağlı kalın:

Yöntem	Komut	Geçmiş sonucu	En iyi olduğu yer
Merge	git merge upstream/main	Ayrışmış branch’lerde ekstra merge commit’i	Açık PR’ı olan feature branch’ler — hiçbir şeyi yeniden yazmaz
Rebase	git rebase upstream/main	Commit’leriniz en üste oynatılır, doğrusal geçmiş	Fork’unuzdaki main‘i temiz tutmak; sıfırlamak istediğiniz ayrışmış fork’lar
GitHub arayüzü	Sync branch düğmesi / PR merge	Merge ile aynı	Klon açık olmadan hızlı güncelleme

Rebase’li senkron:

git fetch upstream
git rebase upstream/main
git push --force-with-lease origin main

Force-push şarttır, çünkü rebase commit ID’lerini yeniden yazar — fork’unuzun uzak branch’i artık yerel branch’inizden doğmuyor. Her zaman --force yerine --force-with-lease: bu sırada biri (ya da sizin başka bir makineniz) push etmişse üzerine yazmayı reddeder; tehlikeli komutu varsayılan olarak güvenli kılar.

Bileğe dövme yaptırılacak tek kural: ne yaptığınızdan emin değilseniz açık pull request’i olan bir branch’i asla rebase etmeyin — rebase commit ID’lerini değiştirir ve açık bir PR’ı commit’lerinden koparabilir. main‘i merge ile senkronlayın (ya da yeni işe başlamadan önce rebase edin) ve PR branch’lerini bunun dışında tutun.

Fork’um upstream ile senkronlanmıyor, neden?

Dört klasik şüpheli, gerçek terminallerde göründükleri sırayla:

1. upstream remote’u yok — git remote -v yalnızca origin gösterir. Belirti: git fetch upstream, 'upstream' does not appear to be a git repository hatasıyla düşer. Çözüm: yukarıdaki 1. adım.
2. Fetch ettiniz ama hiç merge etmediniz — fetch, yerel deponuzda upstream/main‘i günceller ama hiçbir çalışma branch’ine dokunmaz. Belirti: başarılı bir fetch’ten sonra git log eski görünüyor. Çözüm: git merge upstream/main.
3. Ayrışmış geçmiş — fork’unuzun main‘ine commit attınız, upstream de ilerledi. git pull sonra alakasız geçmişlerden yakınır ya da merge zorlar. Upstream kazansın istiyorsanız çözüm: git reset --hard upstream/main (yalnızca yereldeki main’e özel commit’lerinizi çöpe atar — önce git stash liste bakın ya da bir branch ile yedekleyin; kötü bir reset çoktan yaşandıysa kurtarma yolu git undo last commit yazısıyla aynı: git reflog eski ucu hâlâ bilir).
4. Rebase sonrası push non-fast-forward diyerek reddedildi — rebase ettiniz ama normal push ettiniz. Çözüm: git push --force-with-lease origin main.

Beşinci, nadir durum: upstream deposu yeniden adlandırıldı ya da silindi, 1. adımdaki URL bile 404 verir. GitHub, yeniden adlandırılan depoları yönlendirir; sert bir hata genelde silinmiş ya da gizli yapılmış demektir — senkronlanacak bir şey yoktur.

Fork’u GitHub sitesinden senkronleyebilir miyiz?

Evet. Fork’unuzun sayfasında, branch’iniz geride kaldığında bir Sync fork düğmesi belirir; tek tık upstream’i çeker. Kıvrım altında aynı iş bir pull request ile de döner: upstream/main‘den fork’unuzun main‘ine PR açıp merge edin.

Düğmenin sınırları, CLI’a ne zaman geçeceğinizi söyler: yalnızca fast-forward ya da merge yapar — rebase yapmaz ve branch’ler ayrışmışsa direkt pes eder, commit’leri atmayın ya da komut satırını kullanın der. Yalnızca varsayılan branch’i de senkronlar. Basit bir güncellemenin ötesindeki her şey için yukarıdaki üç komut araçtır.

Fork’unuzu ne sıklıkla senkronlamalısınız?

Dürüst cevap, her yeni işten önce: taze bir main‘den branch açın; açtığınız hiçbir PR “bu, üç hafta önceki bir sürüme dayanıyor” ile başlamaz. Aktif katkı verdiğiniz fork’lar için günlük ya da oturum başına bir main senkronu saniyeler tutar. Yalnızca okuduğunuz ya da deploy ettiğiniz fork için, upstream istediğiniz bir şeyi çıkarınca senkronlayın — orijinal deponun releases akışına abone olun, sürümde senkronlayın. Senkron rutin olduğu için ucuzdur; altı ay geride kalan bir fork genelde merge değil cerrahi ister ve “fork’umu senkronlayayım” bir öğleden sonraya dönüşür.

Kopyala-yapıştır kılavuzu

# bir kerelik kurulum
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git

# rutin senkron (merge politikası)
git fetch upstream && git merge upstream/main && git push origin main

# rutin senkron (rebase politikası, doğrusal geçmiş)
git fetch upstream && git rebase upstream/main && git push --force-with-lease origin main

# ne kadar gerideyim?
git fetch upstream && git rev-list --count main..upstream/main

# onarılamaz biçimde ayrıştı — main'i upstream ile birebir yap (yıkıcı)
git fetch upstream && git reset --hard upstream/main && git push --force-with-lease origin main

Rutin iki satırı kas hafızanıza yerleştirin; ayrışmış fork, tamir ettiğiniz bir problem değil, okuduğunuz bir merak konusu olarak kalır. Git bakımınız sunuculara uzanıyorsa, journalctl cheat sheet bir makinenin geçmişini okunur tutmanın öteki yarısını kapsıyor.