Torvalds พูดติดตลกเกี่ยวกับชื่อgit (ซึ่งเป็น คำแสลง ภาษาอังกฤษแบบบริติชที่หมายถึงคนที่ไม่น่าคบหาหรือโง่เขลา): "ผมเป็นไอ้สารเลวที่เห็นแก่ตัว และผมตั้งชื่อโปรเจกต์ทั้งหมดตามชื่อตัวเอง ก่อนหน้านี้ ' Linux ' ตอนนี้ 'git'" ^{[ 33 ] [ 34 ]}หน้าคู่มืออธิบาย Git ว่าเป็น "ตัวติดตามเนื้อหาที่โง่เขลา" ^{[ 35 ]}

ไฟล์readmeของซอร์สโค้ดอธิบายเพิ่มเติมดังนี้: ^{[ 36 ]}

คำว่า "git" สามารถหมายถึงอะไรก็ได้ ขึ้นอยู่กับอารมณ์ของคุณ

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

ซอร์สโค้ดของ Git อ้างถึงโปรแกรมว่าเป็น "ตัวจัดการข้อมูลจากนรก" ^{[ 37 ] [ 38 ]}

การออกแบบของ Git เป็นการสังเคราะห์ประสบการณ์ของ Torvalds กับ Linux ในการบำรุงรักษาโครงการพัฒนาแบบกระจายขนาดใหญ่ พร้อมกับความรู้เชิงลึกเกี่ยวกับประสิทธิภาพของระบบไฟล์ที่ได้รับจากโครงการเดียวกัน และความจำเป็นเร่งด่วนในการสร้างระบบที่ใช้งานได้ในเวลาอันสั้น อิทธิพลเหล่านี้ทำให้เกิดทางเลือกในการใช้งานดังต่อไปนี้: ^{[ 10 ]}

การสนับสนุนอย่างแข็งขันต่อการพัฒนาที่ไม่เป็นเชิงเส้น

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

การพัฒนาแบบกระจาย

เช่นเดียวกับDarcs , BitKeeper , Mercurial , BazaarและMonotone Git มอบสำเนาประวัติการพัฒนาทั้งหมดให้กับนักพัฒนาแต่ละคน และการเปลี่ยนแปลงจะถูกคัดลอกจากที่เก็บข้อมูลดังกล่าวหนึ่งไปยังอีกที่เก็บข้อมูลหนึ่ง การเปลี่ยนแปลงเหล่านี้จะถูกนำเข้าเป็นสาขาการพัฒนาที่เพิ่มเข้ามา และสามารถผสานรวมได้ในลักษณะเดียวกับสาขาที่พัฒนาในพื้นที่^{[ 39 ]}

ความเข้ากันได้กับระบบและโปรโตคอลที่มีอยู่

สามารถเผยแพร่ที่เก็บข้อมูลผ่านHypertext Transfer Protocol Secure (HTTPS), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP) หรือโปรโตคอล Git ผ่านซ็อกเก็ตธรรมดาหรือSecure Shell (ssh) Git ยังมีการจำลองเซิร์ฟเวอร์ CVS ซึ่งช่วยให้สามารถใช้ไคลเอ็นต์ CVS และปลั๊กอิน IDE ที่มีอยู่เพื่อเข้าถึงที่เก็บข้อมูล Git ได้ ที่เก็บข้อมูล Subversionสามารถใช้งานได้โดยตรงกับ git-svn ^{[ 40 ]}

การจัดการโครงการขนาดใหญ่อย่างมีประสิทธิภาพ

Torvalds ได้อธิบายว่า Git นั้นเร็วและปรับขนาดได้ดีมาก^{[ 41 ]}และการทดสอบประสิทธิภาพที่ดำเนินการโดย Mozilla ^{[ 42 ]}แสดงให้เห็นว่าการเปรียบเทียบความแตกต่างของคลังข้อมูลขนาดใหญ่เร็วกว่าMercurialและGNU Bazaar ถึงหนึ่ง ลำดับขนาด การดึงประวัติเวอร์ชันจากคลังข้อมูลที่จัดเก็บไว้ในเครื่องอาจเร็วกว่าการดึงจากเซิร์ฟเวอร์ระยะไกลถึงหนึ่งร้อยเท่า^{[ 43 ]}

