Sürüm A'yı sola, sürüm B'yi sağa yapıştırın ve neyin değiştiğini tam olarak görün. git clone yok, IDE yok, kayıt yok. Tamamen tarayıcınızda çalışır.
Git, GitHub veya IDE açmadan iki kod sürümünü karşılaştırmak için ücretsiz, tarayıcıda çalışan bir araç. Eski sürümü sola, yeni sürümü sağa yapıştırın; farklar karakter karakter vurgulanır. Metin makinenizden çıkmaz; bu, snippet bir private repo'dan veya merge edilmemiş bir branch'ten geliyorsa önem kazanır.
Bir meslektaşın Slack'te bir fonksiyonun iki sürümünü atıp "ne değişti?" diye sorduğu an için yapıldı. 12 satırlık bir diff için yerel checkout açmak abartı. PR henüz yokken GitHub PR görünümünü açmak da öyle. İki metin paneli, bir diff, on beş saniyede biter.
Gerçek bir working tree üzerinde git diff'in yerine geçmez. Hunk stage'leyemez, patch uygulayamaz, blame çalıştıramaz. Yapabildiği şey en sık ihtiyacınız olan kısım: iki rastgele metin bloğunu alıp aralarındaki düzenlemeleri göstermek. Altta diff'in kendisi, compare-text aracımızı çalıştıran motorla aynı; burada code review için çerçevelenmiş.
Diff karakter karakter çalışır, ardından bir semantik temizleme adımı değişiklikleri yeniden okunabilir parçalara gruplar; böylece vurgulama yeniden adlandırılan bir tanımlayıcıya düşer, içindeki her bir harfe değil. Sağ paneldeki eklemeler yeşille, sol paneldeki silmeler kırmızıyla görüntülenir. İki panel scroll açısından kilitlidir; bir tarafta 80. satırda bir değişiklik bulunca diğer taraf da sizinle birlikte zıplar.
Neden satır yerine karakter düzeyinde? Çünkü kısa snippet'lerde yalnız satır görünümü fazla kaba kalır. Bir değişkeni id'den userId'ye yeniden adlandırmak tek bir tanımlayıcı değişikliğidir; satır düzeyinde bir diff size tüm satırı silinmiş, koca yeni bir satırı eklenmiş gibi gösterir. Teknik olarak doğru ama gerçek düzenlemeyi fark etmek zorlaşır. Karakter modu artı semantik temizleme yeniden adlandırılan token'ı vurgular, satırın geri kalanına dokunmaz. Uzun dosyalarda denge tersine döner; bu yüzden Git varsayılan olarak klasik satır tabanlı diff kullanır. İkisinin de yeri var. Bu araç size snippet dostu görünümü verir.
Aracın bilinçli olarak yapmadığı şey: söz dizimini bilmez. JavaScript, Python ya da Java'yı parse etmez. Aynı semantiğe sahip yeniden biçimlendirilmiş bir blok yine diff olarak görünür; çünkü bir metin karşılaştırıcısı için farklı metindir. Yapılandırılmış payload'lar için biçim bilen diff istiyorsanız, compare-json sayfamız bunu JSON için, compare-yaml YAML için, compare-xml XML ve POM dosyaları için yapar. Ham kaynak kodu söz konusu olduğunda, tek seferlik bir snippet için söz dizimi bilen bir aracı yapılandırmaktan çoğu zaman metin diff'ine gözünüzü eklemek daha hızlıdır.
İki metin paneli, bir diff. Login yok, upload yok, parse edilecek bir patch formatı yok.
Fonksiyonun, dosyanın veya snippet'in eski sürümünü editörünüzden, terminalden veya nerede duruyorsa oradan kopyalayın. Ctrl+C, sonra sol panele yapıştırın. git show <commit>'tan çekiyorsanız patch header'ı yerine dosyanın gövdesini kopyalayın; böylece diff yalnızca gerçek kod değişikliklerini vurgular.
Yeni sürüm için aynısını yapın. Bir meslektaş Slack, Teams veya e-postaya yapıştırdıysa doğrudan oradan kopyalayın. Yapıştırmada boşluklar ve girinti korunur; bu, girintinin anlamlı olduğu Python ve YAML gibi dillerde önemlidir. İki snippet uyuşmuyorsa Tab ve boşluk farklılığı bir fark olarak görünür.
Silmeler solda kırmızı üstü çizili, eklemeler sağda yeşil olarak görünür. Her başlıktaki değişiklik sayaçları kaç ayrı düzenleme tespit edildiğini söyler. Vurgulamaları okuyun, önce mantık değişikliklerine (kontrol akışı, koşullar, hata yönetimi) odaklanın; salt yeniden adlandırmaları veya biçim değişikliklerini gözden geçirme adımında daha düşük öncelikle ele alın.
Biri sohbete iki kod bloğu atıp hangisinin doğru olduğunu sorar. 20 satırlık bir snippet için repo'yu klonlamak, branch değiştirmek ve IDE açmak boşa giden bir efordur. İkisini de diff aracına yapıştırın; bir sonraki mesaj gelmeden cevabınız hazır olur. İnsanların online diff'e başvurmasının en yaygın sebebi budur.
CI pipeline'ları, Dockerfile'lar, package.json ve GitHub Actions workflow YAML'ı sürekli kayar. Bir takım arkadaşı bir branch'te .github/workflows/ci.yml'yi düzenler, build kırılır, siz onun branch'ini checkout etmeden neyin değiştiğini görmek istersiniz. main sürümünü kırık branch sürümünün yanına yapıştırın; suçlu adım genellikle saniyeler içinde su yüzüne çıkar. Workflow dosyalarına özgü girinti kenar durumlarını YAML diff sayfamız daha temiz biçimde ele alır.
Ürün yöneticileri, tasarımcılar ve müşteri yöneticileri bazen bir Git arayüzünü okumadan bir kod değişikliğinin ne yaptığını öğrenmek ister. GitHub'ın PR görünümü diff söz dizimine, dosya ağaçlarına ve gözden geçirme yorumlarına aşinalık varsayar. Öncesini ve sonrasını temiz iki panelli bir görünüme yapıştırıp vurgulamaları birlikte adımlamak çok daha dostça olur. Mühendislik dışından kişilerin de yer aldığı incident postmortem'lerinde de işe yarar.
Bir dosya için iki commit'teki git show abc123 ve git show def456 çıktısı elinizde, belki bir CI log'undan ya da git komutlarını kolayca çalıştıramayacağınız uzak bir sandbox'tan. Patch header'larını çıkarın, iki dosya içeriğini yapıştırın ve diff alın. Bir sunucuda hata ayıklarken, bir build artifact'ını okurken veya iki belirli commit'ten dosya içerikleri alıntılayan bir güvenlik bildirisini incelerken iyi çalışır.
Bir tedarikçi PDF'te örnek bir entegrasyon gönderir. Bir düzenleyici e-posta ile bir politika kod parçacığı yollar. Bir danışman script'inizin yamalı sürümünü ekler. Hiçbiri klonlanabilir bir repo değildir. PDF veya e-postadan metni kopyalayın, mevcut sürümünüzün yanına yapıştırın; bir dakikadan kısa sürede kullanılabilir bir gözden geçirme yüzeyi elde edersiniz. PDF'ten kopyala-yapıştırlarda bir miktar biçim gürültüsü beklenir; satır sonları ve tırnak karakterleri her zamanki şüphelilerdir.
Düz metin diff'inin Git, IDE'niz veya kod gözden geçirme aracınızın göstereceğiyle uyuşmadığı durumlar. Üretim kodunu yapıştırıp yanlış pozitif endişesine kapılmadan önce göz atmaya değer.
| Topic | What this tool does |
|---|---|
| Satır sonları (CRLF vs LF) | Windows tarzı CRLF ve Unix tarzı LF farklı byte'lardır. Bir Windows editöründen yapıştırılan bir dosya ile bir Linux container'ından yapıştırılan bir dosya, görünen metin aynı olsa bile satır sonları uyuşmazsa tüm dosya diff'i olarak görünür. Git bunu core.autocrlf ile normalleştirir; bu araç normalleştirmez. |
| Sondaki boşluk | Satır sonundaki boşluk veya sekmeler fark olarak görünür. Git'in core.whitespace'i commit'te uyarabilir veya otomatik düzeltebilir; burada yapıştırdığınız şey karşılaştırdığınız şeydir. Code review gürültü tabanınız sondaki boşluk düzenlemeleriyle doluysa, diff almadan önce editörünüzde bunları temizleyin. |
| İkili dosyalar | Bu araç yalnızca metin içindir. Bir ikili dosyanın (PNG, derlenmiş JAR, sqlite DB) içeriğini yapıştırmak saçmalık üretir veya sekmeyi kilitler. İkili diff için Git patch yerine "Binary files differ" gösterir; gerçek içerik için biçime özgü araçlara ihtiyaç vardır. |
| .gitattributes metin/ikili işaretleme | Bir repo'nun .gitattributes'ı, dosya kalıbı bazında Git'in metin-ikili tespitini geçersiz kılabilir. Bu ayar kopyala-yapıştırla taşınmaz. İki checkout arasında bir dosyanın farklı işlendiğinden şüpheleniyorsanız bakılacak yer o dosyadır; bu araç onu yine düz metin olarak diff alır. |
| Karakter ve satır diff'i | Bu sayfa semantik temizlemeli karakter düzeyinde diff kullanır. Git varsayılan olarak satır düzeyini kullanır, opsiyonel olarak git diff --word-diff kelime düzeyindedir. Karakter düzeyi tek bir token'ın değiştiği kısa snippet'ler için en iyisidir; satır düzeyi pek çok satırın toplu değiştiği uzun dosyalar için en iyisidir. |
| git diff --word-diff | Git'in --word-diff modu bir satır içindeki kelime düzeyi değişiklikleri vurgular ve snippet'ler için bu aracın yaptığına daha yakındır. Çıktı formatı farklıdır (terminal dostu işaretleme ile side-by-side paneller), ama amaç örtüşür. Terminalde yaşıyorsanız --word-diff yerel karşılığıdır. |
| Büyük dosya eşikleri | Tarayıcı tabanlı diff'ler her tarafta birkaç bin satıra kadar tepkiseldir. Ötesinde semantik temizleme yavaşlar ve render edilmiş DOM ağırlaşır. Çok büyük dosyalar için git diff'i yerelde çalıştırın ve bir pager'a yönlendirin ya da karşılaştırmayı daha küçük bölümlere ayırın. |
| Kodlama (yalnızca UTF-8) | Diff, UTF-8 girdi varsayar; bu, 2026'da neredeyse tüm kaynak kodunu kapsar. UTF-16, Windows-1252 veya Shift-JIS olarak kaydedilmiş dosyalar tarayıcınıza bağlı olarak yapıştırmada mojibake olarak görünebilir. Bir snippet karışık görünüyorsa kopyalamadan önce kaynak dosyayı UTF-8 olarak yeniden kaydedin. |
Yerel git diff, gerçek bir repository içinde iki ref'i (commit'ler, branch'ler, working tree) karşılaştırır. Index'inizi, worktree'nizi ve geçmişinizi bilir. Bu online araç bunların hiçbirini yapmaz. Yapıştırdığınız iki rastgele metin bloğunu karşılaştırır. Checkout edilmiş bir repo üzerinde gerçek gözden geçirme işi için git diff kullanın. Bunu, iki snippet'iniz olduğunda ve onları bir working tree'ye sokmanın pratik bir yolu olmadığında ya da bağlam değiştirmeden side-by-side bir görünüm istediğinizde kullanın.
Tam olarak değil. GitHub ve GitLab dosya bağlamı, hunk başlıkları ve dosya başına özetlerle satır tabanlı unified diff kullanır. Bu araç semantik temizlemeli karakter düzeyinde diff kullanır; kısa snippet'ler için daha iyi, çok değişikliği olan dosyaların tamamı için daha kötüdür. Gerçek bir pull request gözden geçirmesi için GitHub PR görünümüne gidin. PR dışında hızlı bir snippet karşılaştırması için bu daha hızlıdır ve doğru repo'ya gitmenizi gerektirmez.
Hayır. Bu düz metin diff'idir. Dili parse etmez, dolayısıyla yeniden adlandırılan bir değişkenin 12 yerde aynı tanımlayıcı olduğunu anlayamaz ve söz dizimi bilen bir diff'in yapacağı gibi yeniden biçimlendirilmiş boşluğu yok sayamaz. Snippet gözden geçirmelerinin çoğunda bu yeterlidir; çünkü vurgulamaları kendi kafanızla okursunuz. Kod için gerçek anlamda semantik diff istiyorsanız IDE'niz (VS Code, IntelliJ) veya tree-sitter tabanlı bir diff doğru araçtır. Bu sayfa hıza optimize edilmiştir, derin parse'a değil.
Klasik Unix komutu diff -u unified format bir patch üretir (Git'in içeride kullandığı formatın aynısı). Satır tabanlıdır ve patch'i başka yerde uygulayabilesiniz diye makine tarafından okunabilir olacak şekilde tasarlanmıştır. Bu araç insan tarafından okunmak içindir. Tek bir artı-eksi satır sütunu yerine inline vurgulamalı iki side-by-side panel gösterir. git apply veya patch -p1 ile uygulayabileceğiniz bir patch dosyası üretmez. Patch üretmeniz gerekiyorsa komut satırını kullanın. Bir diff okuyacaksanız bu daha dostça.
Evet, ama kendi yöntemleriyle. CRLF (Windows) ve LF (Unix) satır sonları, yapıştırılan iki snippet uyuşmuyorsa fark olarak görünür; çünkü teknik olarak farklı byte'lardır. Sondaki boşluk için de aynısı geçerlidir. Bu, core.autocrlf kapalıyken Git'in dosyaları işleme biçimiyle tutarlıdır. Yalnızca mantık değişikliklerini önemsiyor, boşluğu önemsemiyorsanız yapıştırmadan önce her paneli trim'leyin. Şu anda bir "boşluğu yok say" anahtarımız yok ama yol haritasında; git diff -w yereldeki karşılığıdır.
Pratikte var. Diff tarayıcınızda çalıştığı için çok büyük girdiler (vendor edilmiş tüm bir kütüphane veya 50.000 satırlık üretilmiş bir dosya) tarayıcınızın belleğine bağlı olarak sayfayı yavaşlatır veya sekmeyi durdurur. Tipik kod gözden geçirme işi için (fonksiyonlar, dosyalar, build script'leri, her tarafta birkaç bin satıra kadar yapılandırmalar) diff pratik olarak anında biter. Tüm repository'leri karşılaştırmanız gerekiyorsa gerçek bir Git aracı veya bir klasör karşılaştırma aracı doğru yanıttır; bu sayfa snippet'ler ve tek dosyalar için yapılmıştır.
Kodunuz tarayıcınızdan çıkmaz. Diff, vurgulama ve render'ın tamamı makinenizde çalışır. Metni yüklemiyor, log'lamıyor veya herhangi bir üçüncü taraf hizmete iletmiyoruz. Bu, sahip olunan kod gözden geçirme için özellikle önemli: yayınlanmamış bir özelliği, bir güvenlik yamasını veya bir private repo'dan bir snippet'i bir bulut hizmetine yapıştırmak başlı başına işvereninizin veri işleme politikasını ihlal edebilir. Bu iddiayı doğrulamak basittir. Tarayıcınızın DevTools'unu açın, Network sekmesine geçin, iki sürümü yapıştırın ve izleyin. Karşılaştırma sırasında giden istek yoktur. Aynı gizlilik modeli diğer araçlarımızda da geçerlidir; bunlar arasında compare-text, compare-json ve compare-yaml yer alır. Kod gözden geçirme, gözden geçirme yüzeyi güvenilirken en iyi şekilde işler.