Herkes için Jujutsu

 (jj-for-everyone.github.io)
2 puan yazan GN⁺ 2025-09-01 | 1 yorum | WhatsApp'ta paylaş
  • Bu belge, Git deneyimi olmasa bile takip edilebilecek şekilde Jujutsu(VCS)'yu adım adım seviye yapısı ile öğreten, yeni başlayanlara yönelik bir eğitimdir
  • Terminal kullanımını temel alır, ancak terminal temellerini de kapsar; ana komutlar Linux/macOS odaklı olarak açıklanır ve Windows kullanıcılarına WSL önerilir
  • Öğrenme akışı, seviye 1~3'te temel·işbirliği·sorun çözme becerilerini oturtup, üst seviyelerde history rewrite·ileri iş akışlarına genişleyen bir yapıdadır
  • Eğitim sırasında durum karıştığında kullanılmak üzere, her bölümün başlangıç noktasına döndüren reset script'i ile yeniden üretilebilir bir öğrenme ortamı sunar
  • Neden Git yerine Jujutsu sorusuna, Git uyumluluğu, öğrenme zorluğunu azaltma ve ileri düzey işlevsellik gerekçeleriyle yanıt verir; içerik en güncel Jujutsu 0.32 temel alınarak güncellenmektedir

Giriş(Introduction)

  • Bu eğitim, Jujutsu'yu ilk kez kullanan kullanıcıları hedefleyen bir başlangıç kaynağıdır
  • Mevcut Jujutsu materyallerinin deneyimli Git kullanıcılarının geçişine odaklanma sınırlamasını tamamlayan, yeni başlayan odaklı içerik sunar
  • Terminal kullanımı esastır; temel terminal kullanımı bölümü de içerir ve Windows kullanıcılarına WSL kullanımı önerilir

Bu eğitim nasıl okunur?(How to read this tutorial)

  • İçerik seviye bazında düzenlenmiştir; her seviyeyi bitirdikten sonra gerçekten pratik yapıp bir sonraki seviyeye geçilecek şekilde tasarlanmıştır
  • Amaç işbirliği ise, seviye 1 ve 2'nin art arda alınması önerilir
  • Seviye özeti
    • Seviye 1: Kişisel çalışma için gereken asgari başlangıç setini sunar; ödevlerini tek başına yöneten öğrenci düzeyi için uygundur
    • Seviye 2: İşbirliği için asgari set; öğrenci takım projeleri ve profesyonel geliştiriciler için gereklidir
    • Seviye 3: Çatışma çözümü, kurtarma gibi sorun giderme temelleri; ortalama geliştirici yetkinliğine karşılık gelir
    • Seviye 4: History rewrite ile temiz bir geçmiş oluşturma; bazı projelerin kalite standartlarını karşılamak için gereklidir
    • Seviye 5: Üretkenlik artırıcılar·ileri iş akışları·nadir CLI·teori, Jujutsu ustalık seviyesi
    • Seviye 6: Etiketler·submodule'ler·workspace'ler gibi duruma özel konular; gerektiğinde başvurulması önerilir

Kısayollar(Keyboard shortcuts)

  • Sağ ve sol ok tuşlarıyla bölümler arası geçiş desteklenir
  • S veya / ile kitap içinde arama yapılabilir
  • ? ile yardım gösterilir, Esc ile gizlenir

İlerlemenizi sıfırlayın(Reset your progress)

  • Örnek depo durumu bir sonraki bölümle bağlantılı olduğundan, durum kaybı ilerlemeyi tıkayabilir
  • Bunu çözmek için, bölüm başlangıç noktasına geri yükleyen bir reset.sh script'i sağlanır
  • Her bölümün başında tam reset komutu bulunur; böylece kopyala-yapıştır ile yeniden üretilebilir
  • Script çalıştırılmadan önce içeriğinin gözden geçirilmesi önerilir; fiilen elle çalıştırılacak komutlar topluluğu düzeyinde basit işler yapar
  • Script'in başlıca özellikleri
    • JJ_CONFIG=/dev/null ile kullanıcı ayarlarının etkisini engeller
    • Örnek repo oluşturma, colocate Git entegrasyonu, kullanıcı bilgisi ayarlama, commit/push/fetch/rebase gibi ardışık senaryoları yeniden kurma
    • Her bölüm anahtar sözcüğünü argüman olarak alıp ilgili noktada başarıyla sonlanacak şekilde dallanır

