วิธีที่จะกระทำการ refactoring ในความคืบหน้า?

ดังนั้นฉันจึงมีโครงการขนาดใหญ่นี้ซึ่งอยู่ในกระบวนการของการปรับโครงสร้างใหม่โดยฉัน ฉันกำลังเปลี่ยนแปลงสิ่งต่าง ๆ มากมายดังนั้นจึงไม่มีโอกาสที่จะรวบรวมมันในไม่ช้า ฉันอาศัยอยู่ในสาขา git พิเศษที่ฉันตั้งชื่อcleanup(ซึ่งจะถูกรวมเข้าmasterในที่สุดแน่นอน)

ปัญหาคือว่าฉัน / เรามีนโยบายที่จะไม่คอมไพล์โค้ดที่ไม่คอมไพล์ (โดยหลักแล้วมันควรจะทำงานได้ แต่มันต้องคอมไพล์และลิงค์อย่างน้อยที่สุด) ดังนั้นจนกว่าฉันจะเสร็จงานใหญ่นี้ฉันไม่สามารถกระทำอะไรได้ (สำหรับการตรวจสอบหรือการทำบัญชี)
นี่ไม่ใช่วิธีที่ฉันชอบทำงาน (ฉันเชื่อว่าคนส่วนใหญ่กระทำอย่างน้อยวันละครั้งหรือมากกว่านั้น)

คุณคิดอย่างไร? มีวิธีแก้ปัญหาที่ฉันมองเห็นหรือไม่?
ฉันจะบอก git ให้คอมมิชชันรวมหรืออะไรก็ได้ในภายหลัง? ฉันสามารถมีชีวิตอยู่ได้ด้วยความมุ่งมั่นที่ไม่ได้รวบรวมตราบใดที่พวกเขาอยู่ในcleanupสาขา

แก้ไข

ในเรื่องของการผลัก / กระทำ: ฉันรู้ว่ามันแตกต่างกันมาก แต่ต่อมาจะมีการแก้ไขที่ไม่สมบูรณ์เมื่อฉันรวมเนื้อหาของฉันเข้าmasterด้วยกัน ดังนั้นหากคุณเรียกดูประวัติ (หรือgit bisect... ) การแก้ไข "ท้องถิ่น" จะสามารถเข้าถึงได้ทั่วโลก ดังนั้นการกระทำในพื้นที่และไม่ผลักดันไม่ใช่ทางออกที่ดีที่สุดเพราะจะทำให้คุณเดือดร้อนในภายหลัง (เมื่อเรื่องถูกปิดและลืมไปสักระยะหนึ่ง)

ในระยะสั้น: ความมุ่งมั่นของท้องถิ่นจะถูกผลักในที่สุด ประวัติศาสตร์โลกไม่ควรแสดงคอมมิทที่ไม่ได้คอมไพล์

git merge --squashคำสั่งช่วยให้คุณสามารถสร้างเดียวกระทำที่ด้านบนของสาขาในปัจจุบันที่มีผลเป็นเช่นเดียวกับการควบรวมสาขาอื่น คำสั่งจะอัพเดตแผนผังการทำงานและเปลี่ยนการเปลี่ยนแปลงในดัชนีดังนั้นสิ่งที่คุณต้องทำต่อไปคือการคอมมิท:

git checkout master
git merge --squash cleanup
git commit -m "Merge cleanup branch"

git rebase -iคำสั่งยังสามารถกระทำสควอช แต่ต้องทำงานมากขึ้น

การเขียนซ้ำไม่ใช่การปรับเปลี่ยน

ฉันรู้ว่าคุณสนใจที่จะใช้ Git แต่ฉันขอยืนยันว่าคุณควรพิจารณาเปลี่ยนวิธีการทำ Refactorings มากกว่าวิธีที่คุณใช้ Git (แม้ว่าฉันคิดว่า Git สามารถช่วยคุณได้)

มาร์ตินฟาวเลอร์กำหนด refactoring เป็น :

เทคนิคที่มีระเบียบวินัยสำหรับการปรับโครงสร้างโค้ดที่มีอยู่เดิมปรับเปลี่ยนโครงสร้างภายในโดยไม่เปลี่ยนพฤติกรรมภายนอก

