นักพัฒนาได้สร้างเครื่องมือ Git ตัวใหม่ที่เรียกว่า what-changed-twice เพื่อช่วยจัดการประวัติ commit ที่ยุ่งเหยิง แต่ชื่อที่ฟังดูแปลกๆ ของเครื่องมือนี้ได้จุดประกายการสนทนาที่น่าสนใจในชุมชนเกี่ยวกับแนวทางการตั้งชื่อและเครื่องมือที่คล้ายคลึงกันที่มีอยู่แล้ว
ปัญหาที่เครื่องมือนี้แก้ไข
เครื่องมือนี้แก้ไขปัญหาเวิร์กโฟลว์ทั่วไปของนักพัฒนา โปรแกรมเมอร์หลายคนมักทำ commit บ่อยๆ ระหว่างการพัฒนา ทำให้เกิดลูกโซ่ของการเปลี่ยนแปลงที่เกี่ยวข้องกันกระจายอยู่ใน commit หลายๆ ตัว ตัวอย่างเช่น คุณอาจแก้ไขไฟล์ในวันจันทร์ เพิ่มการเปลี่ยนแปลงเพิ่มเติมในวันอังคาร และแก้ไขการสะกดคำผิดในวันพุธ เมื่อถึงเวลาที่ต้องทำความสะอาดประวัติ commit การระบุไฟล์ไหนที่ถูกแก้ไขหลายครั้งจึงกลายเป็นสิ่งสำคัญสำหรับการจัดระเบียบอย่างเหมาะสม
เครื่องมือนี้วิเคราะห์ผลลัพธ์จาก Git log และสร้างรายงานที่แสดงไฟล์ที่เปลี่ยนแปลงใน commit มากกว่าหนึ่งตัว พร้อมกับ commit ID แบบย่อที่การเปลี่ยนแปลงเหล่านั้นเกิดขึ้น สิ่งนี้ช่วยให้นักพัฒนาตัดสินใจว่า commit ไหนควรรวมเข้าด้วยกันระหว่างการ rebase
ฟังก์ชันการทำงานของเครื่องมือ: วิเคราะห์ผลลัพธ์จาก Git log เพื่อระบุไฟล์ที่ถูกแก้ไขในหลาย commit แล้วแสดงผล commit ID แบบย่อและเส้นทางไฟล์เพื่อให้อ้างอิงได้ง่ายระหว่างการดำเนินการ rebase
ชุมชนแสดงความเห็นเรื่องการตั้งชื่อ
การสนทนาเรื่องการตั้งชื่อเผยให้เห็นมุมมองที่น่าสนใจจากชุมชนนักพัฒนา ผู้ใช้บางคนปกป้องชื่อเดิม โดยโต้แย้งว่ามันอธิบายฟังก์ชันของเครื่องมือได้อย่างชัดเจน คนอื่นๆ เสนอทางเลือกอื่น เช่น git-repeatedly-changed ตามแนวทางการตั้งชื่อของ Git หรือตัวเลือกที่สร้างสรรค์มากกว่า เช่น squash-what และ git-delta-delta
สมาชิกชุมชนคนหนึ่งได้ให้ความเห็นที่ลึกซึ้งเป็นพิเศษเกี่ยวกับแนวทางการตั้งชื่อของ Git :
หากคุณมี git-foo ใน PATH คุณสามารถทำ git foo และมันจะเลือกโปรแกรมของคุณโดยอัตโนมัติ
สิ่งนี้เน้นให้เห็นว่าการตั้งชื่ออย่างเหมาะสมสามารถผสานเข้ากับโครงสร้างคำสั่งที่มีอยู่ของ Git ได้อย่างราบรื่น
ข้อเสนอชื่อจากชุมชน:
- git-repeatedly-changed
- squash-what
- git-delta-delta
- Double Jeopardy
- FlipFlopStop (FFS)
เครื่องมือที่มีอยู่และทางเลือกอื่น
การสนทนายังดึงความสนใจไปที่เครื่องมือที่คล้ายคลึงกันที่มีอยู่แล้ว สมาชิกชุมชนหลายคนกล่าวถึง git-absorb ซึ่งนำแนวคิดนี้ไปไกลกว่าด้วยการคิดออกโดยอัตโนมัติว่าการเปลี่ยนแปลงไหนควรรวมเข้ากับ commit ก่อนหน้า เครื่องมือนี้มีอยู่สำหรับทั้งระบบควบคุมเวอร์ชัน Git และ Jujutsu และสามารถใช้ได้ใน repository ของ distribution ส่วนใหญ่
การสนทนาเผยให้เห็นว่าในขณะที่เครื่องมือของนักพัฒนาเน้นไปที่การระบุและวิเคราะห์ โซลูชันอื่นๆ เช่น git-absorb ให้ความสามารถในการแก้ไขอัตโนมัติ
เครื่องมือทางเลือกที่กล่าวถึง:
- git-absorb: ผลักดันการเปลี่ยนแปลงไปยังคอมมิตก่อนหน้าที่เหมาะสมโดยอัตโนมัติ
- Jujutsu absorb: ฟังก์ชันการทำงานที่คล้ายกันในระบบควบคุมเวอร์ชัน Jujutsu
- มีให้ใช้งานในพื้นที่เก็บข้อมูลของดิสทริบิวชัน Linux ส่วนใหญ่
ข้อพิจารณาทางเทคนิคและข้อจำกัด
สมาชิกชุมชนยังได้ยกประเด็นทางเทคนิคที่สำคัญเกี่ยวกับข้อจำกัดของเครื่องมือ แม้ว่าจะสามารถระบุ commit ที่ไม่ก่อให้เกิดข้อขัดแย้งทางข้อความเมื่อจัดเรียงใหม่ แต่ไม่สามารถทำนายข้อขัดแย้งทางความหมายที่อาจทำให้การทดสอบหรือฟังก์ชันการทำงานเสียได้ ความแตกต่างนี้มีความสำคัญสำหรับนักพัฒนาที่ต้องการรักษา commit ระหว่างกลางที่ทำงานได้เทียบกับผู้ที่สนใจเฉพาะผลลัพธ์สุดท้ายที่สะอาดที่จุด merge
การสนทนาเน้นให้เห็นปรัชญาที่แตกต่างกันเกี่ยวกับการจัดการประวัติ commit โดยนักพัฒนาบางคนชอบ atomic commit ที่ผ่านการทดสอบเสมอ ในขณะที่คนอื่นๆ เน้นไปที่ผลลัพธ์สุดท้ายที่สะอาดที่จุด merge
อ้างอิง: My new git utility 'what-changed-twice` needs a new name