jj – Jujutsu için CLI

 (steveklabnik.github.io)
2 puan yazan GN⁺ 15 일 전 | 1 yorum | WhatsApp'ta paylaş
  • jj, Jujutsu'nun komut satırı arayüzü olup dağıtık sürüm kontrol sistemi (DVCS) tabanlı bir araçtır
  • gitten daha basit ve sezgisel, aynı zamanda daha güçlü özellikler sunar
  • git ile Mercurial'ın avantajlarını birleştirerek çekirdek araç sayısını azaltır ve organik entegrasyonu güçlendirir
  • git uyumlu backend kullanarak mevcut iş birliği ortamını korurken bağımsız denemeler yapmayı mümkün kılar
  • İleri düzey kullanıcılar için, git ile zor olan ek sürüm kontrol özelliklerinden yararlanabilmek önemli bir noktadır

jj'ye giriş ve öne çıkan özellikleri

  • jj, Jujutsu'nun CLI'ıdır (komut satırı arayüzü) ve Jujutsu bir dağıtık sürüm kontrol sistemidir (DVCS)

    • Kullanıcılar git gibi başka DVCS'lere aşina olabilir; öğretici de git kullanıcılarının bakış açısını temel alır
    • jj, gitten daha basit, kullanımı daha kolay ama yine de güçlü bir araç olarak tasarlanmıştır
    • Genelde “güçlülük” ile “karmaşıklık” arasında bir ödünleşim vardır, ancak jj bu dengeye yeni bir yaklaşım sunar
    • jj, git ile Mercurial'ın (hg) güçlü yanlarını birleştirerek yeni bir DVCS biçimi oluşturur
    • Çekirdek araç sayısını azaltır ve araçlar arasındaki organik entegrasyon sayesinde verimli bir çalışma ortamı sunar
    • İleri düzey kullanıcılar, git ile zor olan ek sürüm kontrol özelliklerinden yararlanabilir
    • jj, git uyumlu bir backend kullanır; böylece iş birliği ortamını değiştirmeden bağımsız denemeler yapılabilir
    • Mevcut git depolarıyla uyumluluğu korur ve gerektiğinde kolayca gite geri dönülebilir
    • Öğretici, bu özellikler üzerinden jjnin neden dikkat çekici bir araç olduğunu doğrudan gösterme sürecini haber verir

İlgili okumalar

