جيت

الموسوعة الحرة

جيت
المؤلف(ون) الأصلي(ون)لينوس تورفالدس [1]
المطور(ون)جونيو هامانو وآخرون [2]
الإصدار الأولي7 أبريل 2005 ؛ منذ 19 عامًا ( 2005-04-07 )
إصدار مستقر
2.47.0 [3]  / 7 أكتوبر 2024
مستودع
  • git.kernel.org/pub/scm/git/git.git
مكتوب فيفي المقام الأول بلغة C ، مع واجهة المستخدم الرسومية ونصوص البرمجة المكتوبة بلغة Shell script و Perl و Tcl و Python [4] [5]
نظام التشغيلPOSIX ( Linux ، macOS ، Solaris ، AIX )، Windows
متوفر فيإنجليزي
يكتبالتحكم في الإصدار
رخصةGPL-2.0 فقط [i] [7]
موقع إلكترونيgit-scm.com 

Git ( / ɡɪt / ) [8] هو نظام تحكم في الإصدارات الموزعة [9] والذي يتتبع إصدارات الملفات . وغالبًا ما يستخدم للتحكم في الكود المصدر من قبل المبرمجين الذين يطورون البرامج بشكل تعاوني.

تتضمن أهداف تصميم Git السرعة وسلامة البيانات ودعم تدفقات العمل الموزعة وغير الخطية - آلاف الفروع المتوازية التي تعمل على أجهزة كمبيوتر مختلفة. [10] [11] [12]

تم إنشاء Git لاستخدامه في تطوير نواة Linux بواسطة Linus Torvalds وآخرين يعملون على تطوير النواة. [13]

كما هو الحال مع معظم أنظمة التحكم في الإصدارات الموزعة الأخرى، وعلى عكس معظم أنظمة العميل والخادم ، يحتفظ Git بنسخة محلية من المستودع بالكامل ، المعروف أيضًا باسم المستودع، مع إمكانيات تتبع التاريخ والإصدار، بغض النظر عن الوصول إلى الشبكة أو الخادم المركزي . يتم تخزين المستودع على كل جهاز كمبيوتر في دليل قياسي مع ملفات مخفية إضافية لتوفير إمكانيات التحكم في الإصدار. [14] يوفر Git ميزات لمزامنة التغييرات بين المستودعات التي تشترك في التاريخ؛ يتم نسخها (استنساخها) من بعضها البعض. للتعاون، يدعم Git المزامنة مع المستودعات على الأجهزة البعيدة . على الرغم من أن جميع المستودعات (التي لها نفس التاريخ) هي أقران، إلا أن المطورين غالبًا ما يستخدمون خادمًا مركزيًا لاستضافة مستودع لحمل نسخة متكاملة.

Git هو برنامج مفتوح المصدر ومجاني ومتاح بموجب ترخيص GPL-2.0 فقط .

تم تسجيل العلامة التجارية "Git" من قبل منظمة Software Freedom Conservancy ، مما يشير إلى الاعتراف الرسمي بها وتطورها المستمر في مجتمع المصدر المفتوح .

اليوم، يعد Git نظام التحكم في الإصدارات القياسي بحكم الأمر الواقع . وهو نظام التحكم في الإصدارات الموزع الأكثر شيوعًا، حيث أفاد ما يقرب من 95% من المطورين بأنه نظام التحكم في الإصدارات الأساسي لديهم اعتبارًا من عام 2022. [15] إنه أداة إدارة التعليمات البرمجية المصدرية الأكثر استخدامًا بين المطورين المحترفين. هناك عروض لخدمات مستودع Git، بما في ذلك GitHub و SourceForge و Bitbucket و GitLab . [16] [17] [18] [19] [20]

تاريخ

بدأ تورفالدز تطوير جيت في أبريل 2005 بعد إلغاء الترخيص المجاني لـ BitKeeper ، نظام إدارة التحكم في المصدر (SCM) الخاص المستخدم لتطوير نواة لينكس منذ عام 2002، لنظام لينكس. [21] [22] ادعى حامل حقوق الطبع والنشر لـ BitKeeper، لاري ماكفوي ، أن أندرو تريدجيل قد أنشأ SourcePuller عن طريق الهندسة العكسية لبروتوكولات BitKeeper . [23] كما حفز نفس الحادث إنشاء Mercurial ، نظام آخر للتحكم في الإصدارات.

أراد تورفالدز نظامًا موزعًا يمكنه استخدامه مثل BitKeeper، لكن لم يلب أي من الأنظمة المجانية المتاحة احتياجاته. استشهد بمثال لنظام إدارة التحكم في المصدر الذي يحتاج إلى 30 ثانية لتطبيق التصحيح وتحديث جميع البيانات الوصفية المرتبطة به، وأشار إلى أن هذا لن يتناسب مع احتياجات تطوير نواة Linux، حيث قد تتطلب المزامنة مع زملاء الصيانة 250 إجراءً من هذا القبيل في وقت واحد. بالنسبة لمعيار التصميم الخاص به، حدد أن التصحيح يجب ألا يستغرق أكثر من ثلاث ثوانٍ، وأضاف ثلاثة أهداف أخرى: [10]

  • خذ نظام الإصدارات المتزامنة (CVS) كمثال لما لا ينبغي عليك فعله؛ وفي حالة الشك، اتخذ القرار المعاكس تمامًا. [12]
  • دعم سير عمل موزع يشبه BitKeeper. [12]
  • تتضمن ضمانات قوية جدًا ضد الفساد، سواء كان عرضيًا أو خبيثًا. [11]

أدت هذه المعايير إلى إزالة كل أنظمة التحكم في الإصدارات المستخدمة في ذلك الوقت، لذلك مباشرة بعد إصدار تطوير نواة لينكس 2.6.12-rc2، شرع تورفالدز في كتابة نظامه الخاص. [12]

بدأ تطوير جيت في 3 أبريل 2005. [24] أعلن تورفالدز عن المشروع في 6 أبريل وأصبح يستضيف نفسه في اليوم التالي. [24] [25] تم أول دمج للفروع المتعددة في 18 أبريل. [26] حقق تورفالدز أهدافه في الأداء؛ في 29 أبريل، تم اختبار جيت الناشئ لتسجيل التصحيحات لشجرة نواة لينكس بمعدل 6.7 تصحيح في الثانية. [27] في 16 يونيو، أدار جيت إصدار نواة 2.6.12. [28]

سلم تورفالدز مهمة الصيانة في 26 يوليو 2005 إلى جونيو هامانو، وهو أحد المساهمين الرئيسيين في المشروع. [29] وكان هامانو مسؤولاً عن إصدار 1.0 في 21 ديسمبر 2005. [30]

تسمية

وقد أطلق تورفالدز نكتة ساخرة حول اسم git (الذي يعني "شخص غير سار" في اللغة العامية الإنجليزية البريطانية ): "أنا لقيط مغرور، وأسمي جميع مشاريعي باسمي. أولاً " Linux "، والآن "git". [31] [32] وتصف صفحة الدليل git بأنه "متعقب المحتوى الغبي". [33]

يقدم ملف read-me الخاص برمز المصدر مزيدًا من التفاصيل: [34]

يمكن أن تعني كلمة "git" أي شيء، اعتمادًا على حالتك المزاجية.

  • تركيبة عشوائية مكونة من ثلاثة أحرف يمكن نطقها، ولا تستخدم في الواقع بواسطة أي أمر شائع في UNIX. قد تكون حقيقة كونها نطقًا خاطئًا لكلمة "get" ذات صلة أو لا تكون كذلك.
  • غبي. حقير وحقير. بسيط. اختر ما يناسبك من قاموس العامية.
  • "متتبع المعلومات العالمي": أنت في مزاج جيد، وهو يعمل لصالحك بالفعل. الملائكة تغني، وفجأة يملأ الضوء الغرفة.
  • "شاحنة غبية مليئة بالقذارة" عندما تنكسر.

يشير الكود المصدر لـ Git إلى البرنامج باعتباره "مدير المعلومات من الجحيم".

صفات

تصميم

إن تصميم Git هو عبارة عن توليفة من خبرة Torvalds مع Linux في صيانة مشروع تطوير موزع كبير، إلى جانب معرفته الدقيقة بأداء نظام الملفات الذي اكتسبه من نفس المشروع والحاجة الملحة لإنتاج نظام يعمل في وقت قصير. أدت هذه التأثيرات إلى اختيارات التنفيذ التالية: [13]

