Yoğun Geliştiriciler İçin Jujutsu

 (maddie.wtf)
2 puan yazan GN⁺ 2025-07-23 | 1 yorum | WhatsApp'ta paylaş
  • Jujutsu (jj), Git’e göre daha basit kavramlar ve komutlar sunan, buna karşın güçlü özelliklere sahip bir sürüm kontrol sistemidir
  • Arka uçta Git kullandığı için aynı anda birlikte kullanılabilir veya Git’e kolayca geri dönülebilir
  • Yığın tabanlı diff, kolay rebase, geçici revizyonlar gibi özellikler doğal biçimde sunulur
  • Branch yerine Bookmarks kavramını kullanır ve bu, gerçek iş akışlarında daha sezgiseldir
  • Conflict çözümleme yaklaşımı esnektir ve günlük sürüm kontrol işlerini çok daha basit hale getirir

Elevator Pitch

Jujutsu (jj), Git ile karşılaştırıldığında çok daha basit bir zihinsel model ve komut satırı arayüzü sunan bir sürüm kontrol sistemidir.
Özelliklerden ödün vermeden bunu yapar; hatta aslında daha güçlü olduğu bile söylenebilir
Yığın tabanlı diff, kolay rebase ve geçici revizyonlar gibi özellikler doğal biçimde çalışır
Arka planda Git kullandığı için, tek bir satırla Git deposunun yanında kullanmaya başlayabilir ve istediğiniz zaman Git’e geri dönebilirsiniz
Depoyu kullanan diğer kişilerin çalışma biçimini de etkilemez

Getting Started

  • jj komut satırı aracını kurduktan sonra kullanıcı bilgileri ve shell otomatik tamamlama ayarlarını yapmanız önerilir
  • Mevcut bir depoda kullanacaksanız, yeniden clone etmek veya değişiklik olmayan bir durumda başlamanız avantajlıdır
  • Mevcut bir depoda jj git init --colocate . komutuyla Git ve Jujutsu depolarını birlikte oluşturabilirsiniz
  • jj depo verileri, Git’in .git dizininden ayrı olan .jj/ klasöründe tutulur
  • Git ile Jujutsu arasındaki veri senkronizasyonu varsayılan olarak sorunsuz çalışır
  • Ancak git clean -fdx komutu .jj/ klasörünü sildiği için dikkatli olunmalıdır
  • Remote branch takibi de bu komutla tek seferde ayarlanabilir

How To Use It

Jujutsu’nun komut satırı arayüzü Git’ten daha dar ve daha sadedir
Temel kavramları basittir, ancak iş akışına alışmak biraz zaman isteyebilir
Aşağıda temel kullanım biçimleri basit adımlar ve örneklerle açıklanır

Starting A New Revision

  • Git’te yeni işe başlamak genelde branch oluşturarak yapılır; Jujutsu ise yeni bir revizyon oluşturarak çalışır
  • En güncel remote depo durumunu almak: jj git fetch
  • Depo geçmişini görmek: jj log
  • Geçmişteki revizyonlar, kendilerine özgü Jujutsu revizyon kimliği ve Git commit hash’i ile ayırt edilir
  • Yeni işe başlamak için jj new main ile mevcut main’in üzerine yeni bir revizyon oluşturulur
  • Şu anda düzenlenen revizyon @ simgesiyle gösterilir
  • Ortak önek kaybolduğunda, revizyon kimliğinin kısa öneki de buna bağlı olarak değişir

Making Changes

  • Dosyaları değiştirdiğinizde değişiklikler anında ilgili revizyona dahil olur (ayrı bir staging area yoktur)
  • Düzenleme tamamlandığında jj describe -m "mesaj" ile revizyona mesaj eklenir
  • Yeni revizyon oluşturmak için jj new kullanılır (veya önceki bir revizyon belirtilir)
  • jj commit, jj describe + jj new birleşik işlemidir

