Git ถูกออกแบบมาอย่างไร?


9

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

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

ไม่มีข้อสงสัยในส่วนของพรสวรรค์ของไลนัส แต่ฉันสงสัยว่าการออกแบบโดยรวมของคอมไพล์อิงจากบางสิ่งหรือไม่? ฉันได้อ่านเกี่ยวกับ BitKeeper แล้ว แต่บัญชีก็ขาดแคลนรายละเอียดทางเทคนิค การบีบอัดกราฟการกำจัดหมายเลขการแก้ไขการเน้นการแยกการ stashing การควบคุมระยะไกล ... มันมาจากไหน?

ลีนุสเคาะมันออกจากสวนสาธารณะและลองครั้งแรกเลยทีเดียว! มันค่อนข้างดีที่จะใช้เมื่อคุณผ่านช่วงการเรียนรู้


คุณอาจจะได้รับความช่วยเหลือบางส่วนในช่องคอมไพล์ IRC (#git บนฟรีโนด)
Yati sagade


2
you get the feel that it can handle many obscure workflows that other version control systems could not: นั่นอาจเป็นเพราะมันถูกออกแบบมาเพื่อจัดการเคอร์เนล linux ซึ่งเป็นรหัสที่ฉาวโฉ่ใหญ่และซับซ้อน
yannis

1
ในวันครบรอบปีที่ 10 ของ Git ต่อไปนี้เป็นบทความจากการสัมภาษณ์ Torvalds: linux.com/news/featured-blogs/185-jennifer-cloer/ …
Sridhar Sarnobat

คำตอบ:


17

Git ไม่ได้ออกแบบมาให้มากที่สุดเท่าวิวัฒน์

ลองดูด้วยตัวเอง โคลนที่เก็บข้อมูล git อย่างเป็นทางการเปิดในgitk(หรือโปรแกรมดูบันทึกกราฟิก git ที่คุณชื่นชอบ) และดูการแก้ไขที่เก่าที่สุด

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

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


การบีบอัดกราฟการกำจัดหมายเลขการแก้ไขการเน้นการแยกการ stashing การควบคุมระยะไกล ... มันมาจากไหน?

หลายสิ่งนั้นไม่ได้อยู่ที่นั่นในตอนแรก

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

หากโดย "กราฟ" คุณหมายถึงผู้ดูกราฟิกชอบgitkพวกเขาจะปรากฏในภายหลัง (AFAIK ซึ่งเป็นคนแรกgitk) AFAIK, BitKeeper ยังมีโปรแกรมดูประวัติกราฟิก

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

การเน้นการแยกย่อยค่อนข้างหลีกเลี่ยงไม่ได้ในระบบการควบคุมเวอร์ชันที่กระจายเนื่องจากแต่ละโคลนนิ่งทำหน้าที่แยกสาขา

Stashing ( git stash) คือ IIRC ค่อนข้างเร็ว reflogs ที่มันใช้ไม่ได้อยู่ที่นั่นในตอนแรก

แม้แต่รีโมตไม่ได้อยู่ที่นั่นในตอนแรก rsyncแต่เดิมคุณคัดลอกวัตถุด้วยมือโดยใช้

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


"AFAIK, BitKeeper ยังมีโปรแกรมดูประวัติกราฟิก" ใช่. มันไม่ได้สวย แต่มันใช้งานได้ดีมาก ดูbitkeeper.com/Test.Using.Looking.htmlถึงแม้ว่ามันจะทำงานได้ไม่ดีในการแสดงวิธีที่จะแสดงสาขา
ไบรอัน Oakley

1
นอกจากนี้ยังมีการอ่านที่น่าสนใจไม่กี่อีเมลที่เลือกจากจุดเริ่มต้นของคอมไพล์แสดงให้เห็นบิตของการวิวัฒนาการเริ่มต้น: kerneltrap.org/node/4982
CesarB

โปรแกรมเมอร์ใช้เพื่อจำลองการทำงานของ git ด้วย cvs + rsync + httpd หรือไม่? ฉันสนใจที่จะรับฟังคำตอบในแบบโฮมเมดที่เป็นไปได้
Sridhar Sarnobat

8

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

ดังนั้นไลนัสรู้ถึงข้อกำหนดและการใช้เคสสำหรับระบบควบคุมเวอร์ชันแบบกระจายได้ดีกว่าคนอื่น และแน่นอนมันช่วยได้ว่าการเข้ารหัสส่วนใหญ่ที่เขาติดต่ออยู่ใน C และประสิทธิภาพนั้นสำคัญมาก

โดยทั่วไปมันเป็นตัวอย่างที่ดีที่สุดของการเกาคันของตัวเอง


6
"ผู้ที่ผ่านการคัดเลือกมากที่สุด"? ฉันไม่คิดอย่างนั้น มีคนฉลาดมากมายที่มีคุณสมบัติในการเขียนการควบคุมแหล่งที่มาแบบกระจาย พวกที่ BitMover (บริษัท ที่อยู่เบื้องหลัง BitKeeper) รู้จริง ๆว่าพวกเขากำลังทำอะไร Linus ให้เครดิตกับ Larry McVoy เพื่อแสดงให้เขาเห็นว่าการควบคุมซอร์สโค้ดควรจะทำงานอย่างไร หากปราศจากแลร์รี่จะไม่มีคอมไพล์
Bryan Oakley

1
@BryanOakley ฉันคิดว่าเราสามารถหลีกเลี่ยงการทุบตีได้เมื่อมีใครบางคนช่วยเสริมบางสิ่งที่ดี ทุกคนในระดับสูงรู้ว่าความต้องการนี้ทำให้นักพัฒนาซอฟต์แวร์ยอดเยี่ยม ดังนั้นถ้าพรุ่งนี้คุณจะพบกับปัญหาที่ยิ่งใหญ่เราอาจจำคุณได้เช่นเดียวกับที่เราทำกับ Dennis Ritchie ไม่มีใครดีไปกว่าคนอื่น ๆ มันแค่ว่าพวกเขาเจอข้อกำหนดทั่วโลกที่ได้รับการยอมรับและจัดหาวิธีแก้ปัญหาก่อน
Pankaj Upadhyay

2
@Bryan: ฉันแน่ใจว่าประสบการณ์การใช้ BitKeeper สอนให้ Linus เป็นอย่างดีและฉันควรจะพูดถึงเรื่องนี้ และแน่นอนว่ายังมีคนที่เก่งและมีคุณสมบัติอื่น ๆ อีกมากมายที่รู้ว่าพวกเขากำลังทำอะไรอยู่ แต่ฉันยังคงยืนยันว่าประสบการณ์ของ Linus ในการบำรุงรักษาเคอร์เนลทำให้เขามีคุณสมบัติเหมาะสมที่สุดและมีประสบการณ์ ฉันอาจจะผิด แต่คุณสามารถชี้ให้เห็นโครงการใหญ่ที่มีผู้ร่วมให้ข้อมูลจำนวนมากและผู้ที่รับผิดชอบมันยังคงมีส่วนร่วมอย่างลึกซึ้งในการรับรหัสที่แท้จริงของผู้ร่วมให้ข้อมูลเหล่านั้นเพื่อทำงานร่วมกันหรือไม่
Michael Borgwardt

@Pankaj Upadhyay: ฉันไม่ได้ทุบตีใครเลยฉันแค่อธิบายว่าทำไมฉันถึงลงคำตอบ คุณพูดอะไรบางอย่างเกี่ยวกับ "ให้วิธีแก้ปัญหาก่อน" ซึ่งฉันคิดว่าคุณคิดว่า git นั้น "เป็นครั้งแรก" ในบางเรื่อง คุณคิดว่ามันเป็นครั้งแรกที่? แน่นอนว่าไม่ใช่เครื่องมือ SCM แบบกระจายครั้งแรกโดยการยิงระยะไกล
ไบรอัน Oakley

1
@DeadMG: ส่วนที่สำคัญกว่าของคำสั่งนั้นเกิดขึ้นหลังจากนั้น "... และส่วนใหญ่ของคำวิจารณ์นั้น" ฉันสงสัยว่าคุณจะพบว่ามีหลายคนที่โต้แย้งว่า C ไม่เหมาะที่จะใช้รหัสประสิทธิภาพสูงต่ำหากคุณรู้ดี
Michael Borgwardt

6

มันถูกออกแบบมาสวยมากตรงตามที่อธิบายไว้ในGit อุปมา

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.