การตรวจสอบความถูกต้องทางการเข้ารหัสของประวัติศาสตร์

ประวัติ Git ถูกจัดเก็บในลักษณะที่ ID ของเวอร์ชันเฉพาะ (หรือcommitในแง่ของ Git) ขึ้นอยู่กับประวัติการพัฒนาทั้งหมดก่อนหน้า commit นั้น เมื่อเผยแพร่แล้ว จะไม่สามารถเปลี่ยนแปลงเวอร์ชันเก่าได้โดยไม่ถูกตรวจพบ โครงสร้างคล้ายกับMerkle treeแต่มีข้อมูลเพิ่มเติมที่โหนดและใบ^{[ 44 ]} ( MercurialและMonotoneก็มีคุณสมบัตินี้เช่นกัน)

การออกแบบโดยใช้ชุดเครื่องมือ

Git ได้รับการออกแบบให้เป็นชุดโปรแกรมที่เขียนด้วยภาษาCและสคริปต์เชลล์หลายตัวที่ให้ตัวห่อหุ้มรอบโปรแกรมเหล่านั้น^{[ 45 ]}แม้ว่าสคริปต์ส่วนใหญ่จะถูกเขียนใหม่ด้วยภาษา C เพื่อความเร็วและความสามารถในการพกพา แต่การออกแบบยังคงอยู่ และสามารถเชื่อมโยงส่วนประกอบต่างๆ เข้าด้วยกันได้อย่างง่ายดาย^{[ 46 ]}

กลยุทธ์การผสานแบบเสียบปลั๊กได้

ในส่วนของการออกแบบชุดเครื่องมือ Git มีโมเดลการรวมที่ไม่สมบูรณ์ที่กำหนดไว้อย่างชัดเจน และมีอัลกอริทึมหลายตัวสำหรับทำให้การรวมเสร็จสมบูรณ์ โดยท้ายที่สุดจะแจ้งให้ผู้ใช้ทราบว่าไม่สามารถทำการรวมให้เสร็จสมบูรณ์โดยอัตโนมัติได้ และจำเป็นต้องแก้ไขด้วยตนเอง^{[ 47 ]}

ขยะจะสะสมไปเรื่อยๆ จนกว่าจะมีคนมาเก็บ

การยกเลิกการดำเนินการหรือการย้อนกลับการเปลี่ยนแปลงจะทำให้วัตถุที่ค้างอยู่ซึ่งไม่มีประโยชน์เหลืออยู่ในฐานข้อมูล โดยทั่วไปแล้ววัตถุเหล่านี้จะเป็นเพียงส่วนน้อยของประวัติวัตถุที่ต้องการซึ่งเติบโตอย่างต่อเนื่อง Git จะทำการเก็บขยะ โดยอัตโนมัติ เมื่อมีการสร้างวัตถุที่หลวมจำนวนมากพอในที่เก็บข้อมูล การเก็บขยะสามารถเรียกได้อย่างชัดเจนโดยใช้git gc. ^{[ 48 ] [ 49 ]}

การจัดเรียงวัตถุแบบชัดเจนเป็นระยะ