Navigating

  • jj new ile oluşturulan boş revizyonlar, başka yere geçildiğinde otomatik olarak kaldırılır
  • Bir revizyonu açıkça silmek için: jj abandon <rev ID>
  • Silmeyi geri almak için: jj op undo
  • Var olan bir revizyona geri dönmek için: jj edit <rev ID>
  • Revizyonlara başvururken revset ifadeleri de kullanılabilir:
    • @: geçerli revizyon
    • x-: ebeveyn revizyon
    • y+: alt revizyon
    • z::: z’nin tüm torunları

Branches (Bookmarks)

  • Jujutsu’da Git’teki gibi “bir branch üzerinde bulunma” durumu yoktur
  • Bunun yerine bookmark’lar yalnızca belirli bir revizyonu işaret eden göstericilerdir
  • Yeni bookmark oluşturmak için: jj bookmark create <ad> -r <revizyon>
  • Commit ettiğinizde bookmark otomatik olarak taşınmaz; gerekirse jj bookmark move <ad> --to <revizyon> ile ayrıca taşınmalıdır
  • Push sırasında --allow-new bayrağı ile remote üzerinde yeni branch oluşturulmasına izin verilir
  • Bookmark remote ile farklıysa * ile gösterilir ve jj git push ile senkronize edilebilir

Conflicts

  • Jujutsu’nun conflict çözme yaklaşımı Git’ten daha esnektir
  • Conflict oluştuğunda revizyonda ve ondan türeyen alt revizyonlarda conflicted işareti görünür
  • Conflict içeren dosyalara conflict marker’ları eklenir ve bu işaretler kaldırılarak sorun çözülür
  • Doğrudan düzenleme yapılabilir veya değişiklikler yeni bir revizyonda yapıldıktan sonra jj squash ile birleştirilebilir

Sonuç