دعم قوي للتطوير غير الخطي
يدعم Git التفرع والدمج السريع، ويتضمن أدوات محددة لتصور تاريخ التطوير غير الخطي والتنقل فيه. في Git، هناك افتراض أساسي مفاده أن التغيير سيتم دمجه أكثر من كتابته، حيث يتم تمريره إلى مراجعين مختلفين. في Git، الفروع خفيفة الوزن للغاية: الفرع هو مجرد مرجع إلى التزام واحد.
التطوير الموزع
مثل Darcs و BitKeeper و Mercurial و Bazaar و Monotone ، يمنح Git كل مطور نسخة محلية من تاريخ التطوير الكامل، ويتم نسخ التغييرات من مستودع إلى آخر. يتم استيراد هذه التغييرات كفروع تطوير مضافة ويمكن دمجها بنفس الطريقة مثل الفرع المطوَّر محليًا. [35]
التوافق مع الأنظمة والبروتوكولات الحالية
يمكن نشر المستودعات عبر بروتوكول نقل النص التشعبي الآمن (HTTPS)، أو بروتوكول نقل النص التشعبي (HTTP)، أو بروتوكول نقل الملفات (FTP)، أو بروتوكول Git عبر مقبس عادي أو Secure Shell (ssh). يحتوي Git أيضًا على محاكاة خادم CVS، والتي تمكن من استخدام عملاء CVS الحاليين ومكونات IDE للوصول إلى مستودعات Git. يمكن استخدام مستودعات Subversion مباشرةً مع git-svn. [36]
التعامل الفعّال مع المشاريع الكبيرة
وقد وصف تورفالدز Git بأنه سريع للغاية وقابل للتطوير، [37] وأظهرت اختبارات الأداء التي أجرتها شركة Mozilla [38] أنه كان أسرع بمقدار مرتبة واحدة في المقارنة بين المستودعات الكبيرة مقارنة بـ Mercurial و GNU Bazaar ؛ حيث يمكن أن يكون جلب تاريخ الإصدار من مستودع مخزن محليًا أسرع بمئة مرة من جلبه من الخادم البعيد. [39]
المصادقة التشفيرية للتاريخ
يتم تخزين تاريخ Git بطريقة تجعل معرف إصدار معين ( الالتزام بمصطلحات Git) يعتمد على تاريخ التطوير الكامل الذي أدى إلى هذا الالتزام. بمجرد نشره، لا يمكن تغيير الإصدارات القديمة دون أن يتم ملاحظتها. البنية مشابهة لشجرة Merkle ، ولكن مع إضافة بيانات عند العقد والأوراق. [40] ( تتمتع Mercurial و Monotone أيضًا بهذه الخاصية.)
التصميم المبني على مجموعة الأدوات
تم تصميم Git كمجموعة من البرامج المكتوبة بلغة C والعديد من البرامج النصية التي توفر غلافات حول تلك البرامج. [41] وعلى الرغم من إعادة كتابة معظم تلك البرامج النصية بلغة C منذ ذلك الحين من أجل السرعة والقدرة على النقل، إلا أن التصميم لا يزال قائمًا، ومن السهل ربط المكونات معًا. [42]
استراتيجيات الدمج القابلة للتوصيل
كجزء من تصميم مجموعة أدواته، يحتوي Git على نموذج محدد جيدًا للدمج غير المكتمل، ولديه خوارزميات متعددة لإكماله، والتي تنتهي بإخبار المستخدم بأنه غير قادر على إكمال الدمج تلقائيًا وأن التحرير اليدوي مطلوب. [43]
تتراكم القمامة حتى يتم جمعها
إن إلغاء العمليات أو التراجع عن التغييرات سيترك كائنات معلقة عديمة الفائدة في قاعدة البيانات. وهذه عادةً ما تكون جزءًا صغيرًا من التاريخ المتزايد باستمرار للكائنات المطلوبة. سيقوم Git تلقائيًا بجمع القمامة عند إنشاء عدد كافٍ من الكائنات غير المرغوبة في المستودع. يمكن استدعاء جمع القمامة صراحةً باستخدام git gc. [44] [45]
التعبئة الدورية الصريحة للأشياء
يقوم Git بتخزين كل كائن تم إنشاؤه حديثًا كملف منفصل. وعلى الرغم من ضغطه بشكل فردي، إلا أن هذا يشغل مساحة كبيرة وغير فعال. يتم حل هذه المشكلة باستخدام حزم تخزن عددًا كبيرًا من الكائنات المضغوطة دلتا فيما بينها في ملف واحد (أو مجرى بايتات الشبكة) يسمى packfile . يتم ضغط الحزم باستخدام القاعدة التي تنص على أن الملفات التي تحمل نفس الاسم ربما تكون متشابهة، دون الاعتماد على هذا من أجل الدقة. يتم إنشاء ملف فهرس مطابق لكل ملف packfile، يسجل إزاحة كل كائن في packfile. لا تزال الكائنات التي تم إنشاؤها حديثًا (مع التاريخ المضاف حديثًا) مخزنة ككائنات فردية، وهناك حاجة إلى إعادة التعبئة الدورية للحفاظ على كفاءة المساحة. يمكن أن تكون عملية تعبئة المستودع مكلفة للغاية من الناحية الحسابية. من خلال السماح للكائنات بالوجود في المستودع بتنسيق فضفاض ولكن تم إنشاؤه بسرعة، يسمح Git بتأجيل عملية التعبئة المكلفة إلى وقت لاحق، عندما يكون الوقت أقل أهمية، على سبيل المثال، نهاية يوم العمل. يقوم Git بإعادة التعبئة الدورية تلقائيًا، ولكن إعادة التعبئة اليدوية ممكنة أيضًا باستخدام git gcالأمر. [46] من أجل سلامة البيانات، يحتوي كل من ملف الحزمة وفهرسه على مجموع اختباري SHA-1 [47] بداخله، ويحتوي اسم ملف الحزمة أيضًا على مجموع اختباري SHA-1. للتحقق من سلامة المستودع، قم بتشغيل git fsckالأمر. [48] [49]

من خصائص Git الأخرى أنه يلتقط صورًا لأشجار الدليل للملفات. عملت أقدم أنظمة تتبع إصدارات الكود المصدري، نظام التحكم في الكود المصدري (SCCS) ونظام التحكم في المراجعة (RCS)، على ملفات فردية وركزت على توفير المساحة التي يمكن الحصول عليها من الدلتا المتداخلة (SCCS) أو ترميز الدلتا (RCS) للإصدارات (المتشابهة في الغالب). حافظت أنظمة التحكم في المراجعة اللاحقة على فكرة أن الملف له هوية عبر مراجعات متعددة لمشروع ما. ومع ذلك، رفض تورفالدز هذا المفهوم. [50] وبالتالي، لا يسجل Git صراحةً علاقات مراجعة الملف على أي مستوى أسفل شجرة الكود المصدري.

السلبيات

إن علاقات المراجعة الضمنية هذه لها بعض العواقب الهامة:

  • إن فحص سجل التغييرات لملف واحد أكثر تكلفة قليلاً من فحص المشروع بأكمله. [51] للحصول على سجل التغييرات التي تؤثر على ملف معين، يجب على Git أن يتتبع السجل العالمي ثم يحدد ما إذا كان كل تغيير قد عدل هذا الملف. ومع ذلك، فإن طريقة فحص السجل هذه تسمح لـ Git بإنتاج سجل واحد بنفس الكفاءة يوضح التغييرات على مجموعة عشوائية من الملفات. على سبيل المثال، يعد الدليل الفرعي لشجرة المصدر بالإضافة إلى ملف رأس عالمي مرتبط حالة شائعة جدًا.
  • تتم معالجة عمليات إعادة التسمية ضمنيًا وليس صراحةً. الشكوى الشائعة بشأن CVS هي أنها تستخدم اسم الملف لتحديد تاريخ المراجعة الخاص به، وبالتالي فإن نقل أو إعادة تسمية الملف غير ممكن دون مقاطعة تاريخه أو إعادة تسمية التاريخ وبالتالي جعل التاريخ غير دقيق. تحل معظم أنظمة التحكم في المراجعة بعد CVS هذه المشكلة عن طريق إعطاء الملف اسمًا فريدًا طويل الأمد (مشابهًا لرقم العقدة ) يبقى على قيد الحياة بعد إعادة التسمية. لا يسجل Git مثل هذا المعرف، ويُزعم أن هذا ميزة. [52] [53] يتم تقسيم ملفات التعليمات البرمجية المصدرية أو دمجها في بعض الأحيان، أو إعادة تسميتها ببساطة، [54] وتسجيل هذا على أنه إعادة تسمية بسيطة من شأنه أن يجمّد وصفًا غير دقيق لما حدث في التاريخ (غير القابل للتغيير). يعالج Git المشكلة عن طريق اكتشاف عمليات إعادة التسمية أثناء تصفح تاريخ اللقطات بدلاً من تسجيلها عند إنشاء اللقطة. [55] (باختصار، إذا كان هناك ملف في المراجعة N ، فإن الملف الذي يحمل نفس الاسم في المراجعة N  − 1 هو سلفه الافتراضي. ومع ذلك، عندما لا يوجد ملف يحمل نفس الاسم في المراجعة N  − 1، يبحث Git عن ملف كان موجودًا فقط في المراجعة N  − 1 وهو مشابه جدًا للملف الجديد.) ومع ذلك، فإنه يتطلب المزيد من العمل المكثف لوحدة المعالجة المركزية في كل مرة يتم فيها مراجعة السجل، وتتوفر عدة خيارات لضبط القواعد. لا تعمل هذه الآلية دائمًا؛ في بعض الأحيان، يُقرأ الملف الذي تمت إعادة تسميته بالتغييرات في نفس الالتزام على أنه حذف للملف القديم وإنشاء ملف جديد. يمكن للمطورين التغلب على هذا القيد من خلال الالتزام بإعادة التسمية والتغييرات بشكل منفصل.