Git จัดเก็บอ็อบเจ็กต์ที่สร้างขึ้นใหม่แต่ละรายการเป็นไฟล์แยกกัน แม้ว่าจะมีการบีบอัดทีละรายการ แต่ก็ใช้พื้นที่มากและไม่มีประสิทธิภาพ วิธีแก้ปัญหานี้คือการใช้แพ็คซึ่งจัดเก็บอ็อบเจ็กต์จำนวนมากที่บีบอัดแบบเดลต้าไว้ในไฟล์เดียว (หรือสตรีมไบต์เครือข่าย) ที่เรียกว่าไฟล์แพ็คแพ็คจะถูกบีบอัดโดยใช้หลักการที่ว่าไฟล์ที่มีชื่อเดียวกันน่าจะคล้ายกัน โดยไม่ขึ้นอยู่กับความถูกต้อง ไฟล์ดัชนีที่สอดคล้องกันจะถูกสร้างขึ้นสำหรับแต่ละไฟล์แพ็ค โดยบันทึกออฟเซ็ตของแต่ละอ็อบเจ็กต์ในไฟล์แพ็ค อ็อบเจ็กต์ที่สร้างขึ้นใหม่ (พร้อมประวัติที่เพิ่มเข้ามาใหม่) ยังคงถูกจัดเก็บเป็นอ็อบเจ็กต์เดี่ยว และจำเป็นต้องมีการแพ็คใหม่เป็นระยะเพื่อรักษาประสิทธิภาพการใช้พื้นที่ กระบวนการแพ็คที่เก็บข้อมูลอาจมีค่าใช้จ่ายในการคำนวณสูงมาก โดยการอนุญาตให้อ็อบเจ็กต์มีอยู่ในที่เก็บข้อมูลในรูปแบบที่หลวมแต่สร้างขึ้นอย่างรวดเร็ว Git ช่วยให้สามารถเลื่อนการดำเนินการแพ็คที่มีค่าใช้จ่ายสูงไปในภายหลัง เมื่อเวลามีความสำคัญน้อยลง เช่น สิ้นสุดวันทำงาน Git จะทำการแพ็คใหม่เป็นระยะโดยอัตโนมัติ แต่ก็สามารถแพ็คใหม่ด้วยตนเองได้ด้วยgit gcคำสั่ง^{[ 50 ]}เพื่อความสมบูรณ์ของข้อมูล ทั้งไฟล์แพ็คและดัชนีจะมีค่าตรวจสอบSHA-1 ^{[ 51 ]}อยู่ภายใน และชื่อไฟล์ของไฟล์แพ็คยังมีค่าตรวจสอบ SHA-1 ด้วย หากต้องการตรวจสอบความสมบูรณ์ของที่เก็บข้อมูล ให้รันgit fsckคำสั่ง^{[ 52 ] [ 53 ]}

คุณสมบัติอีกประการหนึ่งของ Git คือการสร้างสแนปช็อตของโครงสร้างไดเร็กทอรีของไฟล์ ระบบแรกสุดสำหรับการติดตามเวอร์ชันของซอร์สโค้ด ได้แก่ระบบควบคุมซอร์สโค้ด (SCCS) และระบบควบคุมการแก้ไข (RCS) ทำงานกับไฟล์แต่ละไฟล์และเน้นการประหยัดพื้นที่ที่ได้จากเดลต้าแบบสลับ (SCCS) หรือการเข้ารหัสเดลต้า (RCS) ของเวอร์ชัน (ส่วนใหญ่คล้ายกัน) ระบบควบคุมการแก้ไขในภายหลังยังคงรักษาแนวคิดที่ว่าไฟล์มีเอกลักษณ์เดียวกันในหลายเวอร์ชันของโครงการ อย่างไรก็ตาม Torvalds ปฏิเสธแนวคิดนี้^{[ 54 ]}ด้วยเหตุนี้ Git จึงไม่ได้บันทึกความสัมพันธ์การแก้ไขไฟล์อย่างชัดเจนในระดับใด ๆ ที่ต่ำกว่าโครงสร้างซอร์สโค้ด

Git ใช้กลยุทธ์การรวมหลายแบบ สามารถเลือกกลยุทธ์ที่ไม่ใช่ค่าเริ่มต้นได้ในเวลารวม: ^{[ 60 ]}

• resolve : อัลกอริทึมการรวมแบบสามทาง แบบดั้งเดิม
• แบบเรียกซ้ำ (Recursive ): นี่คือค่าเริ่มต้นเมื่อดึงหรือผสานสาขาเดียว และเป็นรูปแบบหนึ่งของอัลกอริธึมการผสานแบบสามทาง (three-way merge algorithm)

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

  — ลินัส ทอร์วัลด์ส^{[ 61 ]}

• ปลาหมึกยักษ์ : นี่คือค่าเริ่มต้นเมื่อรวมหัวมากกว่าสองหัว