หัวใจของมันคือชุดของพฤติกรรมขนาดเล็กที่รักษาการเปลี่ยนแปลง การเปลี่ยนแปลงแต่ละครั้ง (เรียกว่า "การเปลี่ยนโครงสร้าง") ทำได้เพียงเล็กน้อย แต่ลำดับของการเปลี่ยนแปลงสามารถสร้างการปรับโครงสร้างที่สำคัญได้ เนื่องจากการปรับโครงสร้างแต่ละครั้งมีขนาดเล็กจึงมีโอกาสน้อยที่จะผิดพลาดได้ ระบบยังคงทำงานอย่างเต็มที่หลังจากการปรับโครงสร้างใหม่แต่ละครั้งลดโอกาสที่ระบบจะเสียหายอย่างรุนแรงระหว่างการปรับโครงสร้าง

หากคุณใช้วิธีนี้คุณสามารถยอมรับ (และดัน) เป็นประจำ

คุณอาจโต้แย้งว่าสิ่งนี้ไม่สามารถทำได้และมันไม่ได้ผลกับสิ่งที่มีขนาดใหญ่ นี่คือที่ที่วิธีการ Mikadoสามารถช่วยได้ คุณแยกย่อย refactoring ขนาดใหญ่เป็นชุดของ refactorings ขนาดเล็กโดยการสร้างกราฟอ้างอิง วิธีนี้เป็นแบบเรียกซ้ำพยายามทำให้การเปลี่ยนแปลงของคุณไม่ทำลายสิ่งใด ๆ ที่ตรวจสอบในมิฉะนั้นคืนการเปลี่ยนแปลงของคุณและจดบันทึกสิ่งที่ต้องมีก่อน คุณจะแก้ไข refactorings ที่จำเป็นก่อนนั้นจนกว่าคุณจะสามารถบรรลุเป้าหมายการสร้างใหม่ได้

Git สามารถช่วยวิธีนี้ได้จริงๆ คุณสามารถเก็บสาขาในประเทศของคุณ ในขณะที่คุณกระทำ (และผลักดัน) เป้าหมายย่อยคุณสามารถrebaseสาขาเป้าหมายหลักของคุณให้อยู่เหนือเป้าหมายที่คุณทำจนกว่าจะไม่แตกอีกต่อไป

ลองดูหน้าคู่มือgit rebaseโดยเฉพาะอย่างยิ่งgit rebase -iชุดตัวเลือก ช่วยให้คุณสามารถสั่งซื้อใหม่ลบหรือสควอชรวมถึงจำนวนของการกระทำใด ๆ ในประวัติศาสตร์ของคุณซึ่งดูเหมือนว่าสิ่งที่คุณกำลังมองหา ฉันใช้มันตลอดเวลาในสถานการณ์ที่คุณอธิบาย: การทำคอมมิชชันเล็ก ๆ จำนวนมากซึ่งไม่เหมาะสำหรับการบริโภคสาธารณะ

คุณกำลังใช้ Git จึงกระทำไม่จำเป็นต้องหมายถึงการผลักดันการเปลี่ยนแปลงของคุณ ....

IMHO และการทำงานกับ Git เป็นการดีอย่างยิ่งที่จะมอบงานของคุณแม้ว่าจะไม่ได้รวบรวม ... เพราะหลังจากทั้งหมดเมื่อคุณยอมรับการเปลี่ยนแปลงของคุณจะไม่มีใครสามารถใช้รหัสได้ (จนกว่าคุณจะผลักดัน) แน่นอนก่อนที่จะผลักดันคุณต้องให้แน่ใจว่ามันทำงานได้ดีและรวบรวมเพื่อให้ผู้อื่นสามารถดึงและผสานการเปลี่ยนแปลงของคุณได้โดยไม่มีปัญหาใด ๆ

นอกจากนี้คุณกำลังทำงานในสาขาที่แตกต่างจากหลัก ดังนั้นถ้าคุณต้องการ (และฉันแนะนำสิ่งนี้) คุณจะไม่ผลักสาขาของคุณเลย เมื่อคุณทำการปรับโครงสร้างเสร็จแล้วเพียงชำระเงินที่สาขาหลักรวมการเปลี่ยนแปลงของคุณแล้วกดสาขาหลัก

แก้ไข

ในกรณีนั้นคุณสามารถใช้git cherry-pickหรือเล่นกับgit rebase