دمج الاستراتيجيات

ينفذ Git العديد من استراتيجيات الدمج؛ ويمكن تحديد استراتيجية غير افتراضية في وقت الدمج: [56]

  • الحل : خوارزمية الدمج الثلاثية التقليدية .
  • متكرر : هذا هو الوضع الافتراضي عند سحب أو دمج فرع واحد، وهو أحد أشكال خوارزمية الدمج الثلاثي.

    عندما يكون هناك أكثر من سلف مشترك يمكن استخدامه للدمج ثلاثي الاتجاهات، فإنه ينشئ شجرة مدمجة من السلف المشترك ويستخدمها كشجرة مرجعية للدمج ثلاثي الاتجاهات. وقد تم الإبلاغ عن أن هذا يؤدي إلى تقليل تعارضات الدمج دون التسبب في دمج خاطئ من خلال الاختبارات التي أجريت على عمليات الدمج السابقة المأخوذة من سجل تطوير نواة Linux 2.6. كما يمكن لهذا اكتشاف عمليات الدمج التي تتضمن إعادة تسمية والتعامل معها.

    —  لينوس تورفالدس [57]
  • الأخطبوط : هذا هو الوضع الافتراضي عند دمج أكثر من رأسين.

هياكل البيانات

لا تعد عناصر Git الأساسية نظامًا لإدارة التعليمات البرمجية المصدرية . يوضح تورفالدز: [58]

في كثير من النواحي، يمكنك رؤية git كنظام ملفات - فهو قابل للعنونة بالمحتوى ، ولديه فكرة عن الإصدارات، ولكنني صممته في الواقع من وجهة نظر شخص متخصص في نظام الملفات (مرحبًا، أنوية النظام هي ما أفعله)، وأنا في الواقع ليس لدي أي اهتمام على الإطلاق بإنشاء نظام SCM تقليدي.

من خلال نهج التصميم الأولي هذا، طورت Git المجموعة الكاملة من الميزات المتوقعة من نظام إدارة سلسلة التوريد التقليدي، [59] مع إنشاء الميزات في الغالب حسب الحاجة، ثم تحسينها وتوسيعها بمرور الوقت.

بعض تدفقات البيانات ومستويات التخزين في نظام التحكم في المراجعة Git

يحتوي Git على بنيتين للبيانات : فهرس قابل للتغيير (يُسمى أيضًا المرحلة أو ذاكرة التخزين المؤقت ) يخزن معلومات مؤقتة حول دليل العمل والإصدار التالي الذي سيتم الالتزام به؛ وقاعدة بيانات الكائنات التي تخزن الكائنات غير القابلة للتغيير.

يعمل الفهرس كنقطة اتصال بين قاعدة بيانات الكائنات وشجرة العمل.

يحتوي مخزن الكائنات على خمسة أنواع من الكائنات: [60] [48]

  • الكائن هو محتوى ملف . لا تحتوي الكائنات على اسم ملف صحيح أو طوابع زمنية أو بيانات وصفية أخرى (اسم الكائن داخليًا هو تجزئة لمحتواه). في Git، كل كائن هو إصدار من ملف، يحتوي على بيانات الملف. [61]
  • كائن الشجرة هو المعادل للدليل. فهو يحتوي على قائمة بأسماء الملفات، [62] كل منها يحتوي على بعض بتات النوع ومرجع إلى كائن كتلة أو شجرة يمثل محتويات ذلك الملف أو الرابط الرمزي أو الدليل. هذه الكائنات هي لقطة من شجرة المصدر. (بشكل عام، يتألف هذا من شجرة ميركل ، مما يعني أن تجزئة واحدة فقط للشجرة الجذرية تكفي وتستخدم فعليًا في عمليات الالتزام لتحديد الحالة الدقيقة لهياكل الشجرة الكاملة لأي عدد من الدلائل الفرعية والملفات.)
  • يربط كائن الالتزام كائنات الشجرة معًا في التاريخ. ويحتوي على اسم كائن الشجرة (من دليل المصدر على المستوى الأعلى)، وعلامة زمنية، ورسالة سجل، وأسماء صفر أو أكثر من كائنات الالتزام الرئيسية. [63]
  • كائن العلامة هو حاوية تحتوي على مرجع لكائن آخر ويمكنها الاحتفاظ ببيانات وصفية مضافة تتعلق بكائن آخر. في أغلب الأحيان، يتم استخدامه لتخزين التوقيع الرقمي لكائن الالتزام المقابل لإصدار معين من البيانات التي يتعقبها Git. [64]
  • يقوم كائن ملف الحزمة بجمع العديد من الكائنات الأخرى في حزمة مضغوطة بـ zlib لتحقيق الاكتناز وسهولة النقل عبر بروتوكولات الشبكة. [65]

يتم تحديد كل كائن من خلال تجزئة SHA-1 لمحتوياته. يحسب Git التجزئة ويستخدم هذه القيمة لاسم الكائن. يتم وضع الكائن في دليل يطابق أول حرفين من تجزئة الكائن. يتم استخدام بقية التجزئة كاسم ملف لهذا الكائن.

يخزن Git كل مراجعة لملف على هيئة كائن فريد. ويمكن العثور على العلاقات بين الكائنات من خلال فحص الشجرة وكائنات الالتزام. يتم تخزين الكائنات المضافة حديثًا بالكامل باستخدام ضغط zlib. يمكن أن يستهلك هذا قدرًا كبيرًا من مساحة القرص بسرعة، لذلك يمكن دمج الكائنات في حزم ، والتي تستخدم ضغط دلتا لتوفير المساحة، وتخزين الكائنات كتغييراتها بالنسبة للكائنات الأخرى.

بالإضافة إلى ذلك، يخزن Git تسميات تسمى refs (اختصارًا لـ references) للإشارة إلى مواقع عمليات الالتزام المختلفة. يتم تخزينها في قاعدة بيانات مرجعية وهي على التوالي: [66]

  • الرؤوس (الفروع) : مراجع مسماة يتم نقلها تلقائيًا إلى الالتزام الجديد عند إجراء التزام أعلى منها.
  • HEAD : رأس محجوز سيتم مقارنته بشجرة العمل لإنشاء التزام.
  • العلامات : مثل مراجع الفروع، ولكنها مرتبطة بتعهد معين. تُستخدم لتمييز النقاط المهمة في التاريخ.

الأوامر

تتضمن الأوامر المستخدمة بشكل متكرر لواجهة سطر أوامر Git ما يلي : [67] [68]

  • git init، والذي يستخدم لإنشاء مستودع git.
  • git clone [URL]، الذي يستنسخ أو يكرر مستودع git من عنوان URL خارجي.
  • git add [file]، والذي يضيف ملفًا إلى دليل عمل git (الملفات التي سيتم الالتزام بها).
  • git commit -m [commit message]، الذي يقوم بإرسال الملفات من دليل العمل الحالي (لذا فهي الآن جزء من تاريخ المستودع).

يمكن إنشاء ملف .gitignore في مستودع Git كملف نص عادي. لن يتم تتبع الملفات المدرجة في ملف .gitignore بواسطة Git. [69] : 3–4  يمكن استخدام هذه الميزة لتجاهل الملفات التي تحتوي على مفاتيح أو كلمات مرور، والملفات غير ذات الصلة المختلفة، والملفات الكبيرة (التي سيرفض GitHub تحميلها). [70]

مراجع Git

يمكن تنظيف كل كائن في قاعدة بيانات Git غير المشار إليه باستخدام أمر جمع القمامة أو تلقائيًا. يمكن الرجوع إلى كائن بواسطة كائن آخر أو مرجع صريح. يحتوي Git على أنواع مختلفة من المراجع. تختلف الأوامر لإنشاء المراجع ونقلها وحذفها. git show-refتسرد قائمة بجميع المراجع. بعض الأنواع هي:

  • الرؤوس : تشير إلى كائن محليًا،
  • أجهزة التحكم عن بعد : تشير إلى كائن موجود في مستودع بعيد،
  • stash : يشير إلى كائن لم يتم الالتزام به بعد،
  • meta : على سبيل المثال ، تكوين في مستودع فارغ، حقوق المستخدم؛ تم تقديم مساحة اسم refs/meta/config بأثر رجعي، ويستخدمها Gerrit ، [71]
  • العلامات : انظر أعلاه.

التنفيذات

gitg عبارة عن واجهة أمامية رسومية تستخدم GTK+ .