ฟังก์ชันพื้นฐานของ Git ไม่ใช่ ระบบ จัดการซอร์สโค้ด โดยเนื้อแท้ Torvalds อธิบายว่า: ^{[ 62 ]}

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

จากแนวทางการออกแบบเบื้องต้นนี้ Git ได้พัฒนาฟีเจอร์ครบชุดตามที่คาดหวังจาก SCM แบบดั้งเดิม^{[ 63 ]}โดยฟีเจอร์ส่วนใหญ่จะถูกสร้างขึ้นตามความจำเป็น จากนั้นจึงปรับปรุงและขยายเพิ่มเติมเมื่อเวลาผ่านไป

Git มีโครงสร้างข้อมูล สองแบบ : ดัชนี ที่เปลี่ยนแปลงได้ (เรียกอีกอย่างว่าstageหรือcache ) ที่แคชข้อมูลเกี่ยวกับไดเร็กทอรีการทำงานและการแก้ไขครั้งถัดไปที่จะทำการคอมมิต และฐานข้อมูลวัตถุที่จัดเก็บวัตถุที่ไม่สามารถเปลี่ยนแปลงได้^{[ 64 ]}

ดัชนีทำหน้าที่เป็นจุดเชื่อมต่อระหว่างฐานข้อมูลวัตถุและโครงสร้างการทำงาน^{[ 64 ]}

ที่เก็บวัตถุประกอบด้วยวัตถุห้าประเภท: ^{[ 65 ] [ 52 ]}

• บล็อบคือเนื้อหาของไฟล์บล็อบไม่มีชื่อไฟล์ที่ถูกต้อง การประทับเวลา หรือเมตาเดตาอื่น ๆ (ชื่อบล็อบภายในคือแฮชของเนื้อหา) ใน Git แต่ละบล็อบเป็นเวอร์ชันของไฟล์ ซึ่งมีข้อมูลของไฟล์อยู่^{[ 66 ]}
• อ็อบเจ็กต์ต้นไม้เทียบเท่ากับไดเร็กทอรี ประกอบด้วยรายการชื่อไฟล์^{[ 67 ]}แต่ละไฟล์มีบิตประเภทบางส่วนและการอ้างอิงถึงบล็อบหรืออ็อบเจ็กต์ต้นไม้ที่เป็นไฟล์ ลิงก์สัญลักษณ์ หรือเนื้อหาของไดเร็กทอรีนั้น อ็อบเจ็กต์เหล่านี้เป็นภาพรวมของต้นไม้ต้นทาง (โดยรวมแล้ว ประกอบด้วยต้นไม้ Merkleซึ่งหมายความว่าแฮชเดียวสำหรับต้นไม้รากก็เพียงพอและถูกใช้จริงในการคอมมิตเพื่อระบุสถานะที่แน่นอนของโครงสร้างต้นไม้ทั้งหมดของไดเร็กทอรีย่อยและไฟล์จำนวนใดก็ได้)
• อ อบเจ็กต์ คอมมิตเชื่อมโยงออบเจ็กต์ต้นไม้เข้าด้วยกันในประวัติ ประกอบด้วยชื่อของออบเจ็กต์ต้นไม้ (ของไดเร็กทอรีแหล่งที่มาระดับบนสุด) การประทับเวลา ข้อความบันทึก และชื่อของออบเจ็กต์คอมมิตแม่ศูนย์ตัวขึ้นไป^{[ 68 ]}
• อ็อบเจ็กต์แท็กเป็นคอนเทนเนอร์ที่ประกอบด้วยการอ้างอิงถึงอ็อบเจ็กต์อื่น และสามารถเก็บข้อมูลเมตาเพิ่มเติมที่เกี่ยวข้องกับอ็อบเจ็กต์อื่นได้ โดยทั่วไปแล้ว จะใช้เพื่อจัดเก็บลายเซ็นดิจิทัลของอ็อบเจ็กต์คอมมิตที่สอดคล้องกับการเผยแพร่ข้อมูลเฉพาะที่กำลังติดตามโดย Git ^{[ 69 ]}
• อ็อบเจ็กต์packfileจะรวบรวมอ็อบเจ็กต์อื่นๆ ต่างๆ เข้าไว้ใน บันเดิลที่บีบอัดด้วย zlibเพื่อความกะทัดรัดและง่ายต่อการขนส่งผ่านโปรโตคอลเครือข่าย^{[ 70 ]}

