ข่าวด้านเทคนิคเกี่ยวกับ GitUI

 (github.com/extrawurst)
10 คะแนน โดย GN⁺ 2024-01-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • GitUI เป็นเครื่องมือที่มอบความสะดวกและประสบการณ์การใช้งานแบบ Git GUI ภายในเทอร์มินัล โดยเริ่มจากกรณีผู้ใช้ที่พบว่า Git GUI เดิมค้างหรือช้าลงเมื่อใช้งานกับ repository ขนาดใหญ่มาก
  • ฟีเจอร์หลักประกอบด้วย การควบคุมด้วยคีย์บอร์ดล้วน, ความช่วยเหลือตามบริบท, การตรวจสอบการเปลี่ยนแปลง·commit·amend, stage/unstage/revert/reset ระดับไฟล์·hunk·line, stash, push/fetch, การจัดการ branch, การค้นหา commit log และการดู diff
  • จากการเปรียบเทียบที่ parse commit มากกว่า 900,000 รายการใน Linux Git repository นั้น gitui ทำเวลาได้ 24 วินาที และใช้หน่วยความจำ 0.17GB ขณะที่ lazygit ทำได้ 57 วินาที·2.6GB และ tig ทำได้ 4 นาที 20 วินาที·1.3GB
  • เป้าหมายก่อน 1.0 ได้แก่ การแสดงโครงสร้าง branch เป็นภาพ ในแท็บ log และ interactive rebase ส่วน git-lfs, sparse repo และการจัดการ credential.helper อัตโนมัติสำหรับ HTTPS ยังมีข้อจำกัดที่ทราบอยู่
  • ปัจจุบันยังไม่ได้แทนที่ Git shell อย่างสมบูรณ์ แต่เป็นเครื่องมือที่เหมาะกับการใช้ร่วมกันเพื่อเสริมงานที่ทำใน Git shell ได้ไม่สะดวก เช่น stash หรือ staging ระดับ line·hunk

เครื่องมือที่นำประสบการณ์ Git GUI มาไว้ในเทอร์มินัล

  • GitUI เป็นเครื่องมือโอเพนซอร์สที่มอบประสบการณ์ผู้ใช้และความสะดวกแบบ Git GUI ในเทอร์มินัล
  • แรงจูงใจในการพัฒนามาจากประสบการณ์ที่แม้จะทำงาน Git ส่วนใหญ่ในเทอร์มินัล แต่ก็ยังต้องใช้ Git GUI บ่อยครั้งสำหรับงานอย่าง index, commit, diff, stash, blame และ log
  • Git GUI ยอดนิยมที่มีอยู่เดิมมีปัญหาเมื่อเจอ repository ขนาดใหญ่มาก เช่น ทำงานล้มเหลว ไม่ตอบสนอง หรือใช้งานไม่ได้
  • GitUI มุ่งสร้างประสบการณ์ Git GUI ภายในเทอร์มินัลที่ portable, fast, free และ opensource

ขอบเขตฟีเจอร์

  • โมเดลการใช้งานเน้น การควบคุมด้วยคีย์บอร์ดล้วน และความช่วยเหลือตามบริบท โดยออกแบบมาให้ไม่จำเป็นต้องจดจำ shortcut จำนวนมาก
  • งานเกี่ยวกับการเปลี่ยนแปลงประกอบด้วย
    • inspect, commit, amend การเปลี่ยนแปลง
    • รองรับ hook pre-commit, commit-msg, post-commit, prepare-commit-msg
    • stage, unstage, revert, reset ระดับไฟล์, hunk, line
  • รองรับงานเกี่ยวกับ flow ของ repository ด้วย
    • stash save, pop, apply, drop, inspect
    • push ไปยัง remote, fetch จาก remote
    • สร้าง branch, เปลี่ยนชื่อ, ลบ, checkout, ดู remotes
    • สำรวจ commit log และ ค้นหา, ดู diff ของการเปลี่ยนแปลงที่ commit แล้ว
  • UI และการทำงานภายในประกอบด้วย UI เทอร์มินัลแบบตอบสนองเร็ว, Git API แบบ asynchronous เพื่อการใช้งานที่ลื่นไหล และการรองรับ submodule
  • รองรับ GPG commit signing แต่มีข้อจำกัดที่เกี่ยวข้องกับ #97