Güncel kalın(Stay up to date)

  • Eğitim ve Jujutsu sürekli evriliyor; eğitim deposunun Releases bölümüne abone olarak büyük değişiklik duyurularını alabilirsiniz
  • Bu eğitimin Jujutsu 0.32 tabanında (Ağustos 2025) güncel olduğu belirtilir
  • GitHub'da Watch → Custom → Releases üzerinden güncelleme bildirimi ayarlama yönergesi sunulur

Sürüm kontrolü nedir ve neden kullanılır?(What is version control and why use it?)

  • Yalnızca yazılım için değil, Typst gibi belge yazımı için de uygulanabilen, artan biçimde biriken çalışmaları yönetme aracıdır
  • Geçmiş bir duruma geri dönebilmeyi ve birden fazla kişinin eşzamanlı çalışmasını güvenle destekler
  • Sıradan yedekleme ya da işbirlikçi editörlere kıyasla daha keskin kontrol araçları gerektiğinde Jujutsu uygundur

Neden Git yerine Jujutsu?(Why Jujutsu instead of Git?)

  • Git uyumluluğu: Mevcut Git depolarıyla kayıpsız birlikte çalışabilirlik sağlar; çoğu Git entegrasyon aracını olduğu gibi kullanabilirsiniz
  • Öğrenme kolaylığı: Git'in karmaşık ve sezgisel olmayan arayüzüne kıyasla Jujutsu, aynı işlevleri daha düşük karmaşıklıkla sunar
  • Daha güçlü işlevsellik: Kolay öğrenilmesinden bağımsız olarak çok sayıda power user özelliği sunar ve iş akışı genişletilebilirliğini güvence altına alır
  • Dezavantajlar ve dikkat edilmesi gerekenler
    • Konuşmalarda Git terim merkezli kültürle kavramsal eşleme yükü vardır; ekip arkadaşlarını ikna ederek bu yük azaltılabilir
    • Görece yeni olduğu için Git'in bazı özelliklerini içermeyebilir; gerekirse doğrudan Git kullanarak fallback yapılabilir
    • CLI hâlâ istikrar kazanma sürecinde olduğundan bazı komutlar değişebilir; değişimleri izlemek için eğitim release'lerine abone olmanız önerilir

Öğrenme ilerleyişi(Completed & Next)

  • Şu anda, seviye 1~3 odaklı pratik görev akışıyla (kurulum→başlatma→log/commit→remote/push·clone→branch/merge→rebase→navigasyon→geri alma/kurtarma→çatışma çözümü→temizlik) gerçek kullanım becerilerinin kazanılması hedeflenir
  • Üst seviyelerde rewrite·ileri iş akışları·nadir konular eklenerek kademeli uzmanlaşma stratejisi sunulur

İlgili okumalar