تم تطوير Git (التنفيذ الرئيسي بلغة C) بشكل أساسي على Linux ، على الرغم من أنه يدعم أيضًا معظم أنظمة التشغيل الرئيسية، بما في ذلك BSD ( DragonFly BSD و FreeBSD و NetBSD و OpenBSD )، و Solaris و macOS و Windows . [72] [73]

كان أول إصدار من Git لنظام Windows عبارة عن إطار عمل لمحاكاة Linux يستضيف إصدار Linux. يؤدي تثبيت Git في Windows إلى إنشاء دليل ملفات البرنامج المسمى بشكل مشابه والذي يحتوي على منفذ Mingw-w64 لمجموعة GNU Compiler Collection و Perl 5 و MSYS2 (وهو في حد ذاته فرع من Cygwin ، بيئة محاكاة شبيهة بـ Unix لنظام Windows) والعديد من منافذ Windows الأخرى أو محاكاة أدوات Linux والمكتبات. حاليًا، يتم توزيع إصدارات Windows الأصلية من Git كمثبتات 32 بت و64 بت. [74] يحتفظ موقع git الرسمي حاليًا بإصدار من Git لنظام Windows، ولا يزال يستخدم بيئة MSYS2. [75]

إن تنفيذ JGit لـ Git عبارة عن مكتبة برمجية Java خالصة ، مصممة ليتم تضمينها في أي تطبيق Java. يتم استخدام JGit في أداة مراجعة التعليمات البرمجية Gerrit ، وفي EGit، عميل Git لـ Eclipse IDE. [76]

Go-git هو تنفيذ مفتوح المصدر لـ Git مكتوب بلغة Go الخالصة . [77] يتم استخدامه حاليًا لدعم المشاريع كواجهة SQL لمستودعات أكواد Git [78] وتوفير التشفير لـ Git. [79]

Dulwich هو تنفيذ لـ Git مكتوب بلغة Python الخالصة مع دعم CPython 3.6 والإصدارات الأحدث وPypy. [80]

تنفيذ libgit2 لـ Git عبارة عن مكتبة برمجية ANSI C بدون أي تبعيات أخرى، ويمكن بناؤها على منصات متعددة، بما في ذلك Windows وLinux وmacOS وBSD. [81] لديها ارتباطات للعديد من لغات البرمجة، بما في ذلك Ruby وPython و Haskell . [82] [83] [84]

JS-Git هو تنفيذ JavaScript لمجموعة فرعية من Git. [85]

GameOfTrees هو تنفيذ مفتوح المصدر لـ Git لمشروع OpenBSD. [86]

خادم جيت

لقطة شاشة لواجهة Gitweb تُظهر اختلاف الالتزام

نظرًا لأن Git عبارة عن نظام تحكم في الإصدارات الموزعة، فيمكن استخدامه كخادم جاهز للاستخدام. يتم شحنه مع أمر مدمج git daemonيبدأ خادم TCP بسيط يعمل على بروتوكول Git. [87] [88] تساعد خوادم Git HTTP المخصصة (من بين ميزات أخرى) عن طريق إضافة التحكم في الوصول وعرض محتويات مستودع Git عبر واجهات الويب وإدارة مستودعات متعددة. يمكن استنساخ مستودعات Git الموجودة بالفعل ومشاركتها لاستخدامها من قبل الآخرين كمستودع مركزي. يمكن أيضًا الوصول إليها عبر shell بعيد بمجرد تثبيت برنامج Git والسماح للمستخدم بتسجيل الدخول. [89] تستمع خوادم Git عادةً على منفذ TCP 9418. [90]

المصدر المفتوح

  • استضافة خادم Git باستخدام Git Binary. [91]
  • Gerrit ، خادم Git قابل للتكوين لدعم مراجعات التعليمات البرمجية وتوفير الوصول عبر ssh، أو Apache MINA أو OpenSSH المتكامل، أو خادم ويب Jetty المتكامل . يوفر Gerrit التكامل لشهادات العميل LDAP وActive Directory وOpenID وOAuth وKerberos/GSSAPI وX509 https. مع Gerrit 3.0، سيتم تخزين جميع التكوينات كمستودعات Git، ولا يلزم تشغيل أي قاعدة بيانات. يحتوي Gerrit على ميزة طلب سحب تم تنفيذها في جوهره ولكنه يفتقر إلى واجهة مستخدم رسومية لذلك.
  • Phabricator ، وهو منتج فرعي من Facebook. نظرًا لأن Facebook يستخدم Mercurial بشكل أساسي ، فإن دعم Git ليس بارزًا بنفس القدر. [92]
  • RhodeCode Community Edition (CE)، يدعم Git و Mercurial و Subversion مع ترخيص AGPLv3 .
  • Kallithea ، يدعم كل من Git و Mercurial ، تم تطويره في Python برخصة GPL .
  • المشاريع الخارجية مثل gitolite، [93] والتي توفر البرامج النصية أعلى برنامج Git لتوفير التحكم الدقيق في الوصول.
  • هناك العديد من حلول FLOSS الأخرى للاستضافة الذاتية، بما في ذلك Gogs، [94] وGitea ، وهو فرع من Gogs، بالإضافة إلى Forgejo ، وهو بدوره فرع من Gitea. تم تطوير Gogs، بالإضافة إلى المشتقات المذكورة أعلاه منه، باستخدام لغة Go . يتم توفير الحلول الثلاثة بموجب ترخيص MIT .

خادم Git كخدمة

هناك العديد من العروض التي تقدمها مستودعات Git كخدمة. أشهرها هي GitHub و SourceForge و Bitbucket و GitLab . [95] [17] [18] [19] [20]

الواجهات الرسومية

قد يكون Git، وهو نظام قوي للتحكم في الإصدارات، أمرًا شاقًا بسبب واجهته التي تعتمد على سطر الأوامر. توفر عملاء Git GUI واجهة مستخدم رسومية (GUI) لتبسيط التفاعل مع مستودعات Git.

توفر واجهات المستخدم الرسومية هذه تمثيلات مرئية لتاريخ مشروعك، بما في ذلك الفروع والالتزامات وتغييرات الملفات. كما تعمل على تبسيط الإجراءات مثل تغييرات المرحلة وإنشاء الالتزامات وإدارة الفروع. تساعد أدوات الاختلاف المرئية في حل تعارضات الدمج الناشئة عن التطوير المتزامن.

يأتي Git مع واجهة مستخدم رسومية Tcl/Tk ، والتي تسمح للمستخدمين بتنفيذ إجراءات مثل إنشاء وتعديل الالتزامات، وإنشاء الفروع ودمجها، والتفاعل مع المستودعات البعيدة. [96]

بالإضافة إلى واجهة المستخدم الرسومية الرسمية، توجد العديد من واجهات الطرف الثالث التي توفر ميزات مماثلة لواجهة المستخدم الرسومية الرسمية الموزعة مع Git، مثل GitHub Desktop، وSourceTree، وTortoiseGit. [97]

تجعل عملاء واجهة المستخدم الرسومية Git أسهل في التعلم والاستخدام، مما يحسن كفاءة سير العمل ويقلل الأخطاء. تشمل الخيارات الشائعة GitKraken Desktop متعدد الأنظمة الأساسية (مجاني جزئيًا) وSourcetree (مجاني/مدفوع)، أو خيارات خاصة بالمنصة مثل GitHub Desktop (مجاني) لنظامي التشغيل Windows/macOS وTortoiseGit (مجاني) لنظام التشغيل Windows.

قائمة عملاء واجهة المستخدم الرسومية

في حين يوفر Git أدوات واجهة مستخدم رسومية مدمجة (git-gui، gitk)، فإن مجموعة أوسع من خيارات الطرف الثالث تلبي تفضيلات المستخدم الخاصة بالمنصة.

واجهات المستخدم الرسومية لنظام Windows (GNU GPL/MIT وFree)

  • سطح مكتب GitHub
  • شجرة المصدر
  • تورتويز جيت
  • ملحقات Git
  • جيتغ
  • MeGit (بناءً على EGit)
  • جيت يو آي

واجهات المستخدم الرسومية لنظام التشغيل Mac (GNU GPL/MIT وFree)

  • سطح مكتب GitHub
  • شجرة المصدر

واجهات المستخدم الرسومية لنظام Linux (GNU GPL/MIT وFree)

  • جيتغ
  • MeGit (بناءً على EGit)
  • جيت يو آي
  • قهقه

واجهة المستخدم الرسومية GIT الملكية

  • SmartGit (ويندوز، لينكس، ماك)
  • GitKraken سطح المكتب (Windows، Linux، Mac)
  • جلينت (ويندوز، لينكس، ماك)
  • Git Tower (ويندوز، ماك)
  • SourceTree (ويندوز، ماك)

التبني