1 yorum

 
GN⁺ 15 일 전
Hacker News yorumları

  • Tartışmaların çoğu git ile jj arasındaki farklara odaklanıyor, ama bence git'i unutup doğrudan jj'nin temel iş akışına odaklanmak daha iyi
    Temiz bir depoda jj çalıştırınca durumu görebiliyorsun; değişiklik yaptıktan sonra da jj commit -m "made changes" ile commit atıyorsun
    Hata yaptığında düzeltip jj squash ile son commit'e birleştirebilirsin
    Yalnızca belirli bir revizyondan, sanki yeni bir branch'miş gibi çalışmak istediğinde jj new -r lmnop kullanman yeterli
    git geçmişine git log ile bakılabiliyor ve jj'nin iç işleyişi görünmüyor

    • Ben de benzer bir şey istediğim için alias.save="!git add -A; git commit -m" gibi bir git alias oluşturup $ git save "made changes" şeklinde kullanıyordum

  • JJ benden sanki ters düşünmemi istiyor gibi geliyor
    git'te değişiklikten sonra commit mesajı yazarsın, ama jj'de önce yeni bir commit oluşturup sonra açıklama ekliyorsun
    Birden fazla özelliğin karıştığı dağınık bir durumda yalnızca gereken değişiklikleri seçip commit atmaya alışığım, ama sadece jj eğitimine bakınca bunun mümkün olup olmadığından emin olamadım

    • jj new, boş bir git staging alanı gibi düşünülebilir
      jj'de her zaman bir commit vardır ve bu commit, klasör içeriğine göre hesaplanan bir değer olarak kararlı bir changeid taşır
      Birden fazla değişikliği bölerek commit etmek istiyorsan jj split kullanabilirsin
    • Ben sık sık jj new ile geçici commit'ler oluşturup mesajı boş bırakıyorum
      Sonra hazır olduğumda birkaç commit'i squash edip tek bir commit'te birleştiriyor ve mesaj ekliyorum
      Bu yaklaşım bir tür undo geçmişi gibi çalışıyor ve denemeler yapmayı çok daha rahat hale getiriyor
    • Aslında jj new, sadece “üstte yeni bir commit oluştur” demek; yani hemen açıklama yazman gerekmiyor
      Ben de başta bunu alışkanlık haline getirmeye çalıştım ama aslında verimsizdi
    • JJ'de bu yaklaşım standart sayılıyor
      Git tarafında da benzer bir iş akışı uzun zamandır öneriliyordu; Squash Workflow ile Git'in index'ine benzer bir akış kurulabiliyor
    • Ben de sık sık birden fazla değişiklik yaparken farklı özellikleri birbirine karıştırıyorum
      Bu yüzden birden çok workspace tutuyor ve shelve özelliğini (IntelliJ) sık kullanıyorum
      Bazen diff'i geçici olarak saklamak için git patch de kullanıyorum
      Tüm bu kaotik süreci ekip arkadaşlarımdan gizleyip biraz daha profesyonel görünmeye çalışıyorum

  • jj'yi deneyince hoşuma gitmeyen şey, dosya düzenlemelerinin otomatik olarak commit'e yazılması oldu
    Eski commit'leri incelemek için checkout yaptıktan sonra dosyayı düzenlersen, o commit değişiyor ve sonraki geçmişin tamamı rebase ediliyor
    Bu yüzden kendimi korumak için savunmacı biçimde yeni boş commit'ler açmam gerekiyor
    git'te ben açıkça commit edene kadar depo değişmediği için bana daha rahat geliyor

    • Ben de eskiden böyle düşünüyordum ama jj evolog'u öğrendikten sonra fikrim değişti
      jj, staging'den daha iyi bir çözümü zaten sunuyormuş
      git CLI'a alışık olmak, ironik şekilde jj öğrenmenin önündeki engeldi
      İlginç olan şu ki, jj kullanınca git'in depolama motoru yapısını da daha iyi anlıyorsun
    • edit yerine jj new kullanırsan değişiklikleri temiz biçimde takip edebilirsin
      Bana göre bu, git stash ile cambazlık yapmaktan çok daha iyi
    • jj edit, jj'nin en büyük tuzağı
      Onun yerine jj new kullan; hata yaparsan jj undo ile geri alabilirsin
      jj commit'leri ucuz snapshot'lar gibi ele aldığı için, commit'ten çok “değişiklik”e odaklanmak daha doğru
      Otomatik rebase de push'tan sonra değişmez hale gelerek güvenli oluyor
    • Dosya düzenlemelerinin otomatik commit'e yazılması, jj'nin temel özelliği
      jj new ve jj squash kombinasyonuyla bunu git branch head'i gibi yönetebilirsin
      jj, detached head durumunda çalışmayı kolaylaştırıyor
    • Muhtemelen geçmiş bir commit'i jj edit ile checkout ettin
      Bunu jj new ile değiştirirsen sorun çözülür

  • jj hakkındaki son paragraf asıl kilit nokta
    Tam uyumlu bir git backend'i kullandığı için, tüm ekibin değiştirmesine gerek kalmadan tek başına deneyebilirsin
    Beğenmezsen istediğin zaman git'e dönebilirsin

    • Ancak LFS, submodule ya da hook kullanan organizasyonlarda istisnalar var
    • Tam uyum denemez. Birlikte çalışabilirler ama kusursuz derecede pürüzsüz değil
      git işlemleri jj log'una kaydedilmiyor, elle import etmek gerekiyor
      Bir projede tek bir arayüz kullanılması tavsiye ediliyor
    • Eskiden ben de git'i CVS ve Subversion'la birlikte bu şekilde kullanıyordum
    • Ama git ile jj'yi aynı dizinde aynı anda kullanırsan işler bozulabilir

  • En sevdiğim özellik açık ara jj absorb
    Mevcut revizyondaki değişiklikleri otomatik olarak önceki ilgili commit'lere taşıyor
    Yapılandırma dosyasında ya da .gitignore içinde bir şeyi değiştirmeyi unuttuğunda çok kullanışlı
    jj new deyip değişikliği yapıp sonra jj absorb çalıştırman yeterli
    Üstelik merge conflict ile uğraşmak zorunda kalmamak en güzel yanı

    • Eğer jj absorb yanlış uygulanırsa jj undo ile geri alabilirsin
      Bu özellik sayesinde karmaşık rebase'lerden bile korkmuyorum
    • Bu arada git tarafında da git absorb var

  • Eğitimi uzun süredir güncelleyemedim ama hâlâ her gün jj kullanıyorum
    Startup'ım ersc.io ile meşgul olduğum için upstream katkılarına vakit ayıramadım
    Sorusu olan olursa her zaman memnuniyetle yardımcı olurum

    • git ile jj arasındaki DAG değişmezliği farkı asıl mesele
      jj kararlı change ID kullanıyor, git ise immutable commit ID kullanıyor
      Bu yüzden jj'de undo ya da rebase çok daha esnek hissettiriyor
    • jj, “ilginç olmayan” değişiklikleri otomatik olarak gizliyor
      Bazen daha fazla değişiklik görmek istiyorum; bunu tek seferde gösteren bir seçenek olup olmadığını merak ediyorum

  • jj, git'ten farklı olduğu için denemeye değer
    Sadece başka bir yaklaşımı görmek bile mühendislik bakış açını genişletiyor
    Her şeyi denemek zorunda değilsin ama farklı iş akışlarının trade-off'larını anlamak önemli

    • Tabii, vakaların %99'unda kazancı çok az olan denemeler zaman kaybı da olabilir

  • git ile jj arasındaki ilişki bana C ile Python arasındaki ilişkiyi hatırlatıyor
    git daha çok adli iz sürme gibi, jj ise hikâyenin bölümleri gibi
    Bazen ilk bölümleri yeniden yazmak, sonraki bölümlerin daha doğal akmasını sağlar

    • jj'nin yaptığı şeyler git'te de mümkün, ama git'in alışkanlık haline gelmiş düşünme biçimi engel oluyor
      jj, “working tree'nin kendisi bir commit'tir” ve “conflict de commit edilebilir” anlayışıyla tasarlanmış

  • “Daha güçlü ve daha kolay” iddiası için somut örneklere ihtiyaç var gibi geliyor

    • jj'nin bazı avantajlarını sıralarsam:
      • rebase/merge conflict'lerini hemen çözmek zorunda değilsin
      • commit'lerle oynamak çok kolay (özellikle jjui kullanırken)
      • jj, git durum değişikliklerini izleyen bir operation log tutuyor
      • İsimsiz branch'ler sayesinde deneysel işler özgürce yapılabiliyor
      • git ile tamamen uyumlu olduğu için ekip içinde karışık kullanım mümkün
    • Biz SVN'den git'e geçtiğimizde büyük gelişme hissetmiştik, ama şu anki git iş akışımızda büyük bir rahatsızlık yaşamıyoruz
    • Tek bir depoda aynı anda birden fazla PR üzerinde çalışıp her birini uygun şekilde push edebilirsin
      Böyle bir ihtiyacın yoksa jj'nin değerini hissetmeyebilirsin
    • jj'nin çekiciliği komutlarında değil, sezgisel iş akışında
      Bunu anlamak için bizzat kullanmak gerekiyor
    • Sadece jj undo bile tek başına yeterince değerli
      git'te geri dönüşü olmayan durumlara düşmek kolayken, jj'de birkaç undo ile toparlanabiliyorsun

  • jj sayesinde doğrusal olmayan DAG yapısını kullanma konusunda kendime güvenim arttı
    Birden fazla parent ya da child içeren değişikliklerle rahatça çalışıyorum
    Eskiden gereksiz yere sıralama dayatıyordum, şimdi ise bağımlılık ilişkilerini açıkça ifade edebiliyorum
    İnceleme ve gönderim süreci de çok daha verimli hale geldi

    • Bu dallanmış değişiklikler üzerinde mega-merge + absorb iş akışını kullanıp kullanmadığını merak ediyorum