1 yorum

 
GN⁺ 2025-09-01
Hacker News yorumu

  • Sanırım jj hakkında yalnızca övgü dolu onlarca yazı gördüm. Bu eğitim de benzer; artık iyi yanlarını yeterince okuduğum için daha çok eksileri ve rahatsız edici tarafları ilgimi çekiyor. Benim jj deneyimimde artılar ve eksiler vardı. Ekip arkadaşlarımla branch paylaşarak üzerine commit eklemeye devam ettiğimiz bir iş akışını sık kullanıyorum; jj’de isimlendirilmiş branch’ler olmadığı için git’e göre kullanımı daha zahmetliydi (tug alias’ını kullansam da öyleydi). Eğitimdeki “Tracking remote bookmarks” bölümü de bana hâlâ kullanışsız görünüyor. Bir diğer rahatsız olduğum nokta da jj’nin git’teki git clone --filter=blob:none gibi light clone kullanamamasıydı; bunun düzelip düzelmediğini merak ediyorum

    • jj’de isimlendirilmiş branch’ler var, jj bunlara “bookmarks” diyor. Remote bookmark izlerseniz jj git fetch ile yerel kopya remote ile senkronize olur

    • Beni zorlayan şeylerden biri de jj’nin bazen değişikliklerimi rastgele kaybetmesi oldu. Cursor’da çalışırken repo üzerinde jj ile mutasyon yapan bir işlem yapmadım (jj status, jj log gibi şeyler dışında), ama sonradan bakınca değişikliklerimin kaybolduğunu gördüğüm oldu ve sık sık "stale workspace" mesajı da çıkıyordu. Bunun IDE’den mi yoksa devasa monorepo’dan mı kaynaklandığını bilmiyorum ama gerçekten acı vericiydi. Yine de jj’nin esnekliğini oldukça beğeniyorum

    • https://github.com/jj-vcs/jj/discussions/3549 adresinde tug iş akışını biraz daha basitleştirmeye yönelik bir tartışma var

    • jj’de isimli branch olmadığı söylemi yanlış. jj branch set -r@ XYZ gibi elle belirtmeniz gerekiyor, bu biraz zahmetli ama push sırasında bir kez yapmanız yetiyor. Ya da jj git push --named XYZ=@ ile branch’i taşımanın bir yolu da var

    • jj’nin light clone (git clone --filter=blob:none) desteği hâlâ çözülmüş değil

  • “Jujutsu Git’ten daha güçlü” denmiş ama tam olarak hangi açıdan daha güçlü olduğu açıklanmamış; o yüzden neden kullanmam gerektiğini merak ediyorum. Bu bana sadece süslü bir ifade gibi geliyor

    • Eğitimin yazarı benim. Hedef kitle yeni başlayanlar olduğu için Git ile ayrıntılı bir karşılaştırma uygun değildi. Git arayüzünün karmaşıklığı çoğu zaman “güç” ile meşrulaştırılıyor; ben de kullanıcılara Jujutsu’nun öğrenmesi kolay diye özellik kaybettirmediğini anlatmak için bu ifadeyi ekledim

    • Mesela Main branch’inden yeni bir branch oluşturuyorsunuz ve sonra bunu PR olarak göndermeyi planlıyorsunuz. Birkaç commit biriktirdikten sonra 1 numaralı commit’i değiştirmeniz gerektiğini fark ederseniz, sadece 1 numarayı düzenleyip kaydetmeniz yeterli; diğer tüm commit’ler otomatik olarak en güncel hâle rebase edilir. PR’den sonra da 3 numaralı commit’i değiştirmek istiyorsanız, sadece o commit’i düzenleyip push etmeniz yeterli. Bu tür işleri Git ile doğrudan yapmak gerçekten zor. Ekip arkadaşlarım da birden fazla commit’e bölünmüş PR’leri çok seviyor

    • Ben de benzer düşünüyorum. Git UI’larının genel olarak yetersiz olduğunu hissediyorum, bu yüzden jj’yi belli ölçüde güvenerek kullanmaya niyetliyim. Ama “neden daha kolay, daha güçlü ya da daha kullanışlı” olduğuna dair somut gösterimler olsaydı daha iyi olurdu

    • Örneğin merge conflict’i tek bir öğe olarak kaydedip daha sonra çözebilirsiniz: https://jj-vcs.github.io/jj/latest/conflicts/

  • Yakın zamanda JJ’yi yeniden denedim ve çok geliştiği için keyifle kullanıyorum. İlk dönemlerinde denediğimde epey pürüzlüydü ve göz korkutuyordu, ama bence JJ son dönemde ortaya çıkan harika araç zinciri “yeni dalgasının” bir parçası. Blogumda da bununla ilgili yazdım: https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-renaissance/

    • Güzel yazı. Son birkaç yılda geliştirme araçları için çıtanın gerçekten çok yükseldiğini düşünüyorum. Rust da bu değişimin bir parçası

    • Senin de mise kullanıp sevdiğini görmek güzel. mise, jj (ve aşırı harika olan jjui TUI), ayrıca Python için uv gerçekten devrim niteliğinde. Bu araçların gerçekten çok güzel olduğunu düşünüyorum

    • Ben buna kesinlikle nushell’i de eklemek isterim

    • Bun da bu araç devriminin ön saflarında

  • Harika iş! Neredeyse 5 aydır yalnızca Jujutsu kullanıyorum ve git’in yerini tamamen aldı. Aslında bu sürede Git’i 52 kez çalıştırdım (bunların 11’i --help idi), ama Jujutsu’yu 582 kez kullandım. Belirli bir iş akışına uyma zorunluluğu olmadan, Jujutsu neredeyse her iş akışını destekleyecek kadar esnek. Git gibi kullansanız bile commit’leri ve branch’leri serbestçe taşıyabiliyorsunuz (stash yapmaya gerek yok) ve kolayca rebase edebiliyorsunuz (git ustaları için tanıdık olabilir ama VSCode’un git araçları olmadan doğrudan yapabilmek gerçekten güzel); yani VCS’nin baş ağrıtan tarafları olmadan sadece işe odaklanabiliyorsunuz. Dikkat edilmesi gereken nokta şu: çalışma geçmişi her zamanki gibi git reposunda da tutulduğu için diğer git araçlarıyla uyumluluk korunuyor. Yani ekip arkadaşlarım VCS değiştirmese bile ben farklı bir şey kullanabiliyorum. Tag, submodule ve LFS tarafında bazı eksikleri var ama yine de denemeye fazlasıyla değer

    • git branch --set-upstream-to için jj’de karşılık ne, merak ediyorum

    • jjui’yi kullandıktan sonra bir daha neredeyse hiç jj komutuna dokunmanız gerekmiyor. Gerçekten şaşırtıcı

  • Jujutsu gerçekten iyi. Birkaç ay önce denedim ve onun hakkında birkaç yazı da yazdım (bu yazı); o zamandan beri de kullanmaya devam ediyorum. Genel olarak çok “tutarlı” bir deneyim sunuyor. Aslında git’i de gayet sorunsuz kullanan biriydim ama jj’de her şey birkaç temel ilke etrafında dönüyor ve bunları istediğiniz gibi birleştirip karmaşık geçmiş düzenlemelerini kolayca yapabiliyorsunuz. Eskiden daha çok “stash odaklı” çalışırdım; jj ise değişiklikleri otomatik izlemesi, değişiklikleri özgürce taşıyabilmesi gibi özellikleri sayesinde git’ten çok daha rahat hissettiriyor. Rebase ve conflict çözümü de (özellikle stash tarzı iş akışlarında) çok daha iyi. Kesinlikle tavsiye ederim ve geçiş için gereken çaba da çok düşük

  • Kişisel olarak git’in üstüne yeni bir katman ekleme yaklaşımını pek sevmiyorum. Git’in hegemonyasını kırmanın zor olduğunu biliyorum ama tamamen yeni bir temel üzerine kurmak çok daha güçlü ve özgür olurdu diye düşünüyorum

  • Yaklaşık bir ay jj kullandıktan sonra, şirketteki belirli bir proje yüzünden tekrar git’e dönmek zorunda kaldım. jj’yi gerçekten sevmiştim ama o kadar da değil demiştim. Ama git’e döndükten birkaç saat sonra jj’nin sağladığı rahatlığı inanılmaz özledim: https://blog.nawaz.org/posts/2025/Aug/the-jujutsu-effect/

    • “O kadar da değil” derken tam olarak ne demek istiyorsun?

    • İnsan bir şeyi kaybedince değerini anlıyor demek istiyor

  • “Git uzmanları için Jutustsu” başlığında daha fazlasını okumak isterim. Mesela conflict’i commit etmenin benim git rerere düzenimi bozup bozmayacağını ya da git’te git add -p ile patch’in sadece bir kısmını stage ederek çalışmayı seviyorum, jj’de iki aşamalı patch set’i rahatça yapmanın bir yolu olup olmadığını merak ediyorum. Timestamp bozulmalarından veya anlamsız build sistemi rebuild’lerinden kaçınmak istiyorum

    • jj’de en yaygın kullanılan iş akışına (“squash workflow”) göre cevap vereyim. Çalışma dizini olan top commit üzerinde dilediğiniz gibi değişiklik yapıyorsunuz; sonra “stage etmek” istediğinizde aşağıdaki commit’e, yani bir alt commit’e, squash down yapıyorsunuz (ister tüm değişiklikleri ister -i ile sadece bir kısmını). Ayrıca squash --into ile başka bir commit seçip istediğiniz yere squash da edebilirsiniz

      1. jj’de git rerere kullanılmadığı için bu soru biraz isabetsiz kalıyor. 2. @ çalışma alanı, @- ise üzerinde çalıştığınız commit. jj squash -i ile istediğiniz diff parçalarını etkileşimli biçimde tekrar @ içine alabilirsiniz

    • “Stage/unstage ayrımı gereksiz” görüşüne katılmama rağmen, “ama patch içinden sadece beğendiğim kısımları stage etmeyi çok seviyorum” yaklaşımı bana ilginç geliyor. git worktree, git diff, vi, git apply kombinasyonuyla stage etmeden benzer bir etki elde edilebilir ama gerçekten zahmetli. mercurial 7.1’de de hâlâ etkileşimli ekleme yok; worktree üzerinden yapılan dolambaçlı çözümler dışında bir alternatif görünmüyor

  • Son zamanlarda Jujutsu hakkında çok şey görüyorum ama işin somut iş akışı tarafına henüz bakmadım. Emacs Magit’e kıyasla Jujutsu’nun özel bir avantajı var mı merak ediyorum. Şimdiye kadar kullandığım Git UI’larının çoğu yetersizdi ama Magit sayesinde git verimliliğim çok arttı ve git’in “büyüsünü” de hissettim. Jujutsu bununla mı rekabet etmeye çalışıyor, yoksa hedefi daha çok (gerçekten yetersiz olan) mevcut git UI’larına alternatif olmak mı?

    • Jujutsu sadece bir git UI değil; hatta git UI olarak bazı yönlerden zayıf bile sayılır (tag, submodule gibi desteklerin eksikliği). Git’i backend olarak kullanan tamamen yeni bir VCS. Git, SVN’ye karşı “cheap branch” getirdiyse, JJ de “cheap rebase” getiriyor. Conflict tüm çalışmayı durdurmuyor ve rebase, commit yapısını yönetme gibi işler gerçekten çok rahat. Daha önce stacked diffs kullandıysanız tanıdık gelecektir ve stacked diff PR’leri jj’de neredeyse hiç çaba harcamadan yapılabiliyor

    • Zaten Magit’i yoğun kullanan biriyseniz, jj’nin temel kavramları da size çekici gelecektir. jj, daha önce imkânsız sanılan commit akrobasilerini mümkün kılıyor (örneğin, 5 yönlü octopus merge içindeki 2 leaf’i conflict çözülmemiş hâlde rebase etmek gibi). Bu aynı zamanda benim geliştirdiğim ve “Mega Merge” adını verdiğim teknik. Magit ile jj arasında benzerlikler de var; bence “git’in büyüsü” aslında araçların “tasarım dili”nden geliyor. Git, Magit ve jj için sadece fiziksel depolama katmanı; asıl farkı algoritmalar, UX ve kavramlar yaratıyor. Magit kullanıcıları jj karşısında genelde daha az sarsılıyor ama ileri seviye Git komut satırı kullanıcıları jj’ye çok kolay geçiyor ve hatta güçlü savunuculara dönüşüyor. Çünkü commit grafiğiyle oynayabilen araçların gücünü en iyi onlar anlıyor. Bu arada ben jj maintainers ekibinden biriyim ve bunun çok iyi yapılmış bir araç olduğunu düşünüyorum. Birkaç günlüğüne bile olsa Magit olmadan denemenizi isterim

    • Bununla ilgili bağlantılar burada. Megamerge iş akışını iyi anlatan yazılar: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/, https://ofcr.se/jujutsu-merge-workflow, ayrıca jj cli’ı saran üst düzey bir TUI: https://github.com/idursun/jjui

    • Jujutsu’nun “merkez kavramı”nın ne olduğunu merak ediyorum. Git’in sektör standardı olmasıyla kıyaslandığında Jujutsu kullanmak için yeterince güçlü bir neden görmüyorum. Kavramları ilginç buluyorum ama biraz daha net bir pazarlama anlatısı olsa kullanım ihtimali artar gibi geliyor. Git’in en büyük zayıflığı dışarıdan gelenler için çok kullanıcı düşmanı olması (terminoloji, keşfedilebilirliğin zayıf olması, GUI front-end eksikliği vb.); bu yüzden başlangıç dostu bir VCS’nin büyük potansiyeli var

    • Magit’ten jujutsu’ya geçtim. Bende değişen şey, PR yığmanın çok daha kolay hâle gelmesi ve değişiklikleri daha küçük parçalara ayırma alışkanlığı kazanmam oldu; böylece “gönderilmeye değer” eşiğim de yükseldi. Genel olarak olumlu bir deneyim ama Magit zaten size çok iyi uyuyorsa özel bir üstünlüğü yok. Yine de https://github.com/bolivier/jj-mode.el sayesinde Emacs içinde jj gayet kullanılabiliyor

  • İlginç buldum. İnternette oldukça aktif olmama rağmen Jujutsu’yu ilk kez şimdi duydum. Git’i backend olarak kullanıp daha iyi bir VCS sunma fikrini sevdim. Bunun bir nedeni de hâlâ Github-Gitlab üzerinden yedekleme ve paylaşım yapabilmek. Fossil ve Bitkeeper da çekici ama git’e göre “yeterince” daha iyi olmadıkları için git’in ağ etkisini aşamadılar. Jujutsu ile biraz oynayacağım. Sürekli kullanır mıyım bilmiyorum ama beklediğimden daha iyi çıkmasını umuyorum