เหตุใด git จึงใช้แฮชแทนหมายเลขการแก้ไข

ฉันสงสัยอยู่เสมอว่าทำไม git ชอบแฮชมากกว่าหมายเลขการแก้ไข หมายเลขการแก้ไขมีความชัดเจนและง่ายต่อการอ้างถึง (ในความคิดของฉัน): มีความแตกต่างระหว่างการบอกใครสักคนให้ดูการแก้ไข 1200 หรือกระทำ 92ba93e! (เพียงยกตัวอย่างหนึ่ง)

ดังนั้นมีเหตุผลสำหรับการออกแบบนี้หรือไม่?

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

คุณต้องการแฮ็ชในระบบกระจาย สมมติว่าคุณและเพื่อนร่วมงานกำลังทำงานในพื้นที่เก็บข้อมูลเดียวกันและคุณทั้งสองยอมรับการเปลี่ยนแปลงในพื้นที่แล้วผลักดันมัน ใครจะได้รับการแก้ไขหมายเลข 1200 และใครจะเป็นหมายเลขการแก้ไข 1201 เนื่องจากไม่มีฝ่ายใดมีความรู้เกี่ยวกับกันและกันบ้าง โซลูชันทางเทคนิคที่เหมือนจริงเพียงอย่างเดียวคือการสร้างแฮชของการเปลี่ยนแปลงโดยใช้วิธีการที่เป็นที่รู้จักและเชื่อมโยงสิ่งต่าง ๆ ตามนั้น

HG ที่น่าสนใจสนับสนุนหมายเลขรุ่น แต่เป็นคุณสมบัติเฉพาะที่อย่างชัดเจน - ที่เก็บของคุณมีหนึ่งชุด repo ของเพื่อนร่วมงานของคุณจะมีชุดที่แตกต่างกันขึ้นอยู่กับวิธีที่พวกเขาผลักและดึง มันทำให้การใช้บรรทัดคำสั่งเป็นมิตรมากกว่า Git เล็กน้อย

ความสมบูรณ์ของข้อมูล.

ฉันไม่เห็นด้วยกับคำตอบปัจจุบันอย่างเคารพ hashes ไม่จำเป็นสำหรับ DVCS ดูวิธีท์บาซาร์ คุณสามารถทำได้เช่นกันกับตัวระบุที่ไม่ซ้ำใครอื่น ๆ ทั่วโลก แฮชเป็นตัวชี้วัดที่รับประกันความถูกต้องของข้อมูล: มันเป็นตัวแทนของข้อมูลที่มีอยู่ในวัตถุ (กระทำ, ต้นไม้, ... ) ที่ถูกอ้างถึงโดยแฮช การดัดแปลงเนื้อหาโดยไม่ดัดแปลงแฮช (เช่นการโจมตีก่อนเกิดเหตุการณ์หรือการชนกันของข้อมูล ) เชื่อว่าเป็นเรื่องยากแม้ว่าจะเป็นไปไม่ได้ก็ตาม (ถ้าคุณเป็นจริงลงไปดูที่2011 กระดาษโดย Marc Stevens )

ดังนั้นการอ้างอิงถึงวัตถุโดยการแฮช SHA ของพวกเขาอนุญาตให้ตรวจสอบว่าเนื้อหาได้รับการดัดแปลง และเนื่องจากพวกเขา (เกือบ) รับประกันว่าจะไม่ซ้ำกันพวกเขาสามารถใช้เป็นตัวระบุการแก้ไขได้เช่นกัน

ดูบทที่ 9ของหนังสือ Git สำหรับรายละเอียดเพิ่มเติม

ในคำพูดของคนธรรมดา:

• แฮชมีจุดประสงค์เพื่อให้มีลักษณะเฉพาะที่เป็นสากลเกือบทั้งหมด ไม่รับประกัน แต่ไม่น่าเป็นไปได้อย่างยิ่งที่ SHA เดียวกันนั้นจะสร้างขึ้นสำหรับเนื้อหาที่แตกต่างกัน ในภาคปฏิบัติสำหรับโครงการที่กำหนดคุณสามารถถือว่าเป็นโครงการที่ไม่เหมือนใคร
• ด้วยหมายเลขการแก้ไขคุณจะต้องใช้เนมสเปซเพื่อให้การอ้างอิงซ้ำเป็นการแก้ไข 1200
• Git สามารถทำงานได้ทั้งแบบกระจายและ / หรือรวมศูนย์ ดังนั้นคุณจะได้รับหมายเลขการแก้ไขที่ถูกต้องและไม่ซ้ำกันได้อย่างไร
• การใช้หมายเลขการแก้ไขจะสร้างการแสดงผลที่ผิดพลาดซึ่งการแก้ไขที่ใหม่กว่าควรมีจำนวนที่สูงกว่าและนั่นจะไม่เป็นจริงเพราะการแยกการรวมการรวมการรีบูต ฯลฯ
• คุณมีตัวเลือกที่จะนำแท็กไปใช้ในการคอมมิท

ในแง่คณิตศาสตร์:

• จำเป็นต้องมีคำสั่งซื้อทั้งหมดที่เกินความมุ่งมั่นของ Git ในการเพิ่มหมายเลขรุ่นที่จำเจ
• Git ของกระทำในรูปแบบชี้นำวัฏจักรกราฟ (DAG)ที่สามารถสั่งซื้อบางส่วน / ทอพอโลยี

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

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