แต่ละอ็อบเจ็กต์จะถูกระบุด้วย ค่าแฮช SHA-1 ของเนื้อหาภายใน Git จะคำนวณค่าแฮชและใช้ค่านี้เป็นชื่อของอ็อบเจ็กต์ อ็อบเจ็กต์จะถูกจัดเก็บไว้ในไดเร็กทอรีที่ตรงกับอักขระสองตัวแรกของค่าแฮช ส่วนที่เหลือของค่าแฮชจะถูกใช้เป็นชื่อไฟล์สำหรับอ็อบเจ็กต์นั้น

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

นอกจากนี้ Git ยังจัดเก็บป้ายกำกับที่เรียกว่า refs (ย่อมาจาก references) เพื่อระบุตำแหน่งของ commit ต่างๆ โดยจะถูกจัดเก็บไว้ในฐานข้อมูลอ้างอิงและมีดังนี้: ^{[ 71 ]}

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

คำสั่งที่ใช้บ่อยสำหรับอินเทอร์เฟซบรรทัดคำสั่ง ของ Git ได้แก่: ^{[ 72 ] [ 73 ]}

• git initซึ่งใช้ในการสร้างที่เก็บข้อมูล Git
• git clone [URL]ซึ่งเป็นการโคลนหรือทำสำเนาที่เก็บข้อมูล Git จาก URL ภายนอก
• git add [file]ซึ่งเป็นการเพิ่มไฟล์เข้าไปในไดเร็กทอรีการทำงาน ของ Git (ไฟล์ที่จะถูกคอมมิต)
• git commit -m [commit message]ซึ่งจะบันทึกไฟล์จากไดเร็กทอรีการทำงานปัจจุบัน (ดังนั้นไฟล์เหล่านั้นจึงเป็นส่วนหนึ่งของประวัติของที่เก็บข้อมูล)

สามารถสร้างไฟล์ .gitignore ในที่เก็บ Git เป็นไฟล์ข้อความธรรมดาได้ไฟล์ที่ระบุไว้ในไฟล์ . gitignoreจะไม่ถูกติดตามโดย Git ^{[ 74 ] : 3–4}คุณสมบัตินี้สามารถใช้เพื่อละเว้นไฟล์ที่มีคีย์หรือรหัสผ่าน ไฟล์แปลกปลอมต่างๆ และไฟล์ขนาดใหญ่ (ซึ่งGitHubจะปฏิเสธการอัปโหลด) ^{[ 75 ]}

วัตถุทุกชิ้นในฐานข้อมูล Git ที่ไม่ได้ถูกอ้างอิงถึง สามารถถูกล้างข้อมูลได้โดยใช้คำสั่งเก็บกวาดขยะ หรือโดยอัตโนมัติ วัตถุหนึ่งอาจถูกอ้างอิงโดยวัตถุอื่น หรือโดยการอ้างอิงแบบชัดเจน Git มีการอ้างอิงหลายประเภท คำสั่งในการสร้าง ย้าย และลบการอ้างอิงนั้นแตกต่างกันไปgit show-refรายการการอ้างอิงทั้งหมดมีดังนี้:

• heads : หมายถึงวัตถุภายในเครื่อง
• remotes : หมายถึงวัตถุที่อยู่ในที่เก็บข้อมูลระยะไกล (remote repository)
• stash : หมายถึงวัตถุที่ยังไม่ได้บันทึก (commit)
• เมตา : เช่น การกำหนด ^ค่าในที่เก็บข้อมูลเปล่า สิทธิ์ของผู้ใช้ เนมสเปซ refs/meta/config ได้รับการแนะนำในภายหลัง และถูกใช้โดยGerrit [ ^{76 ]}
• แท็ก : ดูด้านบน

