LazyGit - Git UI สำหรับนักพัฒนาสายขี้เกียจ

 (bwplotka.dev)
12 คะแนน โดย GN⁺ 2025-11-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • lazygit เครื่องมือ Git UI บนเทอร์มินัล ผสานความเรียบง่ายของบรรทัดคำสั่งเข้ากับความใช้งานง่ายแบบกราฟิกอินเทอร์เฟซ เพื่อมอบสภาพแวดล้อมการทำงานที่รวดเร็วและสม่ำเสมอ
  • ออกแบบโดยยึดหลัก ความสม่ำเสมอ·การค้นพบได้ง่าย·การโต้ตอบได้ดี ทำให้แม้แต่มือใหม่ที่รู้เพียงแนวคิดพื้นฐานของ Git ก็เริ่มใช้งานได้ทันที
  • คีย์ไบน์สไตล์ vim และโครงสร้างภาพที่ชัดเจน ช่วยให้ไปยังส่วนต่าง ๆ ได้รวดเร็วและลดเวลางานที่ต้องทำซ้ำ
  • แพตช์ระดับบรรทัด, interactive rebase, cherry-pick ฯลฯ ช่วยลดความซับซ้อนของงาน Git ที่ยุ่งยากและเพิ่มประสิทธิภาพการทำงาน
  • สร้างบน เฟรมเวิร์ก TUI โอเพนซอร์สที่เขียนด้วย Go จึงเป็นกรณีศึกษาที่น่าสนใจสำหรับการออกแบบ UX ของเครื่องมือสำหรับนักพัฒนาตัวอื่นด้วย

ที่มาของ LazyGit

  • ผู้เขียนค้นพบประสิทธิภาพของเครื่องมือนี้โดยบังเอิญขณะรัน lazygit ระหว่างการทดลองกับ Neovim
    • หลังจากนั้นก็ย้ายเวิร์กโฟลว์ Git ทั้งหมดมาใช้ lazygit
  • ก่อนหน้านี้เคยใช้ git gui, gitk และ CLI แบบผสมกัน แต่ด้วย UI ที่ล้าสมัยและความไม่เสถียร จึงเริ่มมองหาเครื่องมือทดแทน
  • lazygit เรียบง่าย รวดเร็ว และมีโครงสร้างที่เข้ากันได้กับ CLI จึงสร้างความเชื่อมั่นด้านความน่าเชื่อถือ

จุดเด่นหลักของ LazyGit

ความสม่ำเสมอ (Consistency)

  • อินเทอร์เฟซประกอบด้วย “กล่องมุมมอง” หลายส่วน และคงโครงสร้างภาพแบบเดิมไว้เสมอ
    • เมื่อเลือกกล่องฝั่งซ้าย เนื้อหาฝั่งขวาจะเปลี่ยนตาม
  • ใช้ คำศัพท์และนามธรรมของ Git ตามเดิม จึงช่วยลดความชันของการเรียนรู้
    • ตัวอย่าง: สามารถค่อย ๆ เรียนรู้แนวคิดมาตรฐานของ Git อย่าง bisect, hunk ได้อย่างเป็นธรรมชาติ
  • ใช้ คีย์ไบน์แบบ vim (h/j/k/l, q, /, y, c, a, f, p, r เป็นต้น) เพื่อการควบคุมที่รวดเร็ว
  • จำกัดจำนวนคำสั่งและยึดตาม ปรัชญา Unix ที่ว่า “ทำสิ่งเดียวให้ดี”

การค้นพบได้ง่าย (Discoverability)

  • เมื่อเปิดใช้งานจะแสดงข้อมูลที่จำเป็นทันที
    • เช่น รีโพซิทอรีปัจจุบัน, บรันช์, สถานะ staging, คอมมิตล่าสุด, stash, คำสั่งล่าสุด, คีย์ลัด ฯลฯ
  • นำเสนอข้อมูลโดยไม่ทำให้ล้นสายตา จึงช่วย ลดการสลับบริบท
  • สามารถดูคีย์ลัดได้ทันทีผ่านฟุตเตอร์ด้านล่างหรือปุ่ม ?
  • ผู้ใช้จึง มองเห็นตำแหน่งและสถานะปัจจุบันได้อย่างเป็นธรรมชาติ ตลอดเวลา

