git-deps เป็นเครื่องมือในการวิเคราะห์การพึ่งพาระหว่างการกระทำโดยอัตโนมัติระหว่างการกระทำในที่เก็บ GIT นี่คือการสาธิต screencast:

ฉันได้บล็อกเกี่ยวกับ git-deps และเครื่องมือที่เกี่ยวข้องและยังพูดคุยเกี่ยวกับเครื่องมือหลายครั้ง:
เป็นที่ชัดเจนว่า GIT สองตัวที่กระทำภายใน repo เดียวสามารถพิจารณาได้ว่า "เป็นอิสระ" จากกันและกันในแง่หนึ่งหากพวกเขาไม่เปลี่ยนไฟล์เดียวกันหรือหากพวกเขาไม่เปลี่ยนชิ้นส่วนที่ทับซ้อนกันของไฟล์เดียวกัน
ในทางตรงกันข้ามเมื่อการกระทำเปลี่ยนบรรทัดมันเป็น "ขึ้นอยู่กับ" ไม่เพียง แต่การกระทำที่เปลี่ยนบรรทัดสุดท้าย แต่ยังรวมถึงการกระทำใด ๆ ที่รับผิดชอบในการจัดหาเส้นโดยรอบของบริบทเพราะหากไม่มีสายรุ่นก่อนหน้าและบริบทของมัน ดังนั้นการพึ่งพาทั้งหมดของการกระทำสามารถอนุมานได้โดยการเขียนโปรแกรมโดยใช้ Git-blame บนบรรทัดการเปลี่ยนแปลงการกระทำรวมถึงอย่างไรก็ตามหลายบรรทัดของบริบททำให้รู้สึกถึงกรณีการใช้งานของการวิเคราะห์การพึ่งพานี้โดยเฉพาะ
ดังนั้นการคำนวณการพึ่งพาจะได้รับผลกระทบจากพารามิเตอร์ปัจจัย "ฟัซซัส" (CF Patch (1)) เช่นจำนวนเส้นของบริบทซึ่งถือว่าจำเป็นสำหรับความแตกต่างของการกระทำเพื่อนำไปใช้อย่างหมดจด
เช่นเดียวกับความสัมพันธ์การพึ่งพาจำนวนมากการพึ่งพาเหล่านี้จะสร้างขอบใน DAG โปรดทราบว่าโหนดสามารถขึ้นอยู่กับชุดย่อยของบรรพบุรุษของมันเท่านั้น
มันเป็นสิ่งสำคัญที่จะต้องทราบว่ากราฟการพึ่งพาใด ๆ ที่อนุมานโดย git-deps อาจไม่สมบูรณ์แบบความหมาย; ตัวอย่างเช่นมันจะไม่ตรวจจับการพึ่งพาการตรวจจับอัตโนมัติระหว่างการกระทำที่รหัสการเปลี่ยนแปลงและการกระทำอื่น B ซึ่งเปลี่ยนแปลงเอกสารหรือการทดสอบเพื่อสะท้อนการเปลี่ยนแปลงรหัสในการกระทำ A. ดังนั้นจึงไม่ควรใช้ git-deps ด้วยศรัทธาตาบอด สำหรับรายละเอียดเพิ่มเติมโปรดดูที่ส่วนเกี่ยวกับข้อความกับความหมาย (ใน) การพึ่งพาด้านล่าง
บางครั้งมันมีประโยชน์ที่จะเข้าใจลักษณะของส่วนต่าง ๆ ของกราฟการพึ่งพานี้เนื่องจากลักษณะของมันจะส่งผลกระทบต่อความสำเร็จหรือความล้มเหลวของการดำเนินงานรวมถึงการผสาน, การรีเบส, เชอร์รี่-เลือก ฯลฯ โปรดดูไฟล์ USE-CASES.md สำหรับรายละเอียดเพิ่มเติม
โปรดดูไฟล์ INSTALL.md
โปรดดูไฟล์ USAGE.md
ผู้อ่านที่ชาญฉลาดจะทราบว่าความเป็นอิสระของข้อความที่ตรวจพบโดย git-deps นั้นไม่เหมือนกับความเป็นอิสระทางความหมาย / ตรรกะ ความเป็นอิสระจากข้อความหมายถึงการเปลี่ยนแปลงสามารถนำไปใช้ในลำดับใด ๆ โดยไม่เกิดความขัดแย้ง แต่นี่ไม่ใช่ตัวบ่งชี้ที่เชื่อถือได้ของความเป็นอิสระเชิงตรรกะ
ตัวอย่างเช่นการเปลี่ยนแปลงฟังก์ชันและการเปลี่ยนแปลงที่สอดคล้องกันกับการทดสอบและ/หรือเอกสารประกอบสำหรับฟังก์ชั่นนั้นมักจะมีอยู่ในไฟล์ต่าง ๆ ดังนั้นหากการเปลี่ยนแปลงเหล่านั้นอยู่ในการกระทำที่แยกต่างหากภายในสาขาการรัน git-deps ในการกระทำจะไม่ตรวจจับการพึ่งพาระหว่างพวกเขาแม้ว่าพวกเขาจะเกี่ยวข้องอย่างมีเหตุผลเนื่องจากการเปลี่ยนแปลงในไฟล์ที่แตกต่างกัน (หรือแม้ในพื้นที่ต่าง ๆ ของไฟล์เดียวกัน) เป็นอิสระ
ดังนั้นในกรณีนี้ git-deps จะไม่ทำตัวเป็นวิธีที่เราต้องการ และตราบใดที่ AI เป็นปัญหาที่ยังไม่ได้แก้ไขมันก็ไม่น่าเป็นไปได้ที่มันจะพัฒนาพฤติกรรมที่เชื่อถือได้โดยสิ้นเชิง นั่นหมายความว่า git-deps นั้นไร้ประโยชน์หรือไม่? ไม่แน่นอน!
ประการแรกเมื่อแนวปฏิบัติที่ดีที่สุดสำหรับการจัดโครงสร้างนั้นได้รับการปฏิบัติตามการเปลี่ยนแปลงที่เกี่ยวข้องอย่างมีเหตุผลควรวางไว้ในการกระทำเดียวกันต่อไป ดังนั้นในตัวอย่างข้างต้นการเปลี่ยนฟังก์ชั่นและการเปลี่ยนแปลงที่สอดคล้องกันกับการทดสอบและ/หรือเอกสารประกอบสำหรับฟังก์ชั่นนั้นควรอยู่ในการประชุมครั้งเดียว (แม้ว่านี่จะไม่ใช่วิธีการที่ถูกต้องเพียงอย่างเดียว แต่สำหรับกลไกการจัดกลุ่มประวัติศาสตร์อภิมานขั้นสูงให้ดูที่ git-dendrify )
ประการที่สองในขณะที่ความเป็นอิสระของข้อความไม่ได้หมายความถึงความเป็นอิสระเชิงตรรกะการสนทนาที่คาดว่าจะเป็นจริงมากขึ้น: ความเป็นอิสระเชิงตรรกะมักหมายถึงความเป็นอิสระของข้อความ (หรือระบุอีกวิธีหนึ่งการพึ่งพาข้อความมักหมายถึงการพึ่งพาตรรกะ) ดังนั้นแม้ว่ามันอาจจะไม่ผิดปกติเกินไปที่ git-deps จะไม่ตรวจจับการพึ่งพาระหว่างการเปลี่ยนแปลงที่เกี่ยวข้องกับตรรกะ แต่ก็ควรหายากกว่าที่จะทำให้การพึ่งพาการพึ่งพาระหว่างการเปลี่ยนแปลงที่ไม่เกี่ยวข้องอย่างมีเหตุผล กล่าวอีกนัยหนึ่งโดยทั่วไปแล้วเชิงลบที่ผิดพลาดนั้นคาดว่าจะเป็นเรื่องธรรมดามากกว่าผลบวกที่ผิดพลาด เป็นผลให้มีแนวโน้มที่จะมีประโยชน์มากขึ้นในการกำหนดขอบเขตที่ต่ำกว่าของการพึ่งพามากกว่าขอบเขตบน ต้องบอกว่าจำเป็นต้องมีการวิจัยเพิ่มเติมเกี่ยวกับเรื่องนี้
ประการที่สามมันมักจะไม่ช่วยเหลือที่จะอนุญาตให้แสวงหาความสมบูรณ์แบบกลายเป็นศัตรูของดี - เครื่องมือไม่จำเป็นต้องสมบูรณ์แบบเพื่อเป็นประโยชน์ มันจะต้องดีกว่าการทำงานเดียวกันโดยไม่มีเครื่องมือ
การอภิปรายเพิ่มเติมเกี่ยวกับบางจุดเหล่านี้สามารถพบได้ในเธรดเก่าจากรายชื่อผู้รับจดหมาย Git
แม้ว่าในที่สุด "หลักฐานอยู่ในพุดดิ้ง" ดังนั้นลองดูดู!
โปรดดูไฟล์ CONTRIBUTING.md
โปรดดูไฟล์ HISTORY.md
ขอขอบคุณเป็นพิเศษสำหรับการสนับสนุนการพัฒนาซอฟต์แวร์นี้บางส่วน ขอขอบคุณทุกคนที่มีส่วนร่วมรหัสรายงานข้อผิดพลาดและข้อเสนอแนะอื่น ๆ
เปิดตัวภายใต้ GPL เวอร์ชัน 2 เพื่อให้สอดคล้องกับใบอนุญาตของ git แต่ฉันเปิดรับแนวคิดเรื่องการออกใบอนุญาตคู่หากมีเหตุผลที่น่าเชื่อถือ