ผล benchmark

  • ในงานนำเสนอ RustBerlin meetup มีการเปรียบเทียบ lazygit, tig, gitui โดย parse ทั้งหมดของ Linux Git repository
    • repository เป้าหมายมี commit มากกว่า 900,000 รายการ
    • เอกสารประกอบการนำเสนอเชื่อมไปยัง RustBerlin meetup presentation และ slides
  • ผลการเปรียบเทียบเป็นดังนี้
    • gitui: 24 วินาที, หน่วยความจำ 0.17GB, ไบนารี 10MB, ไม่มี freeze, ไม่มี crash
    • lazygit: 57 วินาที, หน่วยความจำ 2.6GB, ไบนารี 25MB, มี freeze, มี crash เป็นบางครั้ง
    • tig: 4 นาที 20 วินาที, หน่วยความจำ 1.3GB, ไบนารี 0.6MB, มี freeze เป็นบางครั้ง, ไม่มี crash
  • ในการเปรียบเทียบนี้ gitui ทำค่าได้ต่ำที่สุดในหัวข้อเวลาและหน่วยความจำ

Roadmap ก่อน 1.0 และข้อจำกัดที่ทราบ

  • เป้าหมายระดับสูงก่อนเรียกเป็น 1.0 มีสองข้อ
    • แสดงโครงสร้าง branch เป็นภาพในแท็บ log: #81
    • interactive rebase: #32
  • ข้อจำกัดในปัจจุบันประกอบด้วย
    • ยังไม่รองรับ git-lfs: #2812
    • ยังไม่รองรับ sparse repo: #1226
    • สำหรับ HTTPS ต้องตั้งค่า credential.helper อย่าง ชัดเจน: #800
  • ปัจจุบัน GitUI ยังไม่ได้แทนที่ Git shell อย่างสมบูรณ์ และเหมาะกับการใช้ทั้งสองเครื่องมือร่วมกัน
  • ลำดับความสำคัญมุ่งไปที่ฟีเจอร์ที่ทำใน Git shell ได้ไม่สะดวก เช่น stash และ staging ระดับ line·hunk
  • ขณะนี้โปรเจกต์เป็น spare time project และต้องการความช่วยเหลือหากจะทำให้ GitUI เป็น one stop solution

การติดตั้งและการ build

  • GitUI อยู่ในสถานะ beta และอาจมีบั๊กหรือฟีเจอร์ที่ยังขาดอยู่
  • สำหรับการใช้งานส่วนตัวถือว่ามีเสถียรภาพพอสมควร และถูกใช้ในการพัฒนา GitUI เองด้วย
  • ติดตั้งได้ผ่าน package manager หลายตัว
    • Arch Linux: pacman -S gitui
    • Fedora: sudo dnf install gitui
    • openSUSE: sudo zypper install gitui
    • Homebrew: brew install gitui
    • MacPorts: port install gitui
    • Winget: winget install gitui
    • Scoop: scoop install gitui
    • Chocolatey: choco install gitui
    • Mise: mise use -g gitui@latest
    • Termux: pkg install gitui
    • Anaconda: conda install -c conda-forge gitui
  • มี release binary สำหรับ Linux, macOS และ Windows
    • Linux มีแพ็กเกจ x86_64, aarch64, arm, armv7
    • macOS มีแพ็กเกจ arm64 และ Intel x86
    • Windows มีไบนารีเดี่ยว 64bit และแพ็กเกจติดตั้ง MSI 64bit
  • ข้อกำหนดสำหรับการ build มีดังนี้
    • เวอร์ชัน rust/cargo ขั้นต่ำที่รองรับคือ 1.88
    • ต้องใช้ perl 5.12 ขึ้นไปและ C compiler เพื่อ build dependency ของ OpenSSL
    • การรัน test suite ทั้งหมดต้องมี Python ที่เรียกใช้ได้ด้วย python
  • หากใช้ Cargo สามารถเริ่ม build และติดตั้งด้วยคำสั่ง cargo install gitui --locked
  • Cargo feature trace-libgit จะเปิดใช้ tracing ของ libgit2 และทำงานเมื่อ libgit2 ถูก build ด้วย -DENABLE_TRACE=ON
  • feature นี้เปิดใช้งานเป็นค่าเริ่มต้น และหากต้องการปิดให้ใช้ cargo install --no-default-features