Böylece Git’te en sık kullanılan işlerin yüzde 80’ini Jujutsu ile daha basit biçimde nasıl yapabileceğinizi özetlemiş olduk
İleride daha genel ve ileri düzey kullanım için Quick Reference biçiminde bir başvuru el kitabı sunulması planlanıyor
Git’te olduğu gibi jj status komutu da desteklenir
Soru veya geri bildirim için metindeki e-posta adresi kullanılabilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-07-23
Hacker News görüşleri

  • jj öğrenmeye değip değmeyeceğini düşünenlere özellikle vurgulamak istediğim bir nokta var
    Hacker News'te jj hakkında konuşulunca insanlar iki gruba ayrılıyor: henüz denememiş olanlar ve hararetle tavsiye edenler
    bir hafta jj kullanıp sonra tekrar git'e dönen neredeyse hiç görmedim
    cidden ciddi şekilde deneyenlerin neredeyse hepsi jj'de kaldı
    bugünün jj'yi denemeniz için bir vesile olmasını umuyorum
    geçiş düşündüğünüzden çok daha kolay ve ben aynı gün bile üretkenliğimi korudum, bir hafta içinde git komutlarına geri dönmem hiç gerekmedi
    kısa sürede daha üretken hale geldim ve daha önce git'i nasıl kullandığıma şaşırıyorum

    • Ben git'i üretkenlik açısından hiç rahatsız edici bulmuyorum
      git komutlarını her gün uzun uzun kullanmıyorum ve çoğu durumda işimi gayet görüyor
      repoyu git ile çok fazla manipüle etmeniz gerekiyorsa jj daha iyi olabilir ama bu benim durumum değil
      örneğin bu, vim'e çok benzeyen ama bazı farklı özellikler eklenmiş bir bim'i mutlaka denemenizi önermeye benziyor
      ama birkaç kez daha "i" tuşuna basmanın ne fark yarattığını merak etmiyorum ve Julia otomatik tamamlamasına da ihtiyacım yok
      jj'yi daha iyi bulanlar keyfini çıkarsın

    • jj, VCS arayüzünde kesinlikle bir ilerleme ama ileri düzey git kullanıcıları için bazı sınırlamaları var
      gitattributes desteği olmadığından git-crypt, git-lfs gibi filtrelere ihtiyacınız varsa sıkıntı çıkarıyor
      satır sonu işleme gibi konularda Windows uyumluluğu da daha zayıf olabilir
      ayrıca git-annex, git-bug gibi harici araçlar oplog ile entegre olmuyor ve geçmişi dağıtabiliyor

    • Ben gerçekten bir haftadan uzun süre kullanıp sonra git'e döndüm
      şahsen staging area iş akışını daha çok seviyorum; çoğu kişi git staging'den nefret etse de ben bunu jj uğruna bırakacak kadar büyük bir kazanç görmedim
      alışkanlıklar değişebilir ama şimdilik jj'ye özellikle bağlanmış değilim
      ileride yeniden denemeye açığım

    • Birkaç ay jj kullandıktan sonra git'e dönmemin sebebi performans sorunlarıydı
      jj işlemleri birkaç saniye sürüyordu, git ise proje boyutundan bağımsız olarak anlıktı
      ayrıca jj kullanırken zihinsel olarak biraz daha karmaşık hissettiriyordu, git'e dönünce daha hafifledim
      bu belki de git'i uzun süredir kullanıyor olmamdan kaynaklanıyordur

    • “Nasıl olsa sadece iki grup var” demek başlı başına jj evangelistlerinin tipik söylemi gibi geliyor

  • jj'de beni çıldırtan şey değişikliklerin zorunlu olarak otomatik stage edilmesi
    SVN yapısı eskiden böyleydi ve git'in açıkça staging yapması bana göre çok büyük bir gelişmeydi
    repoda her zaman daha fazla değişiklik kalıyor ve bir sonraki commit'e sadece istediklerinizi seçmek git'te gayet doğal
    ama jj'de (SVN de dahil) commit öncesi değişiklikleri geçici olarak dışarı taşımak gibi uğraştırıcı el işleri gerekiyor

    • Bu konu benim için de bir ikilem
      staging her zaman can sıkıcı geliyor; Mercurial kullanırken de zorlanıyordum
      otomatik eklemenin %90'dan fazla gerekli olduğu durumlarda aslında rahat ama .gitignorea koyamadığınız dosyalar sorun oluyor
      auto add'i kapatsanız da rahatsız, açsanız da tam oturmuyor
      iki taraf da tamamen temiz değil

    • JJ'nin iş akışı biraz farklı; örneğin önce bir temel commit oluşturup onun üstüne adsız commit'ler yığarak çalışıyorsunuz
      hazır olduğunuzda jj squash ya da jj split ile düzenliyorsunuz

    • Ben jj commit -i, birçok komuttaki -i seçeneği ve config'teki snapshot.auto-track="none()" ayarını kullanıyorum
      Mercurial kullanırken de benzerdi
      aslında absorb özelliğini çok kullanırsanız gereksiz dosya ya da chunk'lar otomatik olarak görmezden geliniyor

    • “jj new” komutu tam da istediğiniz iş akışına uygun değil mi?

    • jj, ağaç üzerinde head olmayan branch'leri de düzgün takip ettiği için rebase ve merge işlemleri stash gerekmeden sorunsuz çalışıyor

  • Otomatik değişiklik eklemeye alışmak kolay değil
    yerelde bazen belirli dosyaları commit etme niyeti olmadan geliştirme sırasında geçici olarak değiştiriyorum
    git'te stage etmediğim sürece bunlar asla commit ya da push olmayacağı için içim rahat oluyor
    ama jj'de bir şeyleri unstage etmem ya da ekstra dikkat etmem gerekiyormuş gibi geliyor
    bu belki alışkanlık meselesidir ama ben commit edeceğim şeyleri açıkça belirtmeyi daha rahat buluyorum
    yoksa jj'yi yanlış mı anlıyorum diye merak ediyorum

    • jj'de jj split ile değişiklikleri bölebilirsiniz
      seçtiğiniz kısım ilk revision'a, geri kalanı ikinci revision'a gider
      birden fazla işi aynı anda yapıp sonra bunları lokmalık revision'lara ayırırken git'ten çok daha rahat oluyor
      git'teki gibi yeni bir revision (jj new) oluşturup değişiklik yaptıktan sonra jj squash -i ile tam istediğiniz parçaları taşıyabilirsiniz
      kavramsal olarak “@” mevcut revision, “@-” ise bir önceki olduğu için bunu git'teki working copy/stage gibi düşünebilirsiniz

    • jj'nin otomatik staging'i her zaman iyi değil
      resmî jj belgeleriyle yeni başlayanların rehberleri, varsayılan davranışın kolayca kapatılabildiğini daha açık anlatmalı bence
      ~/.jjconfig içine
      [snapshot]
      auto-track = "none()"
      yazmanız yeterli

    • Ben genelde iş bittikten sonra jj split ile commit'e girecek kısımları gözden geçirip düzenliyorum
      bu iş akışı git'teki add -p ile benzer şekilde çalışıyor
      en üstteki commit genelde push edilmeyen bir working copy gibi kullanılabiliyor
      stash olmadan branch değiştirseniz bile devam eden işler iyi korunuyor

    • Evet, bu alışkanlık bende de kolay değişmedi
      bunu değiştirmeniz gerektiğine dair mantıklı argüman, kodu untracked halde çalıştırmamanız gerektiği
      anlamlı değişiklikleri commit'te bırakıp geri kalanını kaydetmemek daha güvenli
      sorun, repo geneli ayarlarla yerel ayarlar ayrılmadığında ortaya çıkıyor; VSCode bunun tipik örneği
      böyle durumlarda ortama özel, commit edilmemesi gereken değişiklikler gerekiyor ve iş daha da karmaşıklaşıyor

    • Böyle bir iş akışı istiyorsanız jj'deki “@”yı git index'i gibi kullanıp commit anında “@-” üzerine squash ederek git add --patch benzeri bir etki elde edebilirsiniz

  • Ekibi jj'ye geçirmek istiyorum ama pek başarılı olamıyorum
    git'te karmaşık görünen işleri jj ile ne kadar kolay yapabildiğinizi bir bakışta gösteren bir sayfa olsa güzel olurdu
    adeta bir elevator pitch gibi kısa ve net
    sanırım benim bizzat demo yapıp göstermem de gerekecek

    • Birçok kişinin sık yaptığı git işi Jujutsu'da daha kolay olmayabilir
      aksine, Jujutsu'nun gücü git'te imkânsız ya da zahmetli olan yeni iş akışlarında
      bu da mevcut git düzenine alışmış geliştiricilere hemen cazip gelmeyebilir

    • Ben de git'i özellikle seviyor değilim
      geçmişte sadece Mercurial kullanırdım ama artık git tamamen zihnime yerleşmiş durumda
      Jujutsu'nun çok net bir avantajı olsa bile, ilk kurulumla (karmaşık renk ayarları, alışık olduğum script düzeni vb.) uğraşmaya değecek kadar çekici gelmiyor

    • Benim için jj ile git arasındaki tek bir temsilî işin karşılaştırılması epey açıklayıcı olmuştu
      https://lottia.net/notes/0013-git-jujutsu-miniature.html

    • İşe yarayabilecek güzel bağlantılar da önereyim
      https://v5.chriskrycho.com/essays/jj-init/
      https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/
      https://ofcr.se/jujutsu-merge-workflow

    • Bu yazıya yakında ekleyeceğim bir sonraki bölüm muhtemelen hoşunuza gidecek
      yakında sayfanın altına ve ayrı bir yazı olarak ekleyeceğim

  • Birkaç haftadır jj kullanıyorum ve otomatik commit mesajı script'i bile yazdım
    bugün aynı script'i eski bir git reposuna taşımaya çalışırken, git'te commit mi amend mi olduğunu otomatik ayırt edecek kod yazmam gerektiğini fark ettim
    jj'de immutable commit yapısı sayesinde script çok daha basitti
    ben de repo'yu doğrudan jj ile yeniden clone ettim
    commit ile amend karmaşasından bir anda kurtuldum
    https://codeberg.org/jcdickinson/nix/src/branch/main/home/common/scripts/jj-auto.fish

    • Yeniden clone etmeniz şart değil, mevcut git reposunda jj'yi ayrıca kullanabilirsiniz

  • git zaten yeterince iyi çalışıyor
    biraz öğrenme eğrisi var ama bir kez kavrayınca her şey anlam kazanıyor
    dürüst olmak gerekirse durumların %95'inde pull, add, reset, branch ve commit bilmek yeterli

    • Benim iş akışımda stacked diff vazgeçilmez
      review beklerken tıkanmamak ve gelecekteki işleri önceden yığabilmek için çok iyi
      git'te kurmak zor değil ama stack'in alt tarafına değişiklik ekleyip her şeyi yeniden restack etmek tam bir cehennem

    • Birlikte çalışılan ortamlarda rebase/squash bilmek şart
      ekibin tamamını bunları kullanmamaya ikna etmeden bundan kaçamazsınız
      özellikle birkaç kişinin aynı branch'te acele geliştirme yaptığı durumlarda git alışkanlıkları ciddi bir sürtünme yaratıyor
      temel kullanım rahat ama karmaşık durumlarda çok sorun çıkarıyor

    • Sıra dışı birkaç durumla bile karşılaşsanız git'in eksileri ortaya çıkıyor

  • Yaklaşık 2 haftadır jj kullanıyorum ve ilk kez sürüm kontrolünü yalnızca komut satırından rahatça yönetebiliyorum
    git kullanırken hep GUI'ye (VSCode'daki Git Graph) geçip çoğunlukla sağ tıklama yapıyordum
    amma jj'de sadece öğreticiyi okuyarak bile doğrudan tutarlı bir komut satırı akışına geçebildim
    ancak jj log'undan sürekli id kopyalayıp yapıştırmamak için galiba revset dilini öğrenmem gerekecek

    • Ben de benzer durumdayım
      git'i uzun süredir kullanıyorum ama karmaşık işleri hep UI ile hallediyordum
      neredeyse bir aydır sadece jj CLI kullanıyorum ve oldukça memnunum
      amma jj'nin resmî belgeleri temel bilgi varmış varsayımıyla yazıldığı için yeni başlayanlar bazen zorlanabiliyor
      daha fazla blog yazısı ve öğretici görmek isterim
      ben de revset diliyle rebase'i biraz daha öğrenmek istiyorum
      sade CLI, çatışma çözümü ve oplog çok hoşuma gidiyor

    • Ben de id kopyala-yapıştırdan bıkmıştım ama jjui(https://github.com/idursun/jjui) kullanınca her şey çok daha akıcı oldu
      adeta log'u tarar gibi hızlıca çalışabiliyorum

  • Bence jj'nin en iyi özelliği undo
    git'te undo, yapılan hatanın türüne göre farklı komutlar gerektirdiği için zor
    jj'de tek bir jj undo yeterli
    arka plandaki sisteme de bağlı olmadığından, yerelde tek başınıza jj kullansanız bile ekip arkadaşlarınızı etkilemiyor

  • jj'nin ne olduğunu anlamakta zorlanıyorum
    git'te kafası karışanlar için bir frontend mi diye merak ediyorum
    backend soyutlaması yaptığını söylüyor ama git'ten o kadar etkilenmiş görünüyor ki Perforce ya da Piper gibi sıralı numaralı commit dayatan sistemlerde nasıl işleyeceğini hayal etmek zor
    working copy = commit tasarımının kalite kontrolü imkânsız kıldığını düşünüyorum
    sonuçta commit'in özü, yalnızca gerçekten istenen şeylerin kaydedilmesi
    böyle bir yapıda “çöp commit”leri ayırt etmek daha da zorlaşıyor gibi
    hem git hem jj büyük projelerde zayıf kalıyor ve commit kalabalığını önleyemiyor gibi duruyor
    jj'nin gerçekte hangi sorunu çözdüğünü merak ediyorum; yoksa sadece yazarının zevkine göre yapılmış bir frontend mi?

    • Piper backend'i aslında Git backend'inden bile daha doğal çalışıyor
      jj commit'leri git commit'leriyle bire bir aynı şeyler değil, o yüzden öyle düşünmeyin
      pratikte “commit” dediğiniz şey daha çok “isimlendirilmiş diff” gibi
      push'tan önce değişiklikleri istediğiniz gibi kolayca yeniden düzenleyip toparlayabilirsiniz
      bu, git'teki rebase ve geçmiş düzenlemelerinden çok daha rahat
      ben deneyler, dokümantasyon vb. için işin ortasında birden çok commit oluşturuyorum; git'te olsaydı bunları stash'e ya da geçici branch'lere sıkıştırmak zorunda kalırdım

    • jj, git frontend'inden daha fazlası
      bir sürüm kontrol sistemi ve backend-agnostic
      en yaygın backend git olduğu için mevcut repolarda hemen kullanmaya başlayabiliyorsunuz
      ben GitHub çıkmadan önceki dönemden beri git kullanan biriyim ama jj'yi kullandıktan sonra git'e dönemem
      jj daha basit ama aynı zamanda daha güçlü
      working copy = commit mantığını aslında “index de bir commit'tir” gibi anlamak lazım
      örneğin feature x üzerinde çalışmaya başlarken jj new -m "working on feature x" trunk ile yeni bir commit oluşturup üstüne bir tane daha boş commit ekliyorsunuz
      çalışma çıktınız working copy'de (@) duruyor, bunu önceki commit'e (@-) “taşıyarak” (squash) git'teki add-p, reset gibi karmaşık seçenekler yerine her şeyi commit'ler arası diff üzerinden yönetiyorsunuz
      bu yapı sayesinde git index'inden daha esnek ve güçlü şekilde commit bölme ve düzenleme yapabiliyorsunuz
      commit kalabalığı meselesi daha çok pull request kültürüyle ilgili ve jj bunu ancak kısmen çözebilir

    • working copy rastgele GitHub'a push edilmiyor; açıklama eklerken gözden geçirip düzenlemeniz yeterli

  • jj'yi birkaç gün denedim ama mevcut lazygit düzenimden, iş akışımdan ve script kurulumumdan yeterince memnunum
    jj yenilikçi ve güzel ama sürüm kontrolüne yeni başlayan biri değilseniz değiştirmek için güçlü bir motivasyon sunmuyor

    • GitButler gibi başka araçlar kullanıyorsanız frontend daha az önemli oluyor ama ben birkaç gün önce Jujutsu'yu kurdum, Claude'a temel işlemleri (commit, branch değiştirme, GitHub'a push/pull) sordum ve 10 dakika içinde alıştım
      Lazygit'in diff görünümünü hâlâ kullanıyorum ama detached HEAD durumunda olmak hiç sorun yaratmıyor
      JJ git ile çok iyi uyumlu ve karmaşık komutları ezberlemek zorunda kalmadan her şeyi çok daha kolay yapmanızı sağlıyor
      branch'ler arasında geçerken commit edilmemiş dosyaların otomatik taşınması en iyi özellik olabilir
      geliştirme, bug fix, metin değişikliği gibi işler arasında gidip gelmek çok kolay oluyor
      AI ajanları değişiklik yapıyorsa ayrı worktree kullanabilirsiniz
      iş bitmeden önce değişiklik açıklamasını (= commit mesajını) ekleyip ağaçta önceden görebilmek de gerçekten çok iyi
      JJ genel olarak oldukça müthiş