คอมไพล์“ Golden Rule of Rebasing” จำเป็นอย่างยิ่งหรือไม่?

ฉันมีการสนทนาเมื่อเร็ว ๆ นี้กับผู้คนที่ต่อต้านกลยุทธ์การปฏิเสธของฟีเจอร์บั๊กใน GIT ดูเหมือนว่าจะเป็นรูปแบบที่ได้รับการยอมรับให้ใช้ rebase เฉพาะสำหรับสาขาในพื้นที่ของเอกชน แต่ไม่เคยใช้เมื่อมีหลายคนทำงานในฟีเจอร์และสาขาเดียวกันตามที่เรียกว่า "Golden Rule of Rebasing" (เช่นอธิบายที่นี่: https : //www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview )

ฉันแค่แปลกใจที่มีมติในเรื่องนี้ ฉันทำงานเป็นเวลา 3 ปีด้วยกลยุทธ์การรีบูทเต็มรูปแบบโดยมีนักพัฒนาซอฟต์แวร์ประมาณ 20 คนที่ทำงานเพื่อหาและคาดเดาว่ามันทำงานได้อย่างไร

กระบวนการนั้นเป็นพื้น:

• คุณสร้างสาขาฟีเจอร์ของคุณเรียกมันว่า "myfeature" และผลักมันไปที่ต้นกำเนิด / myfeature
• คนอื่นอาจตรวจสอบและทำงานกับมัน
• บางครั้งคุณอาจทำการรีบูตจากต้นแบบ: จาก "myfeature", ต้นกำเนิด git rebase / master ; จากนั้นใช่คุณต้องผลักดันมัน
• เกิดอะไรขึ้นเมื่อคนอื่น ๆ ต้องการที่จะผลักดันการกระทำของพวกเขา? พวกเขาเพียงแค่ rebase มัน: คอมไพล์ rebase ต้นกำเนิด / คุณสมบัติของฉัน ดังนั้นตอนนี้พวกเขาอยู่ข้างหน้าอย่างรวดเร็วและสามารถผลักดันมันโดยไม่บังคับ

หลักการเดียวที่จะเคารพคือสาขาคุณลักษณะเป็นเจ้าของโดยใครบางคน เจ้าของเป็นคนเดียวที่สามารถผลักดัน

ดังนั้นฉันยอมรับ: ทันทีที่มีแรงผลักดันมีความเสี่ยงที่จะทำผิดพลาด นั่นเป็นเรื่องจริง แต่ก็มีหลายวิธีในการกู้คืนจากข้อผิดพลาดและจริงๆแล้วในการพัฒนา 3 ปีฉันไม่เห็นข้อผิดพลาดที่เกิดขึ้นมากมายและเมื่อมันเกิดขึ้นเราพบวิธีการกู้คืนอย่างถูกต้องเสมอ

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

ปัญหาเกี่ยวกับการบังคับใช้ไม่ได้เกี่ยวกับสาขาคุณลักษณะและหลักของคุณ แต่เกี่ยวกับการผลักดันต้นแบบของคุณไปยังต้นแบบของบุคคลอื่น - การซิงโครไนซ์นั้นจะเป็นการเขียนทับต้นแบบของพวกเขาด้วยการเปลี่ยนแปลงของคุณ

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

ดังนั้นคำถามอาจเป็นเพราะเหตุใดคุณจึงปรับใหม่ทั้งหมด? สำหรับประวัติ 'สะอาด' เมื่อนำคุณสมบัติกลับมาเป็นหลัก ถ้าเป็นเช่นนั้นคุณกำลังละทิ้งประวัติศาสตร์ที่ดีทั้งหมดเกี่ยวกับการแตกแขนงด้วยเหตุผลทางสไตล์ล้วนๆ การผสานการส่งต่อที่รวดเร็วของ IMHO นั้นก็ไม่ใช่วิธีปฏิบัติที่ดีที่สุดเช่นกันคุณควรจะเก็บประวัติทั้งหมดไว้เพื่อที่คุณจะได้เห็นสิ่งที่คุณทำจริงๆไม่ใช่เวอร์ชันที่ถูกสุขลักษณะในภายหลัง

การปฏิเสธไม่จำเป็นอย่างที่คุณบอกว่ามันเป็นเครื่องสำอางส่วนใหญ่ บางครั้งมันง่ายกว่ามากที่จะรวมกัน ดังนั้นจึงสามารถมีค่า "จริง" แต่บางครั้ง "บางครั้ง"

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

ด้วยการแลกเปลี่ยนผลจาก "น้อยคนนักที่จะลดและผลักดัน" ไม่น่าแปลกใจนัก

เวิร์กโฟลว์บางตัวสามารถลดความเสี่ยงได้เช่นลดเป็น "ศูนย์ตราบใดที่คุณจำได้ว่าสาขาใดที่คุณได้รับอนุญาตให้บังคับและไม่สามารถทำได้" ในความเป็นจริงพวกเขาอาจปลอดภัยพอที่จะพิสูจน์ความเสี่ยง แต่ผู้คนมักเลือกตัวเลือกตามคติชนที่ใหญ่กว่า จากนั้นในความเป็นจริงอีกครั้งประโยชน์มีขนาดเล็กดังนั้นความเสี่ยงไม่จำเป็นต้องมีขนาดเล็กจริง ๆ ?

วิธีเพิ่มเสียงอื่น:

ใช่ถ้าคุณทำงานตามที่อธิบายไว้ไม่มีปัญหากับการใช้rebaseและการบังคับให้กด จุดสำคัญคือ: คุณมีข้อตกลงในทีมของคุณ

คำเตือนเกี่ยวกับrebaseและเพื่อนมีไว้สำหรับกรณีที่ไม่มีข้อตกลงพิเศษ โดยปกติแล้วคอมไพล์จะปกป้องคุณโดยอัตโนมัติโดยยกตัวอย่างเช่นไม่อนุญาตให้มีการส่งต่อแบบเร็ว การใช้rebaseและการบังคับให้แทนที่ความปลอดภัยนั้น ไม่เป็นไรถ้าคุณมีอย่างอื่นในสถานที่

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

โปรดทราบว่าโครงการ git เองก็ทำสิ่งที่คล้ายกัน: พวกเขามีสาขาการรวมที่สร้างขึ้นใหม่เป็นประจำเรียกว่า "pu" ("การปรับปรุงที่เสนอ") มีการบันทึกไว้ว่ามีการสร้างสาขาใหม่เป็นประจำและคุณไม่ควรสร้างงานใหม่

ดังนั้นฉันยอมรับ: ทันทีที่มีแรงผลักดันมีความเสี่ยงที่จะทำผิดพลาด นั่นเป็นเรื่องจริง แต่ก็มีหลายวิธีในการกู้คืนจากข้อผิดพลาดและจริงๆแล้วในการพัฒนา 3 ปีฉันไม่เห็นข้อผิดพลาดที่เกิดขึ้นมากมายและเมื่อมันเกิดขึ้นเราพบวิธีการกู้คืนอย่างถูกต้องเสมอ

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

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

เปรียบเทียบสิ่งนี้กับงานวิวัฒนาการ Changesetของ Mercurial (ซึ่งฉันควรทราบว่ายังไม่เสร็จหรือเสถียร) ทุกคนสามารถทำการเปลี่ยนแปลงอะไรก็ได้ในประวัติศาสตร์ที่พวกเขาชอบหากเซ็ตการแก้ไขไม่ได้ถูกทำเครื่องหมายเป็นสาธารณะ การแก้ไขและการคืนเงินเหล่านี้สามารถผลักดันและดึงได้โดยไม่ต้องรับโทษรวมไม่ต้องมีเจ้าของสาขา ไม่มีการลบข้อมูล พื้นที่เก็บข้อมูลท้องถิ่นทั้งหมดเป็นแบบผนวกเท่านั้น การเปลี่ยนแปลงที่ไม่ต้องการอีกต่อไปจะถูกทำเครื่องหมายว่าล้าสมัย แต่จะถูกเก็บไว้เรื่อย ๆ ในที่สุดเมื่อคุณทำให้ประวัติของคุณยุ่งเหยิง (ซึ่งถือว่าเป็นส่วนหนึ่งของกระบวนการทำงานในชีวิตประจำวันของคุณ) มีคำสั่งที่ดีที่จะทำความสะอาดให้คุณโดยอัตโนมัติ นี่คือประเภทของ UX ที่ผู้คนคาดหวังก่อนที่พวกเขาจะแก้ไขประวัติการแชร์