Tạo tên nhánh sinh ra tốt hơn với `jj`

 (ddbeck.com)
1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • jj là hệ thống quản lý phiên bản tương thích Git, khuyến khích dùng các nhánh ẩn danh, nhưng để push lên kho Git thì vẫn cần bookmark, tức là tên nhánh Git
  • Mặc định, jj git push --change xyz sẽ tạo nhánh push-xyz; cách này xoay quanh change ID nên rất tự nhiên trong CLI, nhưng trên danh sách GitHub thì khó nhớ nhánh đó đang làm gì
  • Có thể cải thiện bằng cách đổi mẫu git_push_bookmark để biến dòng đầu của phần mô tả thành một slug ngắn bằng slugify(), rồi nối thêm change ID ngắn ở phía sau
  • jj git push --change ozkspkuyzpwu sẽ tạo add-note-about-jj-bookmark-templates/ozkspkuyzpwu, giúp dễ đọc hơn mà vẫn giữ được liên kết với revision
  • Khi push vào kho dùng chung, có thể thêm namespace như ddbeck/ ở phía trước, nhưng quy tắc tên nhánh Git khá phức tạp nên nếu tên sinh ra không hợp lệ thì cần tạo bookmark thủ công

Cải thiện tên nhánh dùng cho Git push của jj

  • jj(Jujutsu) là một hệ thống quản lý phiên bản tương thích Git và vì nhiều lý do, nó kỳ vọng cũng như khuyến khích sử dụng nhánh ẩn danh
  • Khi push lên kho Git, ngay cả nhánh ẩn danh cũng cần có tên; trong jj nó được gọi là bookmark, còn trong Git thì gọi là branch
  • jj git push --change xyz sẽ push revision có ID xyz lên nhánh Git push-xyz
  • Thiết lập mặc định này khá tự nhiên vì nhấn mạnh change ID mà CLI của jj thường xuyên hiển thị và sử dụng, nhưng trong danh sách nhánh trên website GitHub thì chỉ nhìn push-xyz sẽ khó nhớ đó là công việc gì

Cách thay đổi cấu hình

  • Tạo mới template alias slugify() và chỉnh mẫu git_push_bookmark để dùng nó
[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() dùng dòng đầu của mô tả thay đổi để tạo tên dạng slug ngắn, rồi gắn thêm change ID ngắn ở cuối
  • Ví dụ, khi chạy jj git push --change ozkspkuyzpwu thì sẽ tạo ra add-note-about-jj-bookmark-templates/ozkspkuyzpwu
  • Tên này dễ đọc hơn mà vẫn giữ được kết nối với revision ID hiển thị trong CLI của jj
  • Nếu bạn push vào kho được chia sẻ với người khác, có thể đổi mẫu để đặt nhánh của mình dưới một namespace riêng
[templates]
git_push_bookmark = '"ddbeck/" ++ slugify(description) ++ "/" ++ change_id.short()'
  • Không thể đảm bảo tên nhánh Git lúc nào cũng an toàn
  • Quy tắc tên nhánh hợp lệ của Git khá phức tạp; nếu mẫu tạo ra tên không hợp lệ thì sẽ phát sinh lỗi và bạn phải tự tạo bookmark thủ công

Bài viết liên quan

1 bình luận

 
GN⁺ 3 giờ trước
Ý kiến trên Lobste.rs

  • Tôi đang dùng khá hiệu quả cách đưa metadata vào commit message rồi tận dụng nó
    Trước hết tạo alias trailer_v(key) để dễ lấy giá trị trailer từ phần mô tả commit, rồi trong script push bằng nushell dùng jj log để ghép nhãn branch theo dạng ticket/topic
    Ví dụ nếu trong commit message có ticket:TKT-123, topic:stop-crashing, thì script sẽ lấy các giá trị đó để push lên GitHub và mở trang "Create PR"
    Git trailers rất hay vì là một kho key-value có thể dùng nhất quán trong phần mô tả, nhưng hiện tại việc lấy ra dùng trong ngôn ngữ revset vẫn hơi bất tiện

  • Việc slug hóa tên branch dựa trên commit message hoặc nội dung thay đổi có vẻ là kiểu việc mà một LLM cục bộ xử lý rất dễ

    • Tôi thấy không hẳn có lý do phải dùng LLM. Script đơn giản trong bài nhẹ hơn, có lẽ nhanh hơn, và chắc cũng hoạt động gần như tốt tương tự

  • Đồng đội của tôi đã hỏi về tên branch do jj tự động tạo ra nhiều lần
    Tôi đang nghĩ sẽ thử một biến thể của cách này cho các branch commit dùng một lần

  • Theo tôi thì tên branch dựa trên change-id là hoàn hảo. Tôi không thực sự muốn đổi nó
    Đây chỉ là tên branch mà mấy công cụ review code tệ hại yêu cầu, chứ không phải tiêu đề

    • Tôi nhìn chung vẫn hài lòng với tên branch tự sinh mặc định, nhưng khi push một nhóm thay đổi để tạo PR thì đôi lúc có thể khó phân biệt mỗi PR nên nhắm vào branch nào
      Có lẽ cũng có thể giải quyết bằng công cụ tự động hóa việc tạo PR, nhưng cách này hay ở chỗ đơn giản
    • Ở $JOB, việc dùng tên branch mang tính mô tả là thông lệ