การโต้ตอบได้ดี (Interactivity)

  • งาน Git ที่ซับซ้อนจะถูกนำทางผ่าน อินเทอร์เฟซแบบโต้ตอบ
    • ตัวอย่าง: ตอน push จะมีการเตือนความต่างกับ upstream และตอน rebase จะมีการถามว่าจะใช้แบบ interactive หรือไม่
  • ในกระบวนการ rebase, แก้ conflict, สลับ branch จะมีการยืนยันอัตโนมัติและเสนอขั้นตอนถัดไป
  • ไม่จำเป็นต้องพิมพ์คำสั่ง pick/drop/squash เอง แต่ใช้คีย์ลัดผสมจัดการได้เลย
  • รบกวนผู้ใช้น้อยที่สุด พร้อมเพิ่มทั้งความเชื่อมั่นและความเร็วในการทำงาน

เวิร์กโฟลว์ Git ที่ดีขึ้น

  • lazygit ไม่ได้เพิ่มเวิร์กโฟลว์ใหม่ แต่ช่วยให้ ใช้ความสามารถเดิมของ Git ได้เร็วและปลอดภัยยิ่งขึ้น
  • ฟีเจอร์ เลือกแพตช์ระดับบรรทัด·ระดับ hunk ช่วยให้กู้คืนโค้ดได้ละเอียดมากขึ้น
    • เช่น ย้อนกลับเพียงบางส่วนของคอมมิต หรือแยกบางส่วนออกมาได้
  • ตัวอย่างเวิร์กโฟลว์ลัดที่สำคัญ
    • แก้ไขคอมมิตเดิมและ push: 2 space A P enter
    • สร้างคอมมิตใหม่และ push: 2 space c <제목> P
    • rebase บรันช์: 3 r i ... m c
    • ลบคอมมิต: 4 d
    • แยกคอมมิต: 4 enter enter <c-p> n <제목> enter
    • cherry-pick: 3 4 C 3 4 V
  • เมื่อใช้ซ้ำบ่อย ๆ คีย์ลัดจะกลายเป็นความเคยชินตามธรรมชาติ และ เพิ่มความเร็วในการทำงานได้อย่างมาก

บทเรียนด้าน UX ของเครื่องมือสำหรับนักพัฒนา

  • ความเรียบง่าย, ความสม่ำเสมอ, การค้นพบได้ง่าย, ค่าเริ่มต้นที่สมเหตุสมผล, การโต้ตอบได้ดี ของ lazygit คือหลักการออกแบบเครื่องมือที่ยอดเยี่ยม
  • มีทั้ง ความสามารถในการปรับแต่งเชิงลึก, การขยายต่อได้, และ ระบบนิเวศการมีส่วนร่วมแบบโอเพนซอร์ส ที่แข็งแรง
  • สร้างบน เฟรมเวิร์ก TUI (gocui) ที่เขียนด้วยภาษา Go ทั้งหมด 100% และสามารถนำไปใช้พัฒนาเครื่องมืออื่นได้
  • ชี้ให้เห็นความเป็นไปได้ในการพัฒนาเครื่องมือ CLI/TUI ใหม่ ๆ ที่ประยุกต์ใช้แพตเทิร์น UX คล้ายกัน