ذكرت مؤسسة Eclipse في استطلاعها السنوي للمجتمع أنه اعتبارًا من مايو 2014، أصبح Git الآن أداة إدارة التعليمات البرمجية المصدرية الأكثر استخدامًا، حيث أفاد 42.9% من مطوري البرامج المحترفين أنهم يستخدمون Git كنظام أساسي للتحكم في المصدر [98] مقارنة بـ 36.3% في عام 2013، و32% في عام 2012؛ أو لاستجابات Git باستثناء استخدام GitHub : 33.3% في عام 2014، و30.3% في عام 2013، و27.6% في عام 2012، و12.8% في عام 2011. [99] يشير دليل المصدر المفتوح Black Duck Open Hub إلى زيادة مماثلة بين مشاريع المصدر المفتوح. [100]

لقد أدرج موقع Stack Overflow التحكم في الإصدارات في استطلاع المطورين السنوي الخاص به [101] في عام 2015 (16694 استجابة)، [102] و2017 (30730 استجابة)، [103] و2018 (74298 استجابة) [104] و2022 (71379 استجابة). [15] كان Git هو المفضل بشكل كبير لدى المطورين المستجيبين في هذه الاستطلاعات، حيث أفاد بنسبة 93.9% في عام 2022.

أنظمة التحكم في الإصدارات المستخدمة من قبل المطورين المستجيبين:

اسم 2015 2017 2018 2022
جيت 69.3% 69.2% 87.2% 93.9%
التخريب 36.9% 9.1% 16.1% 5.2%
تي اف في سي 12.2% 7.3% 10.9% [ثانيا]
زئبقي 7.9% 1.9% 3.6% 1.1%
سي في اس 4.2% [ثانيا] [ثانيا] [ثانيا]
بالقوة 3.3% [ثانيا] [ثانيا] [ثانيا]
في اس اس [ثانيا] 0.6% [ثانيا] [ثانيا]
IBM DevOps Code ClearCase [ثانيا] 0.4% [ثانيا] [ثانيا]
النسخ الاحتياطي لملفات ZIP [ثانيا] 2.0% 7.9% [ثانيا]
مشاركة الشبكة الخام [ثانيا] 1.7% 7.9% [ثانيا]
آخر 5.8% 3.0% [ثانيا] [ثانيا]
لا أحد 9.3% 4.8% 4.8% 4.3%

يذكر موقع وظائف تكنولوجيا المعلومات في المملكة المتحدة itjobswatch.co.uk أنه اعتبارًا من أواخر سبتمبر 2016، استشهد 29.27% ​​من وظائف تطوير البرمجيات الدائمة في المملكة المتحدة بـ Git، [105] متقدمًا على 12.17% لـ Microsoft Team Foundation Server ، [106] و10.60% لـ Subversion ، [107] و 1.30% لـ Mercurial ، [108] و0.48% لـ Visual SourceSafe . [109]

الإضافات

هناك العديد من ملحقات Git ، مثل Git LFS، الذي بدأ كملحق لـ Git في مجتمع GitHub ويُستخدم الآن على نطاق واسع من قبل مستودعات أخرى. عادةً ما يتم تطوير الملحقات وصيانتها بشكل مستقل من قبل أشخاص مختلفين، ولكن في مرحلة ما في المستقبل، يمكن دمج ملحق مستخدم على نطاق واسع مع Git.

تتضمن ملحقات Git مفتوحة المصدر الأخرى ما يلي:

  • git-annex ، نظام مزامنة الملفات الموزعة الذي يعتمد على Git
  • git-flow، مجموعة من ملحقات Git لتوفير عمليات مستودع عالية المستوى لنموذج التفرع الخاص بـ Vincent Driessen
  • git-machete، منظم مستودع وأداة لأتمتة عمليات إعادة التأسيس/الدمج/السحب/الدفع

طورت شركة مايكروسوفت ملحق نظام الملفات الافتراضي لـ Git (VFS for Git؛ المعروف سابقًا باسم نظام الملفات الافتراضي لـ Git أو GVFS) للتعامل مع حجم شجرة الكود المصدر لنظام التشغيل Windows كجزء من انتقالها من Perforce في عام 2017. يسمح VFS for Git لمستودعات النسخ باستخدام عناصر نائبة يتم تنزيل محتوياتها بمجرد الوصول إلى ملف. [110]

الاتفاقيات