การตั้งค่า การวินิจฉัย และการปรับแต่ง

  • เปิดใช้ logging ด้วย gitui -l
  • ตำแหน่งไฟล์ log แตกต่างกันตามแพลตฟอร์ม
    • macOS: $HOME/Library/Caches/gitui/gitui.log
    • Linux with XDG: $XDG_CACHE_HOME/gitui/gitui.log
    • Linux: $HOME/.cache/gitui/gitui.log
    • Windows: %LOCALAPPDATA%/gitui/gitui.log
  • GitUI ควรทำงานอัตโนมัติได้ทั้งกับธีมเทอร์มินัลแบบ light และ dark
  • สามารถปรับแต่งธีมสีได้ตาม THEMES.md
  • สามารถปรับแต่ง key binding ได้ตาม KEY_CONFIG.md และตั้งเป็น binding สไตล์ vim ได้
  • โปรเจกต์ที่เป็นแรงบันดาลใจ ได้แก่ lazygit, tig, GitUp, git-brunch
  • สำหรับ GitUp มีเป้าหมายเพิ่มเติมว่าอยากหาวิธีใช้ map view ในเครื่องมือเทอร์มินัลได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-08
ความคิดเห็นบน Hacker News

  • พอติดตั้งเสร็จ หน้าต่าง xterm ก็เล็กเกินไป เลยขยายหน้าต่าง แล้วพยายามลากขอบของพื้นที่ tree ไฟล์ให้แคบลง แต่ทำไม่ได้
    อยากดู diff ให้ใหญ่ขึ้น และชื่อไฟล์ก็สั้น ทำให้พื้นที่ tree ส่วนใหญ่สูญเปล่า แต่ในหน้าช่วยเหลือ H ก็ไม่มีคีย์ที่เกี่ยวข้อง เลยดูเหมือนว่า ปรับขนาดด้วยคีย์บอร์ด ก็ไม่ได้เช่นกัน
    ต่อให้ทำได้ด้วยคีย์บอร์ด กรณีแบบนี้ การปรับขนาดด้วยเมาส์ ก็ง่ายและเร็วกว่าเยอะ และถ้ามีการปรับด้วยคีย์บอร์ดไว้สำหรับตอนที่ใช้เมาส์ไม่ได้ เช่นสภาพแวดล้อม SSH ที่มีปัญหา ก็น่าจะดี

    • การเพิ่ม การรองรับเมาส์ในเทอร์มินัล เพื่อเสริมคีย์ลัดคีย์บอร์ดมีประโยชน์มากจริง ๆ
      แม้แต่ใน Vim ส่วนที่ยังใช้แทร็กแพด/เมาส์อยู่ก็คือการเลื่อนและการปรับขนาดหน้าต่าง และไม่มีเหตุผลอะไรที่ผ่าน SSH แล้วจะให้ทั้งสองอย่างไม่ได้
      น่าจะเป็นฟีเจอร์เสริมที่ดีสำหรับที่นี่ด้วย

  • lazygit ถูกระบุว่าเป็นแรงบันดาลใจของโปรเจกต์นี้ ในฐานะผู้ใช้ lazygit เลยสงสัยว่ามันขาดอะไรไปจนต้องมีโปรเจกต์ใหม่ทั้งโปรเจกต์
    ผมใช้ lazygit ได้มีประโยชน์มาก

    • ตัดสินยากว่าวิธีวัดนั้นสมเหตุสมผลหรือไม่ แต่ถ้ามองด้วยสายตาผู้จัดการ ตัวเลขค่อนข้างน่าประทับใจ
      สำหรับการนำเสนอในมีตอัป RustBerlin ได้ parse ทั้ง repository Git ของ Linux เพื่อเปรียบเทียบ lazygit, tig, gitui และใน repository มี commit มากกว่า 900,000 รายการ
      gitui ใช้เวลา 24 วินาที หน่วยความจำ 0.17GB ไบนารี 1.4MB ไม่มีค้าง ไม่มี crash ส่วน lazygit ใช้เวลา 57 วินาที, 2.6GB, 16MB, มีค้าง, crash เป็นบางครั้ง และ tig ใช้เวลา 4 นาที 20 วินาที, 1.3GB, 0.6MB, ค้างเป็นบางครั้ง, ไม่มี crash
    • ใช้ lazygit ทุกวันมาหลายปี และเคยลองตัวนี้เมื่อไม่กี่เดือนก่อน มันดูเหมือนเป็นกรณีที่สร้างขึ้นเพื่อ เขียนเครื่องมือที่เกือบสมบูรณ์แบบใหม่ด้วย Rust
      เท่าที่จำได้ ไม่มีฟีเจอร์ไหนที่ lazygit ไม่มี แต่กลับขาดบางฟีเจอร์ที่มีใน lazygit ด้วยซ้ำ
    • README ระบุแรงจูงใจไว้
      งาน Git ส่วนใหญ่ทำในเทอร์มินัล แต่สำหรับงานอย่าง index, commit, diff, stash, blame, log มักจะหันไปใช้ Git GUI และบอกว่า Git GUI ยอดนิยมใช้ไม่ได้กับ repository ขนาดใหญ่มาก เพราะล้มเหลวหรือไม่ตอบสนอง

  • คำว่า “Git GUI ยอดนิยมใช้ไม่ได้กับ repository ขนาดใหญ่มาก เพราะล้มเหลวหรือไม่ตอบสนอง” ผมเคยเห็นเฉพาะตอนที่ git status ใช้เวลานานบน command line หรือ magit เพราะมี tree ไดเรกทอรีลึกมาก ๆ ที่ยังไม่ได้ใส่ใน .gitignore
    กรณีแบบนี้ผมคิดว่าไม่มีความต่างระหว่างการใช้ Git ผ่าน GUI/TUI/command line
    อินเทอร์เฟซ Git อื่น ๆ ล้มเหลวรุนแรงกว่า Git เองมากขนาดนั้นหรือ?

    • ผมคิดว่ารูปแบบความล้มเหลวของ Magit มาจากการทำงานย่อยที่ดึง ข้อมูล diff มาในหน้า status
      ตอนมีปัญหาเดียวกัน git status บน command line ก็จบแทบจะทันที
      ถ้าจะโชว์ข้อมูลจำนวนมาก ก็เลี่ยงไม่ได้ที่ต้องใช้เวลา แต่ magit ในบางจุดทำงานแบบ eager เกินไป ทำให้ workflow แพงกว่า flow ของ Git ดิบ ๆ มาก
    • merge ใหญ่ ๆ ผมจะไม่ทำใน magit เด็ดขาด เรื่องแบบนั้นใช้ Git CLI
    • ถ้าอย่างนั้นก็น่าแปลกใจ
      Git UI ของ IntelliJ เขียนด้วย Java และฝังอยู่ใน IDE แต่ก็ยังเร็วพอ ดังนั้น Git UI ภายนอกก็น่าจะไม่มีปัญหา

  • บทความที่เกี่ยวข้อง:
    GitUI: Terminal UI for Git - https://news.ycombinator.com/item?id=32864036 - กันยายน 2022, 90 ความคิดเห็น
    Terminal-UI for Git written in Rust - https://news.ycombinator.com/item?id=25504811 - ธันวาคม 2020, 1 ความคิดเห็น

  • มีใครเคยทำ UI แบบคลิกแล้วลาก สำหรับ Git ไหม?
    หมายถึง UI ที่ทำงานได้โดยแค่ลาก branch ไปวางอะไรทำนองนั้น

    • Git GUI ที่ชอบที่สุดคือ Fork: https://git-fork.com/
      รองรับ drag and drop สำหรับหลายงาน เช่น merge, rebase, stage/unstage และน่าจะมีอย่างอื่นอีก
    • งานพื้นฐานใช้ GitHub Desktop ส่วนงานซับซ้อนใช้ CLI
      เป็น Git client ที่ค่อนข้างเรียบง่าย แต่มี ฟังก์ชันลาก เล็กน้อยสำหรับงานอย่าง cherry-pick commit
    • เคยเห็น extension ตัวหนึ่งชูเรื่องนั้นเป็นหนึ่งในฟีเจอร์โฆษณา แต่ยังไม่เคยลองใช้
      https://marketplace.visualstudio.com/items?itemName=trunkflo...
    • ผ่านไป 10 ปี ถ้าต้องใช้คลิกแล้วลากใน UI ก็ยังใช้ SourceTree เป็นหลัก

  • ลองใช้เครื่องมือพวกนี้มาหมด แต่ก็มักจะขาดฟีเจอร์หลักสักอย่าง หรือไม่ทำงานในแบบที่ต้องการ สุดท้ายเลยกลับไปใช้ tig อยู่ดี
    ใน GitUI ผมหาการแสดงผลที่แสดงโครงสร้าง branch ได้ดีในที่อย่างมุมมอง Log ไม่เจอ
    อยากได้เครื่องมือที่แสดงโครงสร้าง branch ได้ดีเพื่อพิจารณา rebase

  • ดูดี น่าจะลองใช้ดู
    หวังว่าสักวัน GitExtensions จะถูกพอร์ตเป็นแอป Linux แบบ native
    ลองใช้ UI มาหลายสิบตัวแล้ว แต่ดูเหมือนไม่มีอะไรเทียบได้

    • หลังย้ายมา Linux แอป Windows ตัวเดียวที่คิดถึงทุกวันคือ TortoiseGit
      ยังไม่มี Git UI ตัวไหนที่ทำให้ระบบแบบ context menu ใช้งานได้เป็นธรรมชาติเหมือน TortoiseGit
    • แปลกใจเสมอที่มีนักพัฒนารู้จัก GitExtensions น้อยขนาดนี้
      Git UI ตัวอื่นที่ใกล้เคียงมีแค่ Tortoise แต่เมื่อก่อนผมเคยลองใช้แค่ variant ของ hg
    • Gitex ยอดเยี่ยม
      บน Linux ผมยังใช้เวอร์ชัน 2.x mono อยู่

  • ดูคล้ายปลั๊กอิน Neovim ชื่อ neogit ที่ผมเริ่มใช้เมื่อประมาณหนึ่งเดือนก่อนมาก
    key binding ยังหยาบ ๆ นิดหน่อย และใช้เวลาประมาณหนึ่งชั่วโมงกว่าจะคุ้นกับ workflow ทั้งหมดจริง ๆ แต่พอคุ้นแล้วก็เร็วกว่าแนวทางเดิม คือ suspend neovim แล้วไปใช้ Git โดยตรงใน shell มาก
    0: https://github.com/NeogitOrg/neogit

  • สิ่งหนึ่งที่กังวลเกี่ยวกับเครื่องมือ UI คือหลายครั้งมันซ่อนคำสั่งจริงจากผู้ใช้ ทำให้ภายหลังยากที่จะอนุมานว่าอะไรผิดพลาด และควรหลีกเลี่ยงอย่างไรต่อไป
    ตัวอย่างเช่น บางเครื่องมืออาจใส่ flag ที่ค่อนข้างยึดแนวทางตัวเองและไม่สอดคล้องกับ flow CLI ปกติ
    ไม่รู้ว่าตัวนี้เป็นแบบนั้นไหม แต่สำหรับเครื่องมือประเภทนี้ นี่อาจเป็น feedback ที่น่าสนใจ

    • เพราะอย่างนั้นบน Windows ผมถึงใช้และชอบ GitExtensions
      มันแสดงคำสั่งทั้งหมดที่รันเสมอ และดู log ทั้งหมดได้ครบถ้วน