การเปิดตัว Edamagit ซึ่งเป็น extension ของ VSCode ที่นำฟังก์ชัน Git แบบ Magit มาสู่ editor ยอดนิยมของ Microsoft ได้จุดประกายการถกเถียงอย่างร้อนแรงเกี่ยวกับความจงรักภักดีต่อ editor และความท้าทายในการสร้าง tool ที่เป็นที่รักขึ้นมาใหม่บนแพลตฟอร์มที่แตกต่างกัน แม้ว่า extension นี้จะมีเป้าหมายเพื่อให้การใช้งาน Git แบบขับเคลื่อนด้วยคีย์บอร์ดคล้ายกับ package Magit ที่มีชื่อเสียงของ Emacs แต่การตอบสนองจากชุมชนกลับเผยให้เห็นคำถามที่ลึกซึ้งกว่าเกี่ยวกับสิ่งที่ทำให้ tool บางตัวไม่สามารถถูกแทนที่ได้
ความท้าทายในการสร้าง Magic ของ Magit ขึ้นมาใหม่
Edamagit เสนอการใช้งาน Git ที่คุ้นเคยผ่าน keyboard shortcuts รวมถึงฟังก์ชัน staging, committing, branching และ rebasing อย่างไรก็ตาม ผู้ใช้ Magit ที่มีประสบการณ์ชี้ให้เห็นข้อจำกัดพื้นฐานในการทำงานของ VSCode extensions เมื่อเปรียบเทียบกับ Emacs packages ปัญหาหลักอยู่ที่การแยกตัว - VSCode extensions ไม่สามารถโต้ตอบกันโดยตรงหรือเข้าถึงฟังก์ชันภายในได้ ในขณะที่ Emacs packages สามารถผสานรวมและขยายความสามารถของกันและกันได้อย่างราบรื่น
ความแตกต่างทางสถาปัตยกรรมนี้หมายความว่าแม้ว่า Edamagit จะสามารถทำซ้ำ interface ของ Magit ได้ แต่ก็ไม่สามารถสร้างการผสานรวมที่ลึกซึ้งซึ่งทำให้ตัวต้นฉบับมีพลังมากได้ ผู้ใช้จะสูญเสียความสามารถในการรวมฟังก์ชัน Magit กับ tool อื่น ๆ สร้าง workflow ที่กำหนดเอง หรือขยายฟังก์ชันผ่านการเปลี่ยนแปลงการกำหนดค่าง่าย ๆ
คุณสมบัติหลักของ Edamagit :
- อินเทอร์เฟซ Git แบบใช้คีย์บอร์ดที่ได้แรงบันดาลใจจาก Emacs Magit
- ทางลัดเริ่มต้น: Alt+X+G สำหรับสถานะ, Alt+X+Ctrl+G สำหรับการส่งคำสั่ง
- รองรับการ staging, committing, branching, rebasing และการดำเนินการ Git อื่นๆ
- รองรับการใช้คีย์ Vim ผ่านการปรับแต่ง keybindings.json ของ VSCode
- รองรับ Monorepo ด้วยการตรวจจับ .git หลัก
- การตั้งค่าสำหรับฟังก์ชัน forge, การจัดตำแหน่งบัฟเฟอร์ และการยืนยันการสลับอย่างรวดเร็ว
ภาวะกลืนไม่เข้าคายไม่ออกของการย้าย Editor
การถกเถียงได้เผยให้เห็นรูปแบบที่น่าสนใจในหมู่นักพัฒนาที่พยายามย้ายจาก Emacs ไปยัง editor หลักกระแสมากขึ้น หลายคนอ้างว่า Magit เป็นเหตุผลหลักที่ทำให้พวกเขายังคงผูกติดอยู่กับ Emacs แม้จะถูกดึงดูดโดย ecosystem และ interface ที่ใช้งานง่ายของ VSCode ผู้ใช้บางคนรายงานว่าใช้ Edamagit สำหรับ Git workflows ที่ง่ายกว่าได้สำเร็จ ในขณะที่ยังคงเปลี่ยนกลับไปใช้ Emacs สำหรับงาน version control ที่ซับซ้อน
คุณสมบัติเด่นคือการทำให้ git รู้สึกเหมือนเป็นส่วนขยายธรรมชาติของการแก้ไขข้อความแทนที่จะเป็น tool แยกต่างหาก UI ของ git อื่น ๆ มีอยู่ แต่ไม่มีตัวไหนที่ผสานรวม cycle การแก้ไข-ตรวจสอบ-commit ได้อย่างราบรื่นเท่านี้
การปรากฏของ tool ที่คล้ายกันเช่น Neogit สำหรับ Neovim และทางเลือก TUI ต่าง ๆ แสดงให้เห็นว่าอิทธิพลของ Magit ขยายไปไกลเกินกว่าชุมชน Emacs โดยสร้างแรงบันดาลใจให้กับการออกแบบ interface ในแพลตฟอร์มต่าง ๆ
ทางเลือกที่ได้รับแรงบันดาลใจจาก Magit:
- Neogit - การใช้งานบน Neovim
- Gitu - แอปพลิเคชันส่วนต่อประสานผู้ใช้แบบเทอร์มินัล
- GitSavvy - ส่วนขยายสำหรับ Sublime Text
- Jjui - ส่วนต่อประสานสำหรับระบบควบคุมเวอร์ชัน Jujutsu
- Stage - แอปพลิเคชันแบบสแตนด์อโลนสำหรับ Linux (อยู่ระหว่างการพัฒนา)
ทางเลือกในตัวที่กำลังได้รับความนิยม
เรื่องราวย่อยที่ไม่คาดคิดในการถกเถียงเกี่ยวข้องกับผู้ใช้ที่ค้นพบว่าฟังก์ชัน Git blame ในตัวของ VSCode ได้รับการปรับปรุงอย่างมีนัยสำคัญ ทำให้หลายคนถอนการติดตั้ง extension GitLens ที่ได้รับความนิยมแต่มีโฆษณามากขึ้นเรื่อย ๆ การตกแต่ง blame แบบ native มีรายงานว่าเร็วกว่าและรบกวนน้อยกว่า แม้ว่าผู้ใช้บางคนจะพบว่ามันตอบสนองเกินไปและรบกวนสมาธิระหว่างการนำทางโค้ดอย่างรวดเร็ว
แนวโน้มนี้ที่หันไปใช้ฟังก์ชันในตัวแทนที่จะใช้ extension ของบุคคลที่สามสะท้อนถึงความปรารthนาที่กว้างขึ้นสำหรับสภาพแวดล้อมการพัฒนาที่สะอาดและไม่รกรุงรัง ผู้ใช้ให้ความสำคัญกับประสิทธิภาพและความเรียบง่ายมากกว่า extension ที่มีฟีเจอร์มากมายแต่อาจมาพร้อมกับเนื้อหาโปรโมชันที่ไม่ต้องการ
คุณสมบัติ Git ที่มีมาพร้อมกับ VSCode:
- การแสดง blame decorations แบบดั้งเดิม (เร็วกว่า GitLens )
- เทมเพลตแถบสถานะ blame ที่ปรับแต่งได้:
${authorName} (${authorDate}) ${subject} - ความสามารถในการ diff และ merge ที่มีมาพร้อม
- แผงควบคุมซอร์สโค้ดแบบรวมเข้าด้วยกัน
- ตัวดู Git tree และประวัติการ commit
ปรัชญาของความผูกพันต่อ Tool
การถกเถียงยังได้สัมผัสกับคำถามที่ลึกซึ้งกว่าเกี่ยวกับการเชี่ยวชาญและความผูกพันต่อ tool ผู้ใช้ Emacs มายาวนานอธิบายความสัมพันธ์ของพวกเขากับ editor ว่าเป็นมากกว่าแค่การใช้ซอฟต์แวร์ - มันกลายเป็นแพลตฟอร์มสำหรับสร้าง workflow ส่วนบุคคลที่พัฒนาไปตลอดหลายทศวรรษ ระดับของการปรับแต่งและการผสานรวมนี้ยากที่จะทำซ้ำใน editor ที่มีสถาปัตยกรรม extension ที่เข้มงวดกว่า
สำหรับนักพัฒนาที่กำลังพิจารณาว่าจะลงทุนเวลาในการเรียนรู้ tool ที่ซับซ้อนเช่น Emacs หรือยึดติดกับตัวเลือกที่เข้าถึงได้ง่ายกว่า การถกเถียงแสดงให้เห็นว่าการเลือกมักจะขึ้นอยู่กับลำดับความสำคัญของแต่ละบุคคล: ประสิทธิภาพในทันทีเทียบกับศักยภาพในการปรับแต่งระยะยาว
การเปิดตัว Edamagit แสดงถึงทั้งความน่าดึงดูดของหลักการออกแบบของ Magit และความท้าทายที่ต่อเนื่องในการสร้าง tool ที่ผสานรวมลึกซึ้งขึ้นมาใหม่ในแพลตฟอร์มต่าง ๆ แม้ว่ามันอาจไม่สามารถแทนที่ตัวต้นฉบับสำหรับ power user ได้อย่างสมบูรณ์ แต่ก็เสนอสะพานเชื่อมสำหรับผู้ที่แสวงหา Git workflows ที่คุ้นเคยในสภาพแวดล้อม editor หลักกระแสมากขึ้น
อ้างอิง: edamagit