บทสรุป

  • lazygit ไม่ได้เป็นแค่ Git UI ธรรมดา แต่ยังถูกมองว่าเป็น ตัวอย่างชั้นยอดของทั้ง productivity สำหรับนักพัฒนาและการออกแบบ UX
  • แม้ความสามารถช่วยเหลือจาก AI จะพัฒนาไปมากขึ้น แต่ในงานจัดการเวอร์ชันที่ต้องการ ความถูกต้องและความน่าเชื่อถือ ก็ยังคงมีบทบาทสำคัญ
  • ยังคงพัฒนาอย่างต่อเนื่องผ่านการมีส่วนร่วมและการทำงานร่วมกันของชุมชนโอเพนซอร์ส
  • ทุกคนสามารถใช้งานและร่วมพัฒนาได้ พร้อมมอบ ประสบการณ์ Git ที่รวดเร็วและเป็นธรรมชาติ

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

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

 
GN⁺ 2025-11-11
ความเห็นจาก Hacker News

  • เมื่อก่อนชอบ git TUI ที่เน้นคีย์บอร์ดอย่าง magit, neogit, lazygit
    แต่ตอนนี้ใช้ jujutsu(jj) แทน git แล้ว
    พอคุ้นกับ jj CLI ก็เริ่มใช้ jjui
    ผมต้องแยก commit บ่อย เลยพบว่าปลั๊กอิน hunk.nvim มีประโยชน์มาก
    แล้วสำหรับการแก้ jj conflict นั้น jj-diffconflicts ดีที่สุด
    ตอนนี้พอใช้ jj ก็แก้ไข commit graph ได้อย่างเป็นธรรมชาติ เหมือนย้ายบรรทัดโค้ดเลย

    • ขอบคุณสำหรับลิงก์เครื่องมือต่างๆ อยากรู้ว่ามีเครื่องมืออื่นที่ แยกหรือประกอบ diff ใหม่ใน patch series ได้อีกไหม
      เวลาเอา hunk ที่ไม่จำเป็นออกจาก commit เก่า มักเกิด conflict ลูกโซ่กับ commit ถัดๆ ไป เลยสงสัยว่ามีเครื่องมือที่จัดการเรื่องแบบนี้ให้อัตโนมัติไหม
    • ผมก็ย้ายจาก git ไป jj แบบเต็มตัวแล้ว แต่ยังใช้ การดู diff ของ lazygit อยู่ เพราะส่วนนั้นยังดูสะอาดกว่ามาก
      diff ที่แยกตามไฟล์ดูง่ายดี นี่เป็นเหตุผลเดียวที่ยังใช้ lazygit อยู่
    • ผมก็กำลังย้ายไป jj เหมือนกัน ยังไม่ได้ใช้กับทุกโปรเจกต์ แต่คงอีกไม่นาน
      แค่อยากให้มี GUI สำหรับ jj โดยเฉพาะ มากกว่านี้ เวลาที่อยากดูหลายการเปลี่ยนแปลงพร้อมกันผมใช้ gg แต่ไม่มี side-by-side diff
      ดูวิดีโอของ git butler แล้วก็คิดว่าถ้า UI ของ jj พัฒนาไปทางนั้นได้ก็คงดี
      ถ้ามี GUI ที่ลากย้ายการเปลี่ยนแปลงได้ หรือทำ split/rebase แบบโต้ตอบได้ก็คงเยี่ยม
    • ปัญหาของ git คือมัน ไม่กำหนดแนวทางชัดเจนเกินไป (unopinionated)
      แต่ละทีมมี git flow ของตัวเอง แล้วนักพัฒนาก็มักไปหมกมุ่นกับการจูนจุกจิกที่ไม่จำเป็นหรือไม่ยอมเรียนรู้
      สุดท้ายเลยกลายเป็นว่าทุกทีมต้องมีผู้เชี่ยวชาญ git ประจำทีม
      เอาจริงๆ อยากได้เครื่องมือที่บังคับให้ใช้วิธีเดียวไปเลยมากกว่า

  • อาจฟังดูขำ แต่ในบรรดา git UI ที่เคยใช้มา ยังไม่มีอะไรดีเท่า SourceTree
    เวลาทำงานง่ายๆ มันสบายกว่า CLI มาก และ มุมมองสถานะไฟล์กับประวัติ ก็ยอดเยี่ยมจริงๆ
    จะ stage/unstage เป็นระดับ hunk หรือระดับบรรทัดก็ง่าย
    แค่เสียดายที่ไม่มีเวอร์ชัน Linux ลองเครื่องมืออื่นมาหมดแล้วแต่สุดท้ายก็กลับมาใช้มัน
    ช่วงหลังๆ ก็ลอง lazygit เหมือนกัน และในบรรดา TUI ก็ถือว่าดีทีเดียว

    • เคยลอง magit ไหม ถึงจะอยู่บน Emacs และมีช่วงเรียนรู้ แต่เน้นคีย์บอร์ดเต็มรูปแบบ และแทบไม่มี workflow ไหนที่มันไม่รองรับ
    • ถ้าตอน commit ผมว่า Commit view ของ Git Extensions ดีที่สุด
      มันไม่มีการรีเฟรชอัตโนมัติ เลยไม่ชนกับ CLI
      เอกสาร Commit ของ Git Extensions
    • ผมชอบ Sublime Merge มากที่สุด เร็ว UI สะอาด ใช้งานได้ดีทุกแพลตฟอร์ม และซื้อไลเซนส์ครั้งเดียวจบ
    • ผมว่า Fork หรือ Tower ดีกว่า SourceTree มากนะ หรือว่าคุณใช้แต่เครื่องมือฟรีอย่างเดียว?
    • แทบไม่มี UI ไหนในโลกที่ผมเกลียดมากกว่า SourceTree แล้ว
      ผมเสียเวลาไปกับบั๊กและปัญหาแปลกๆ นับไม่ถ้วน ได้โปรด เลิกใช้ SourceTree เถอะ

  • ยิ่งใช้ git ตรงๆ มากเท่าไร ก็ยิ่งรู้สึกถึง ความไม่สมเหตุสมผลของอินเทอร์เฟซ git CLI
    ผมใช้ jj มา 2 ปีแล้ว และคงกลับไปใช้ git CLI ไม่ได้อีก
    เห็นคนสับสนกับ git จนสร้างปัญหาบ่อยเกินไป เลยแนะนำให้ไปใช้อย่างอื่นแทนเลย

    • ผมก็ลอง jj มาหลายครั้ง แต่ workflow ยังไม่เข้ามือ เลยทำงานช้าลง
      ผมชอบแยกการเปลี่ยนแปลงแล้ว commit จากใน editor แต่ jj ยังผสานกับ editor ได้ไม่ดีพอ สุดท้าย commit เลยออกมารกๆ

  • หลายคนหลีกเลี่ยงเพราะชื่อ แต่ GitHub Desktop นี่ดีพอตัวเลย
    มันทำงานกับ repo นอก GitHub ได้ดีด้วย และ แก้ไข commit กับ cherry-pick แบบรายไฟล์/รายบรรทัด ได้ง่าย
    งานที่ซับซ้อนแต่ละอย่างก็มีคำอธิบายกำกับไว้ เลยเหมาะกับมือใหม่มากเป็นพิเศษ
    ฟังก์ชัน merge หรือ graph อาจยังไม่เด่น แต่ผมก็ยังคิดว่ามันดีกว่า git CLI มาก
    เวลาเข้าทีมใหม่ ผมมักให้ใช้ GH Desktop ตลอด ทั้งพลาดน้อยลงและเข้าใจได้เร็วขึ้น

    • ผมก็เห็นด้วยกับ GH Desktop ฟีเจอร์อาจเพิ่มช้า แต่ทำอย่างระมัดระวัง
      สำหรับคนที่ไม่มั่นใจเรื่อง git นี่คือตัวเลือกที่ดีที่สุด
      ตรงกันข้าม ผมเห็น นักพัฒนาจูเนียร์ที่มั่นใจใน git เกินไป ทำ repo พังมาหลายครั้งเกินนับ
      เพราะงั้นผมเลยแนะนำ GH Desktop กับคนในทีมอย่างจริงจัง
    • การที่ GH Desktop ไม่มีการจัดการ merge/conflict และไม่มี graph อาจกลับกลายเป็นเหตุผลที่คนหลีกเลี่ยงมันก็ได้

  • ผู้ใช้ git จำนวนมากไม่รู้จัก git-absorb
    มันเข้ากับ git flow แบบไหนก็ได้ และช่วยลดความเจ็บปวดเวลา แก้ staged changes แล้วกระจายกลับไปหลาย commit
    TUI ส่วนใหญ่ไม่มีความสามารถแบบนี้

    • ดูมีประโยชน์นะ แต่ผมใช้ magit อยู่แล้ว เลยจัดการ commit กับ rebase ได้เร็วพอ
      เครื่องมือที่ทำด้วย Rust ผมไม่ค่อยชอบ เพราะ มี dependency เยอะเกินไป
    • อันนี้มีอยู่ใน repo ของ GNU/Debian ด้วย
    • ผมลองใช้มาหลายเดือนแล้ว แต่เคย squash commit ผิดจน repo ยุ่งไปครึ่งหนึ่ง
      ความเชื่อใจเลยลดลงและสุดท้ายก็เลิกใช้ มันทำงานเหมือนเวทมนตร์เกินไป จนกลับรู้สึกไม่สบายใจ
    • สำหรับผม ความชัดเจนของประวัติ สำคัญกว่า การเขียนประวัติใหม่เพื่อให้ชื่อสวยๆ ไม่ใช่ความคิดที่ดี

  • ผมยังคงชอบ tig
    ฟีเจอร์อาจน้อย แต่ UI เรียบง่ายและเร็ว
    ผมใช้มันหลักๆ เพื่อเพิ่มเข้า incremental index

    • ผมก็ใช้ tig สำหรับ stage แบบ hunk มานานกว่า 15 ปีแล้ว

  • VS Code ฟรี ข้ามแพลตฟอร์ม และหลายคนก็ใช้อยู่แล้ว
    git GUI ของมันก็ดี และรองรับ workflow ทั่วไปได้ครบ
    ปกติผมใช้ CLI แต่ถ้าเปิดโปรเจกต์ค้างไว้ใน VS Code อยู่แล้ว หลายครั้งทำผ่าน GUI จะเร็วและตรงไปตรงมามากกว่า

    • แต่ผมว่าปัญหาคือ คุณต้องใช้ VS Code เองนี่แหละ

  • ชุด LazyVim + tmux เปลี่ยนวิธีใช้ git ของผมไปเลย
    ผมตั้งให้กด ctrl-g แล้ว tmux floating pane ที่เปิด lazygit ในไดเรกทอรีปัจจุบันโผล่ขึ้นมา
    เลยทำงานกับ git ได้ทันทีโดยไม่ต้องเข้าไปใน neovim หรือสลับ UI
    สำหรับ workflow ที่เน้นเทอร์มินัล นี่คือประสบการณ์ที่ ยืดหยุ่นและลื่นไหล ที่สุด

    • ช่วงนี้ผมก็เพิ่งรู้จัก tmux display-popup
      ถ้าเพิ่มสิ่งนี้ลงใน ~/.tmux.conf 
      bind-key C-g display-popup -E -d "#{pane_current_path}" -xC -yC -w 80% -h 75% "lazygit"
      ก็จะกด ctrl-b ctrl-g เพื่อเปิดป๊อปอัป lazygit และกด q เพื่อปิดได้

  • ผมทำงาน git ด้วย คำสั่งเสียง + AI ไม่อย่างนั้นก็คิดว่า ctrl-r เป็น UI ที่เพียงพอแล้ว

  • ยังไม่มีใครพูดถึง แต่ Gitu ก็เป็นไคลเอนต์ที่ใช้ได้ดีเหมือนกัน