• การโฮสต์เซิร์ฟเวอร์ Git โดยใช้ไบนารี Git ^{[ 100 ]}
• Gerritคือเซิร์ฟเวอร์ Git ที่สามารถกำหนดค่าเพื่อรองรับการตรวจสอบโค้ดและให้การเข้าถึงผ่าน SSH, Apache MINAหรือ OpenSSH ที่ผสานรวม หรือ เว็บเซิร์ฟเวอร์ Jetty ที่ผสานรวม Gerrit รองรับการผสานรวม LDAP, Active Directory, OpenID, OAuth, Kerberos/GSSAPI และใบรับรองไคลเอ็นต์ X509 https ใน Gerrit 3.0 การกำหนดค่าทั้งหมดจะถูกจัดเก็บเป็นที่เก็บ Git และไม่จำเป็นต้องใช้ฐานข้อมูลในการทำงาน Gerrit มีฟีเจอร์ pull-request ที่ถูกนำมาใช้ในส่วนหลัก แต่ขาด GUI สำหรับฟีเจอร์นี้
• Phabricatorเป็นบริษัทที่แยกตัวออกมาจาก Facebook เนื่องจาก Facebook ใช้Mercurial เป็นหลัก การสนับสนุน Git จึงไม่โดดเด่นนัก^{[ 101 ]}
• RhodeCode Community Edition (CE) รองรับ Git, MercurialและSubversionภายใต้ใบอนุญาต AGPLv3
• Kallitheaรองรับทั้ง Git และMercurialพัฒนาด้วยภาษาPython ภาย ใต้ใบอนุญาต GPL
• โครงการภายนอกเช่น gitolite ^{[ 102 ]}ซึ่งจัดเตรียมสคริปต์บนซอฟต์แวร์ Git เพื่อให้การควบคุมการเข้าถึงแบบละเอียด
• มีโซลูชัน FLOSS อื่นๆ อีกหลายอย่างสำหรับการโฮสต์ด้วยตนเอง รวมถึง Gogs ^{[ 103 ]} Giteaซึ่งเป็นเวอร์ชันแยกของ Gogs และForgejoซึ่งเป็นเวอร์ชันแยกของ Gitea อีกด้วย Gogs รวมถึงเวอร์ชันแยกอีกสองเวอร์ชันที่กล่าวถึงข้างต้น ได้รับการพัฒนาโดยใช้ภาษา Goโซลูชันทั้งสามนี้ให้บริการภายใต้ใบอนุญาต MIT

มีบริการ Git repositories มากมายให้เลือกใช้ บริการที่ได้รับความนิยมมากที่สุด^{ได้แก่} GitHub , SourceForge , BitbucketและGitLab [ ^{104 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ]}

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

ส่วนขยาย Git แบบโอเพนซอร์สอื่นๆ ได้แก่:

• git-annexคือระบบซิงโครไนซ์ไฟล์แบบกระจายศูนย์ที่ใช้ Git เป็นพื้นฐาน
• git-flowคือชุดส่วนขยายของ Git ที่ช่วยให้สามารถดำเนินการกับที่เก็บข้อมูลระดับสูงได้ตามแบบจำลองการแตกสาขาของ Vincent Driessen
• git-machete คือเครื่องมือจัดการและควบคุมพื้นที่เก็บข้อมูล (repository) สำหรับการทำ automating rebase/merge/pull/push

Microsoft ได้พัฒนา ส่วนขยาย Virtual File System for Git (VFS for Git; เดิมชื่อ Git Virtual File System หรือ GVFS) เพื่อจัดการขนาดของโครงสร้างซอร์สโค้ดของ Windows ซึ่งเป็นส่วนหนึ่งของการย้ายจาก Perforce ในปี 2017 VFS for Git อนุญาตให้ที่เก็บข้อมูลที่โคลนมาใช้ตัวยึดตำแหน่งซึ่งเนื้อหาจะถูกดาวน์โหลดเพียงครั้งเดียวเมื่อมีการเข้าถึงไฟล์^{[ 119 ]}