jj ile daha iyi üretken branch adları oluşturmak

• jj, Git uyumlu bir sürüm kontrol sistemi ve anonim branch’leri öneriyor; ancak bir Git deposuna push etmek için bookmark, yani bir Git branch adı gerekiyor
• Varsayılan jj git push --change xyz, push-xyz branch’ini oluşturuyor; bu change ID odaklı yaklaşım CLI’da doğal olsa da GitHub listesindeyken yapılan işi hatırlatmakta yetersiz kalabiliyor
• git_push_bookmark şablonunu değiştirip açıklamanın ilk satırını slugify() ile kısa bir slug’a dönüştürmek ve sonuna kısa change ID eklemek mümkün
• jj git push --change ozkspkuyzpwu, add-note-about-jj-bookmark-templates/ozkspkuyzpwu adını üretip okunabilirliği ve revizyon bağlantısını birlikte koruyor
• Paylaşılan depolarda başa ddbeck/ gibi bir namespace eklenebilir; ancak Git branch adı kuralları karmaşık olduğundan geçersizse manuel bookmark oluşturmak gerekiyor

---

jj için Git push branch adlarını iyileştirme

• jj(Jujutsu), Git uyumlu bir sürüm kontrol sistemi ve çeşitli nedenlerle anonim branch kullanımını bekliyor ve öneriyor
• Bir Git deposuna push ederken anonim branch’lerin de bir ada ihtiyacı var; jj buna bookmark, Git ise branch diyor
• jj git push --change xyz, kimliği xyz olan revizyonu Git branch’i push-xyz olarak push eder
• Varsayılan davranış, jj CLI’ın sıkça gösterip kullandığı change ID’yi öne çıkardığı için doğal; ancak GitHub web sitesindeki branch listesinde push-xyz tek başına hangi işin yapıldığını hatırlatmakta zorlanıyor

Yapılandırmayı değiştirme yöntemi

• template alias slugify() yeniden tanımlanıp git_push_bookmark şablonunun bunu kullanması sağlanıyor

[template-aliases]
"slugify(str)" = '''
truncate_end(
65,
str.first_line()
.replace(regex:'[^[[:alnum:]].]', '-')
.replace(regex:'-{2,}', '-')
.replace(regex:'\.{2,}', '.')
.replace(regex:'(^-+|-+$)', '')
.lower()
)
'''
[templates]
git_push_bookmark = 'slugify(description) ++ "/" ++ change_id.short()'

• slugify(), değişiklik açıklamasının ilk satırını kullanarak kısa bir slug biçiminde ad üretir ve sonuna kısa change ID’yi ekler
• Örneğin jj git push --change ozkspkuyzpwu çalıştırıldığında add-note-about-jj-bookmark-templates/ozkspkuyzpwu oluşturulur
• Bu ad, daha okunabilir olurken jj CLI’da gösterilen revizyon ID’si ile bağlantıyı da korur
• Başkalarıyla paylaşılan bir depoya push ediyorsanız, branch’lerinizi ayrı bir namespace altında tutacak şekilde şablonu değiştirebilirsiniz

[templates]
git_push_bookmark = '"ddbeck/" ++ slugify(description) ++ "/" ++ change_id.short()'

• Git branch adlarının her zaman güvenli olacağı garanti edilmez
• Git’in geçerli branch adı kuralları karmaşıktır; şablon geçersiz bir ad üretirse hata oluşur ve bookmark’ı manuel olarak oluşturmanız gerekir

[GN⁺]

Lobste.rs görüşleri

• Commit mesajına metadata ekleyip kullanma yaklaşımını oldukça verimli buluyorum
  Önce commit açıklamasından trailer değerini kolayca çekmek için trailer_v(key) adında bir takma ad oluşturup, ardından nushell push script’inde jj log ile ticket/topic biçiminde branch etiketi oluşturuyor
  Örneğin commit mesajına ticket:TKT-123, topic:stop-crashing eklerseniz, GitHub’a push edip "Create PR" sayfasını açan script bu değerleri alıp kullanıyor
  Git trailers, açıklama içinde tutarlı şekilde kullanılabilen iyi bir anahtar-değer deposu, ancak şu anda revset dilinden alıp kullanmak biraz zahmetli

• Commit mesajına veya değişiklik içeriğine dayanarak branch adını slug’laştırmak, yerel bir LLM’in kolayca halledebileceği bir alan gibi geliyor

  • LLM kullanmak için gerçekten bir neden var mı emin değilim. Yazıdaki basit script daha hafif, muhtemelen daha hızlı ve neredeyse aynı derecede iyi çalışacaktır

• Ekip arkadaşlarım birkaç kez jj’nin otomatik oluşturduğu branch adıyla ilgili soru sormuştu
  Tek seferlik commit branch’leri için bunun bir varyasyonunu kullanmayı düşünüyorum

• change-id tabanlı branch adı bence mükemmel. Özellikle değiştirmek istemem
  Bu, korkunç bir code review aracının istediği branch adından ibaret; bir başlık değil

  • Varsayılan otomatik oluşturulan branch adından da genel olarak memnunum, ancak değişiklik gruplarını push edip PR’ye dönüştürürken her PR’nin hangi branch’i hedeflemesi gerektiği bazen karışabiliyor
    Bunu PR oluşturmayı otomatikleştiren bir araçla da çözebilirsiniz, ama bu yaklaşımın sadeliği hoşuma gidiyor
  • $JOB’de açıklayıcı branch adları kullanmak bir gelenek