يمكن استخدام Git بعدة طرق مختلفة، ولكن يتم اعتماد بعض الاتفاقيات بشكل عام.

  • الأمر لإنشاء مستودع محلي، git init ، ينشئ فرعًا باسم master . [61] [111] وغالبًا ما يتم استخدامه كفرع تكامل لدمج التغييرات فيه. [112] ونظرًا لأن جهاز التحكم عن بعد الافتراضي في المنبع يسمى origin ، [113] فإن فرع التحكم عن بعد الافتراضي هو origin/master . تنشئ بعض الأدوات مثل GitHub وGitLab فرعًا افتراضيًا باسم main بدلاً من ذلك. [114] [115] كما يمكن للمستخدمين إضافة وحذف الفروع واختيار أي فرع للتكامل.
  • لا يتم استبدال الالتزامات المدفوعة بشكل عام، ولكن يتم إعادتها [116] عن طريق الالتزام بتغيير آخر يعكس التزامًا سابقًا. يمنع هذا الالتزامات المشتركة من أن تكون غير صالحة لأن الالتزام الذي تستند إليه غير موجود في الجهاز البعيد. إذا كانت الالتزامات تحتوي على معلومات حساسة، فيجب إزالتها، الأمر الذي يتضمن إجراءً أكثر تعقيدًا لإعادة كتابة التاريخ.
  • غالبًا ما يتم اعتماد سير عمل git -flow [117] واتفاقيات التسمية للتمييز بين السجلات غير المستقرة الخاصة بالميزات (feature/*)، والسجلات المشتركة غير المستقرة (develop)، والسجلات الجاهزة للإنتاج (main)، والتحديثات الطارئة للمنتجات الصادرة (hotfix).
  • طلب السحب ، المعروف أيضًا باسم طلب الدمج ، هو طلب من المستخدم لدمج فرع في فرع آخر. [118] [119] لا يوفر Git بحد ذاته طلبات سحب، ولكنها ميزة شائعة في خدمات Git السحابية. لا تختلف الوظيفة الأساسية لطلب السحب عن وظيفة مسؤول المستودع الذي يسحب التغييرات من جهاز بعيد آخر (المستودع الذي يعد مصدر طلب السحب). ومع ذلك، فإن طلب السحب نفسه عبارة عن تذكرة يديرها خادم الاستضافة الذي يقوم بهذه الإجراءات؛ إنه ليس ميزة من ميزات Git SCM.

حماية

لا يوفر Git آليات التحكم في الوصول، ولكنه مصمم للعمل مع أدوات أخرى متخصصة في التحكم في الوصول. [120]

في 17 ديسمبر 2014، تم اكتشاف ثغرة أمنية تؤثر على إصدارات Windows و macOS من عميل Git. يمكن للمهاجم تنفيذ تعليمات برمجية عشوائية على جهاز كمبيوتر مستهدف مثبت عليه Git عن طريق إنشاء شجرة Git ضارة (دليل) باسم .git (دليل في مستودعات Git يخزن جميع بيانات المستودع) في حالة مختلفة (مثل .GIT أو .Git، وهو أمر ضروري لأن Git لا يسمح بإنشاء إصدار كامل من .git بأحرف صغيرة يدويًا) مع ملفات ضارة في الدليل الفرعي .git/hooks (مجلد يحتوي على ملفات قابلة للتنفيذ يقوم Git بتشغيلها) على مستودع أنشأه المهاجم أو على مستودع يمكن للمهاجم تعديله. إذا قام مستخدم Windows أو Mac بسحب (تنزيل) إصدار من المستودع الذي يحتوي على الدليل الضار، ثم انتقل إلى هذا الدليل، فسيتم استبدال دليل .git (بسبب سمة عدم حساسية الأحرف الكبيرة والصغيرة لأنظمة الملفات في Windows وMac) وقد يتم تشغيل الملفات القابلة للتنفيذ الضارة في .git/hooks ، مما يؤدي إلى تنفيذ أوامر المهاجم. يمكن للمهاجم أيضًا تعديل ملف تكوين .git/config ، والذي يسمح للمهاجم بإنشاء أسماء مستعارة ضارة لبرنامج Git (أسماء مستعارة لأوامر Git أو الأوامر الخارجية) أو تعديل الأسماء المستعارة الموجودة لتنفيذ أوامر ضارة عند التشغيل. تم تصحيح الثغرة الأمنية في الإصدار 2.2.1 من Git، الذي تم إصداره في 17 ديسمبر 2014، وتم الإعلان عنه في اليوم التالي. [121] [122]

احتوى إصدار Git 2.6.1، الذي تم إصداره في 29 سبتمبر 2015، على تصحيح لثغرة أمنية (CVE-2015-7545) [123] سمحت بتنفيذ تعليمات برمجية عشوائية. [124] كانت الثغرة قابلة للاستغلال إذا تمكن المهاجم من إقناع الضحية باستنساخ عنوان URL معين، حيث تم تضمين الأوامر العشوائية في عنوان URL نفسه. [125] يمكن للمهاجم استخدام الثغرة عبر هجوم الوسيط إذا كان الاتصال غير مشفر، [125] حيث يمكنهم إعادة توجيه المستخدم إلى عنوان URL من اختيارهم. كانت الاستنساخات المتكررة أيضًا عرضة للخطر لأنها سمحت لوحدة التحكم في المستودع بتحديد عناوين URL عشوائية عبر ملف gitmodules. [125]

يستخدم Git تجزئات SHA-1 داخليًا. رد لينوس تورفالدس بأن التجزئة كانت في الغالب للحماية من الفساد العرضي، وأن الأمان الذي توفره التجزئة الآمنة تشفيريًا كان مجرد تأثير جانبي عرضي، حيث كان الأمان الرئيسي هو التوقيع في مكان آخر. [126] [127] منذ عرض هجوم SHAttered ضد git في عام 2017، تم تعديل git لاستخدام متغير SHA-1 مقاوم لهذا الهجوم. تتم كتابة خطة لانتقال وظيفة التجزئة منذ فبراير 2020. [128]

العلامة التجارية

"Git" هي علامة تجارية مسجلة لشركة Software Freedom Conservancy تحت US500000085961336 منذ 2015-02-03.

انظر أيضا

ملحوظات

  1. ^ GPL-2.0-only منذ 2005-04-11. بعض الأجزاء بموجب تراخيص متوافقة مثل LGPLv2.1 . [6]
  2. ^ abcdefghijklmnopqrs غير مدرج كخيار في هذا الاستطلاع

الاستشهادات

  1. ^ "المراجعة الأولية لـ ""git""، مدير المعلومات من الجحيم". GitHub . 8 أبريل 2005. مؤرشف من الأصل في 16 نوفمبر 2015. تم الاسترجاع 20 ديسمبر 2015 .
  2. ^ "Commit Graph". GitHub . 8 يونيو 2016. مؤرشف من الأصل في 20 يناير 2016. تم الاسترجاع 19 ديسمبر 2015 .
  3. ^ جونيو سي هامانو (7 أكتوبر 2024). "[إعلان] Git v2.47.0" . تم الاسترجاع في 8 أكتوبر 2024 .
  4. ^ "موقع Git". مؤرشف من الأصل في 9 يونيو 2022 . استرجاع 9 يونيو 2022 .
  5. ^ "Git Source Code Mirror". GitHub . مؤرشف من الأصل في 3 يونيو 2022 . تم الاسترجاع 9 يونيو 2022 .
  6. ^ "Git's LGPL license at github.com". GitHub . 20 مايو 2011. مؤرشف من الأصل في 11 أبريل 2016. تم الاسترجاع 12 أكتوبر 2014 .
  7. ^ "Git's GPL license at github.com". GitHub . 18 يناير 2010. مؤرشف من الأصل في 11 أبريل 2016. تم الاسترجاع 12 أكتوبر 2014 .
  8. ^ "Tech Talk: Linus Torvalds on git (at 00:01:30)". 14 مايو 2007. مؤرشف من الأصل في 20 ديسمبر 2015. تم الاسترجاع في 20 يوليو 2014 – عبر YouTube.
  9. ^ تشاكون وستراوب 2014، ص 29-31.
  10. ^ ab Torvalds, Linus (7 April 2005). "Re: Kernel SCM saga..." linux-kernel (Mailing list). مؤرشف من الأصل في 1 يوليو 2019. تم الاسترجاع في 3 فبراير 2017 ."لذا فأنا أكتب بعض النصوص لمحاولة تتبع الأمور بشكل أسرع كثيرًا."
  11. ^ ab Torvalds, Linus (10 يونيو 2007). "Re: fatal: dangerous inflate inconsistency". git (قائمة بريدية).
  12. ^ abcd Linus Torvalds (3 مايو 2007). Google tech talk: Linus Torvalds on git. حدث الحدث في 02:30. مؤرشف من الأصل في 28 مايو 2007. تم الاسترجاع في 16 مايو 2007 .
  13. ^ "تاريخ مختصر لـ Git". Pro Git (الطبعة الثانية). Apress. 2014. مؤرشف من الأصل في 25 ديسمبر 2015. تم الاسترجاع في 26 ديسمبر 2015 .
  14. ^ شاكون ، سكوت (24 ديسمبر 2014). برو جيت (الطبعة الثانية). نيويورك، نيويورك: أبريس . ص 29-30. رقم ISBN 978-1-4842-0077-3. تم أرشفة النسخة الأصلية في 25 ديسمبر 2015.
  15. ^ "استطلاع رأي مطوري Stack Overflow 2022". Stack Overflow . تم الاسترجاع في 4 أغسطس 2022 .
  16. ^ كريل، بول (28 سبتمبر 2016). "حروب مستودعات المؤسسات: جيثب في مقابل جيثلاب في مقابل بيتباكيت". إنفوورلد . تم الاسترجاع في 2 فبراير 2020 .
  17. ^ ab "github.com Competitive Analysis, Marketing Mix and Traffic". Alexa . مؤرشف من الأصل في 31 مارس 2013 . تم الاسترجاع 2 فبراير 2020 .
  18. ^ ab "sourceforge.net Competitive Analysis, Marketing Mix and Traffic". Alexa . مؤرشف من الأصل في 20 أكتوبر 2020 . تم الاسترجاع 2 فبراير 2020 .
  19. ^ ab "bitbucket.org Competitive Analysis, Marketing Mix and Traffic". Alexa . مؤرشف من الأصل في 23 يونيو 2017 . تم الاسترجاع 2 فبراير 2020 .
  20. ^ "gitlab.com Competitive Analysis, Marketing Mix and Traffic". Alexa . مؤرشف من الأصل في 30 نوفمبر 2017 . تم الاسترجاع 2 فبراير 2020 .
  21. ^ براون، زاك (27 يوليو 2018). "قصة أصل جيت". مجلة لينكس . مجلة لينكس. مؤرشف من الأصل في 13 أبريل 2020. تم الاسترجاع في 28 مايو 2020 .
  22. ^ "BitKeeper وLinux: نهاية الطريق؟". Linux.com . 11 أبريل 2005 . تم الاسترجاع في 18 مايو 2023 .
  23. ^ ماكاليستر، نيل (2 مايو 2005). "خطأ لينوس تورفالدس في برنامج BitKeeper". InfoWorld . مؤرشف من الأصل في 26 أغسطس 2015. تم الاسترجاع في 8 سبتمبر 2015 .
  24. ^ ab Torvalds, Linus (27 فبراير 2007). "Re: Trivia: متى قام git باستضافة نفسه؟". git (قائمة بريدية).
  25. ^ تورفالدس ، لينوس (6 أبريل 2005). "ملحمة Kernel SCM." Linux-kernel (القائمة البريدية).
  26. ^ Torvalds, Linus (17 أبريل 2005). "أول دمج حقيقي لنواة git على الإطلاق!". git (قائمة بريدية).
  27. ^ Mackall, Matt (29 أبريل 2005). "Mercurial 0.4b vs git patchbomb benchmark". git (قائمة بريدية).
  28. ^ Torvalds, Linus (17 يونيو 2005). "Linux 2.6.12". git-commits-head (قائمة بريدية).
  29. ^ Torvalds, Linus (27 يوليو 2005). "تعرف على المشرف الجديد". git (قائمة بريدية).
  30. ^ هامانو ، جونيو سي. (21 ديسمبر 2005). "أعلن: Git 1.0.0". بوابة (القائمة البريدية).
  31. ^ "GitFaq: لماذا اسم 'Git'؟". Git.or.cz. مؤرشف من الأصل في 23 يوليو 2012. تم الاسترجاع في 14 يوليو 2012 .
  32. ^ "بعد الجدل، بدأ تورفالدس العمل على 'git'". PC World . 14 يوليو 2012. مؤرشف من الأصل في 1 فبراير 2011. بدا تورفالدس مدركًا أن قراره بالتخلي عن BitKeeper سيكون أيضًا مثيرًا للجدل. عندما سُئل عن سبب تسميته للبرنامج الجديد، "git"، وهي لغة عامية بريطانية تعني "شخص فاسد"، قال. "أنا لقيط مغرور، لذلك أسمي جميع مشاريعي باسمي. أولاً لينكس، والآن git."
  33. ^ "git(1) Manual Page". مؤرشف من الأصل في 21 يونيو 2012. تم الاسترجاع في 21 يوليو 2012 .
  34. ^ "المراجعة الأولية لـ 'git'، مدير المعلومات من الجحيم · git/git@e83c516". GitHub . مؤرشف من الأصل في 8 أكتوبر 2017 . تم الاسترجاع 21 يناير 2016 .
  35. ^ "Git – Distributed Workflows". Git . مؤرشف من الأصل في 22 أكتوبر 2014 . تم الاسترجاع 15 يونيو 2020 .
  36. ^ Gunjal, Siddhesh (19 يوليو 2019). "ما هي أداة التحكم في الإصدار؟ استكشف Git وGitHub". Medium . تم الاسترجاع في 25 أكتوبر 2020 .
  37. ^ Torvalds, Linus (19 أكتوبر 2006). "Re: جدول مقارنة VCS". git (قائمة بريدية).
  38. ^ مدونة Jst حول Mozillazine "bzr/hg/git performance". مؤرشف من الأصل في 29 مايو 2010. تم الاسترجاع في 12 فبراير 2015 .
  39. ^ دراير، رولاند (13 نوفمبر 2006). "يا له من ارتياح". مؤرشف من الأصل في 16 يناير 2009.، مع ملاحظة أن "git log" أسرع بـ 100 مرة من "svn log" لأن الأخير يجب أن يتصل بخادم بعيد.
  40. ^ "Trust". Git Concepts . Git User's Manual. 18 أكتوبر 2006. مؤرشف من الأصل في 22 فبراير 2017.
  41. ^ Torvalds, Linus. "Re: VCS comparison table". git (Mailing list) . تم الاسترجاع في 10 أبريل 2009 .، يصف تصميم Git الموجه نحو البرامج النصية
  42. ^ iabervon (22 ديسمبر 2005). "Git rocks!". مؤرشف من الأصل في 14 سبتمبر 2016.، يشيد بقدرة Git على كتابة النصوص البرمجية.
  43. ^ "Git – Git SCM Wiki". git.wiki.kernel.org . تم الاسترجاع في 25 أكتوبر 2020 .
  44. ^ تشاكون وستراوب 2014.
  45. ^ "دليل مستخدم Git". 10 مارس 2020. مؤرشف من الأصل في 10 مايو 2020.
  46. ^ Chacon & Straub 2014، ص 499.
  47. ^ تشاكون وستراوب 2014، ص 33-34.
  48. ^ من "Git – Packfiles". Git .
  49. ^ Chacon & Straub 2014، ص 568.
  50. ^ Torvalds, Linus (10 أبريل 2005). "Re: المزيد من تحديثات git." linux-kernel (قائمة بريدية).
  51. ^ هايبل، برونو (11 فبراير 2007). "كيفية تسريع 'سجل git'؟". git (قائمة بريدية).
  52. ^ Torvalds, Linus (1 مارس 2006). "Re: إعادة تسمية غير نقية / تتبع التاريخ". git (قائمة بريدية).
  53. ^ هامانو، جونيو سي. (24 مارس 2006). "رد: أخطاء GITtifying GCC وBinutils". git (قائمة بريدية).
  54. ^ هامانو، جونيو سي. (23 مارس 2006). "رد: أخطاء GITtifying GCC وBinutils". git (قائمة بريدية).
  55. ^ Torvalds, Linus (28 نوفمبر 2006). "Re: git and bzr". git (قائمة بريدية).، عند استخدامه git-blameلإظهار الكود الذي تم نقله بين ملفات المصدر.
  56. ^ Torvalds, Linus (18 July 2007). "git-merge(1)". مؤرشف من الأصل في 16 يوليو 2016.
  57. ^ Torvalds, Linus (18 July 2007). "CrissCrossMerge". مؤرشف من الأصل في 13 يناير 2006.
  58. ^ Torvalds, Linus (10 أبريل 2005). "Re: المزيد من تحديثات git..." linux-kernel (قائمة بريدية).
  59. ^ Torvalds, Linus (23 مارس 2006). "Re: Errors GITtifying GCC and Binutils". git (قائمة بريدية). مؤرشف من الأصل في 22 مارس 2021. تم الاسترجاع في 3 فبراير 2017 .
  60. ^ "Git – Git Objects". Git .
  61. ^ من Chacon & Straub 2014، ص 81-83.
  62. ^ تشاكون وستراوب 2014، ص 485-488.
  63. ^ تشاكون وستراوب 2014، ص 488-490.
  64. ^ تشاكون وستراوب 2014، ص 495-496.
  65. ^ تشاكون وستراوب 2014، ص 497-501.
  66. ^ "Git – مراجع Git". Git .
  67. ^ "Git Cheat Sheet" (PDF) . education.github.com . تم الاسترجاع في 10 يونيو 2024 .
  68. ^ "Git Tutorial" (PDF) . web.stanford.edu . تم الاسترجاع في 10 يونيو 2024 .
  69. ^ "Git Quick Intro" (PDF) . data-skills.github.io . تم الاسترجاع في 10 يونيو 2024 .
  70. ^ با تران، أندرو. "أفضل الممارسات للتحميل إلى GitHub" (PDF) . journalismcourses.org . تم الاسترجاع في 10 يونيو 2024 .
  71. ^ "تنسيق ملف تكوين المشروع". مراجعة Gerrit Code . مؤرشف من الأصل في 3 ديسمبر 2020. تم الاسترجاع في 2 فبراير 2020 .
  72. ^ "التنزيلات". مؤرشف من الأصل في 8 مايو 2012. اطلع عليه بتاريخ 14 مايو 2012 .
  73. ^ "إصدارات حزمة git – Repology". مؤرشف من الأصل في 19 يناير 2022 . تم الاسترجاع 30 نوفمبر 2021 .
  74. ^ "msysGit". GitHub . مؤرشف من الأصل في 10 أكتوبر 2016. استرجاع 20 سبتمبر 2016 .
  75. ^ "Git – تنزيل الحزمة". Git .(المصدر الكود)
  76. ^ "JGit". مؤرشف من الأصل في 31 أغسطس 2012. اطلع عليه بتاريخ 24 أغسطس 2012 .
  77. ^ "Git – go-git". Git . تم الاسترجاع في 19 أبريل 2019 .
  78. ^ "واجهة SQL لمستودعات Git، مكتوبة بلغة Go"، github.com ، تم الاسترجاع في 19 أبريل 2019
  79. ^ "Keybase تطلق git المشفرة". keybase.io . تم الاسترجاع في 19 أبريل 2019 .
  80. ^ "Dulwich GitHub Repository README.md". GitHub . مؤرشف من الأصل في 29 أبريل 2024 . تم الاسترجاع 29 أبريل 2024 .
  81. ^ "libgit2". GitHub . مؤرشف من الأصل في 11 أبريل 2016 . تم الاسترجاع 24 أغسطس 2012 .
  82. ^ "rugged". GitHub . مؤرشف من الأصل في 24 يوليو 2013 . تم الاسترجاع 24 أغسطس 2012 .
  83. ^ "pygit2". GitHub . مؤرشف من الأصل في 5 أغسطس 2015 . تم الاسترجاع 24 أغسطس 2012 .
  84. ^ "hlibgit2". مؤرشف من الأصل في 25 مايو 2013. اطلع عليه بتاريخ 30 أبريل 2013 .
  85. ^ "js-git: a JavaScript implementation of Git". GitHub . مؤرشف من الأصل في 7 أغسطس 2013 . تم الاسترجاع في 13 أغسطس 2013 .
  86. ^ "لعبة الأشجار". gameoftrees.org . تم الاسترجاع في 10 مارس 2024 .
  87. ^ تشاكون وستراوب 2014، ص 138-139.
  88. ^ "Git – Git Daemon". Git . تم الاسترجاع في 10 يوليو 2019 .
  89. ^ 4.4 Git على الخادم – إعداد الخادم محفوظ في 22 أكتوبر 2014 على موقع Wayback Machine ، Pro Git.
  90. ^ "1.4 البدء – تثبيت Git". جيت. مؤرشف من الأصل في 2 نوفمبر 2013. استرجاع 1 نوفمبر 2013 .
  91. ^ Chacon, Scott; Straub, Ben (2014). "Git on the Server – Setting Up the Server". Pro Git (الطبعة الثانية). Apress. ISBN 978-1484200773.
  92. ^ دليل مستخدم الانتشار: استضافة المستودعات محفوظ في 20 سبتمبر 2020 على موقع Wayback Machine .
  93. ^ "Gitolite: استضافة مستودعات Git".
  94. ^ "Gogs: خدمة Git ذاتية الاستضافة غير مؤلمة".
  95. ^ "أبرز ما جاء في Git 2.26". مدونة GitHub . 22 مارس 2020. مؤرشف من الأصل في 22 مارس 2021. تم الاسترجاع في 25 نوفمبر 2020. قد تتذكر عندما قدم Git إصدارًا جديدًا من بروتوكول جلب الشبكة الخاص به في عام 2018. يتم استخدام هذا البروتوكول افتراضيًا الآن في 2.26، لذا دعنا نجدد أنفسنا بشأن ما يعنيه ذلك. تكمن أكبر مشكلة في البروتوكول القديم في أن الخادم كان يسرد على الفور جميع الفروع والعلامات والمراجع الأخرى في المستودع قبل أن تتاح الفرصة للعميل لإرسال أي شيء. بالنسبة لبعض المستودعات، قد يعني هذا إرسال ميغا بايت من البيانات الإضافية، عندما أراد العميل حقًا معرفة الفرع الرئيسي فقط. يبدأ البروتوكول الجديد بطلب العميل ويوفر طريقة للعميل لإخبار الخادم بالمراجع التي يهتم بها. سيسأل جلب فرع واحد فقط عن هذا الفرع، بينما ستسأل معظم النسخ المستنسخة فقط عن الفروع والعلامات. قد يبدو هذا كل شيء، ولكن مستودعات الخادم قد تخزن مراجع أخرى (مثل رأس كل طلب سحب مفتوح في المستودع منذ إنشائه). الآن، تتحسن سرعة عمليات جلب البيانات من المستودعات الكبيرة، خاصة عندما يكون الجلب نفسه صغيرًا، مما يجعل تكلفة الإعلان المرجعي الأولي أكثر تكلفة نسبيًا. وأفضل جزء هو أنك لن تحتاج إلى القيام بأي شيء! بفضل بعض التصميم الذكي، يمكن لأي عميل يتحدث البروتوكول الجديد العمل بسلاسة مع كل من الخوادم القديمة والجديدة، والعودة إلى البروتوكول الأصلي إذا كان الخادم لا يدعمه. كان السبب الوحيد للتأخير بين تقديم البروتوكول وجعله الافتراضي هو السماح للمتبنين الأوائل باكتشاف أي أخطاء.
  96. ^ "Git - git-gui Documentation". Git . تم الاسترجاع في 1 يوليو 2024 .
  97. ^ "Git - GUI Clients". Git . تم الاسترجاع في 1 يوليو 2024 .
  98. ^ "نتائج استطلاع مجتمع Eclipse لعام 2014 | إيان سكيريت". Ianskerrett.wordpress.com. 23 يونيو 2014. مؤرشف من الأصل في 25 يونيو 2014. تم الاسترجاع في 23 يونيو 2014 .
  99. ^ "نتائج استطلاع مجتمع Eclipse لعام 2012". eclipse.org. مؤرشف من الأصل في 11 أبريل 2016.
  100. ^ "مقارنة المستودعات – Open Hub". مؤرشف من الأصل في 7 سبتمبر 2014.
  101. ^ "Stack Overflow Annual Developer Survey". Stack Exchange, Inc. تم الاسترجاع في 9 يناير 2020. يُعد استطلاع Stack Overflow السنوي للمطورين هو أكبر استطلاع شامل للأشخاص الذين يقومون بالبرمجة في جميع أنحاء العالم. في كل عام، نجري استطلاعًا يغطي كل شيء من التقنيات المفضلة لدى المطورين إلى تفضيلاتهم الوظيفية. يصادف هذا العام العام التاسع الذي ننشر فيه نتائج استطلاع المطورين السنوي، وقد شارك ما يقرب من 90.000 مطور في الاستطلاع الذي استغرق 20 دقيقة في وقت سابق من هذا العام.
  102. ^ "Stack Overflow Developer Survey 2015". Stack Overflow. مؤرشف من الأصل في 4 مايو 2019. استرجاع 29 مايو 2019 .
  103. ^ "Stack Overflow Developer Survey 2017". Stack Overflow. مؤرشف من الأصل في 29 مايو 2019. استرجاع 29 مايو 2019 .
  104. ^ "Stack Overflow Developer Survey 2018". Stack Overflow. مؤرشف من الأصل في 30 مايو 2019. استرجاع 29 مايو 2019 .
  105. ^ "وظائف Git (البرمجيات)، متوسط ​​الراتب لمهارات نظام التحكم في الإصدارات الموزعة Git". Itjobswatch.co.uk. مؤرشف من الأصل في 8 أكتوبر 2016. تم الاسترجاع في 30 سبتمبر 2016 .
  106. ^ "وظائف Team Foundation Server، متوسط ​​الراتب لمهارات Microsoft Team Foundation Server (TFS)". Itjobswatch.co.uk. مؤرشف من الأصل في 29 أكتوبر 2016. تم الاسترجاع في 30 سبتمبر 2016 .
  107. ^ "وظائف Subversion، متوسط ​​الراتب لمهارات Apache Subversion (SVN)". Itjobswatch.co.uk. مؤرشف من الأصل في 25 أكتوبر 2016. تم الاسترجاع في 30 سبتمبر 2016 .
  108. ^ "Mercurial Jobs, Average Salary for Mercurial Skills". Itjobswatch.co.uk. مؤرشف من الأصل في 23 سبتمبر 2016. تم الاسترجاع في 30 سبتمبر 2016 .
  109. ^ "وظائف VSS/SourceSafe، متوسط ​​الراتب لمهارات Microsoft Visual SourceSafe (VSS)". Itjobswatch.co.uk. مؤرشف من الأصل في 29 أكتوبر 2016. تم الاسترجاع في 30 سبتمبر 2016 .
  110. ^ "انتقال Windows إلى Git يكاد يكون كاملاً: 8,500 عملية تحويل و1,760 عملية بناء كل يوم". Ars Technica . 24 مايو 2017. مؤرشف من الأصل في 24 مايو 2017 . تم الاسترجاع في 24 مايو 2017 .
  111. ^ "git-init". Git . مؤرشف من الأصل في 15 مارس 2022.
  112. ^ "Git – Branches in a Nutshell". Git . مؤرشف من الأصل في 20 ديسمبر 2020 . تم الاسترجاع في 15 يونيو 2020 . الفرع "الرئيسي" في Git ليس فرعًا خاصًا. إنه يشبه تمامًا أي فرع آخر. والسبب الوحيد لوجود فرع رئيسي في كل مستودع تقريبًا هو أن أمر git init ينشئه افتراضيًا ولا يكلف معظم الأشخاص أنفسهم عناء تغييره.
  113. ^ تشاكون وستراوب 2014، ص 103-109.
  114. ^ github/renaming, GitHub, 4 ديسمبر 2020 , تم الاسترجاع 4 ديسمبر 2020
  115. ^ اسم الفرع الافتراضي للمستودعات الجديدة أصبح الآن main، GitLab، 22 يونيو 2021 ، تم الاسترجاع في 22 يونيو 2021
  116. ^ "Git Revert | Atlassian Git Tutorial". Atlassian . تتمتع عملية التراجع بميزتين مهمتين مقارنة بإعادة الضبط. أولاً، لا تغير تاريخ المشروع، مما يجعلها عملية "آمنة" للتغييرات التي تم نشرها بالفعل في مستودع مشترك.
  117. ^ "Gitflow Workflow | Atlassian Git Tutorial". Atlassian . تم الاسترجاع في 15 يونيو 2020 .
  118. ^ تشاكون وستراوب 2014، ص 170-174.
  119. ^ "Forking Workflow | Atlassian Git Tutorial". Atlassian . تم الاسترجاع في 15 يونيو 2020 .
  120. ^ "Git repository access control". مؤرشف من الأصل في 14 سبتمبر 2016. اطلع عليه بتاريخ 6 سبتمبر 2016 .
  121. ^ Pettersen, Tim (20 ديسمبر 2014). "تأمين خادم Git الخاص بك ضد CVE-2014-9390". مؤرشف من الأصل في 24 ديسمبر 2014. تم الاسترجاع في 22 ديسمبر 2014 .
  122. ^ Hamano, JC (18 ديسمبر 2014). "[إعلان] Git v2.2.1 (وتحديثات لمسارات الصيانة القديمة)". مجموعة الأخبار : gmane.linux.kernel. مؤرشف من الأصل في 19 ديسمبر 2014. تم الاسترجاع في 22 ديسمبر 2014 .
  123. ^ "CVE-2015-7545". 15 ديسمبر 2015. مؤرشف من الأصل في 26 ديسمبر 2015. اطلع عليه بتاريخ 26 ديسمبر 2015 .
  124. ^ "Git 2.6.1". GitHub . 29 سبتمبر 2015. مؤرشف من الأصل في 11 أبريل 2016. اطلع عليه بتاريخ 26 ديسمبر 2015 .
  125. ^ abc Blake Burkhart; et al. (5 أكتوبر 2015). "Re: CVE Request: git". مؤرشف من الأصل في 27 ديسمبر 2015. تم الاسترجاع في 26 ديسمبر 2015 .
  126. ^ "hash – ما مدى أمان علامات git الموقعة؟ هل هي آمنة مثل SHA-1 أو أكثر أمانًا بطريقة ما؟". Information Security Stack Exchange. 22 سبتمبر 2014. مؤرشف من الأصل في 24 يونيو 2016.
  127. ^ "لماذا يستخدم Git دالة تجزئة تشفيرية؟". Stack Overflow. 1 مارس 2015. مؤرشف من الأصل في 1 يوليو 2016.
  128. ^ "Git – توثيق انتقال وظيفة التجزئة". Git .
  • الموقع الرسمي
يحتوي موقع Wikibooks على كتاب حول موضوع: Git
تحتوي ويكيميديا ​​كومنز على وسائط متعلقة بـ Git .
Retrieved from "https://en.wikipedia.org/w/index.php?title=Git&oldid=1253914341"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate