حصلت من الداخل: مقدمة (ترجمة)

مرحبا يا هبر! أقدم إليكم ترجمة المقال "Git for Computer Scientists" للمخرج تومي فيرتانين.

حصلت داخل الداخل: مقدمة

من نفسي: قرأت بشكل دوري مقالات حول كيفية ترتيب مختلف التقنيات الشعبية تحت الغطاء ، صادفت هذه المادة . بدا المقال مثيرًا للاهتمام بسبب وجود مخططات بسيطة ومفهومة ، والتي يُنظر إليها على أنها أفضل بكثير من أوراق النص الممل. قررت أن تترجم إلى الروسية. الصور مأخوذة من الأصل.

من سيكون مهتمًا وربما مفيدًا: الأشخاص الذين يعملون مع Git يوميًا (أي كل ثانية ، إن لم يكن أول مطور برامج) ، والذين يريدون فهم آلية عمله بشكل أفضل.

ملاحظة: لفهم أفضل للمقال ، ينبغي أن يكون لدى الفرد فكرة عن مثل هذا الوحش مثل رسم بياني موجه (DAG) .

تخزين الأشياء

مستودع كائن Git هو ، بالمعنى الأولي للكلمة ، DAG يحتوي على أنواع مختلفة من الكائنات. يتم تخزين الكائنات في شكل مضغوط وتحديدها بواسطة تجزيئات SHA-1 (هذه ليست تجزئة لمحتويات الملف الذي يمثل الكائن ، ولكن للعرض الخاص به في Git).

سائل

Blob هو كائن بسيط ، مجرد مجموعة من وحدات البايت. يمكن أن يكون ملفًا أو رابطًا رمزيًا أو أيًا كان. يتم تحديد الدلالات حسب الكائن الذي يشير إلى هذه النقطة.

شجرة (شجرة)

تصف الكائنات من النوع "شجرة" الدلائل (الدلائل). يمكنهم الإشارة إلى النقط التي تخزن محتويات الملفات ، وكذلك الأشجار الأخرى ، وبالتالي إنشاء بنية دليل فرعي.

إذا كانت عقدة تشير إلى عقدة أخرى في DAG ، فإنهم يقولون إن ذلك يعتمد على هذه العقدة ، أي لا يمكن أن توجد بدونها. يمكن حذف العقد الموضحة بالعقدة باستخدام مجموعة البيانات المهملة (أمر git gc ) ، أو استعادتها باستخدام الأمر git fsck --lost-found .

ارتكب

يشير الالتزام إلى شجرة تمثل حالة الملفات في Git وقت إنشاء الالتزام. أيضًا ، يمكن أن يشير الالتزام إلى الالتزامات الأخرى التي يمثلها والديه:

• إذا كان الالتزام يحتوي على أكثر من أصل واحد ، فهذا يعني أنه يصف عملية الدمج (دمج)
• إذا لم يكن للالتزام والدين ، فهذا هو ما يسمى بالالتزام الأولي (الأولي) (أي الأول في المستودع)
• قد تكون هناك أيضًا حالات عندما يكون هناك أكثر من التزام أولي في المستودع - وهذا يعني عادةً دمج مستودعين منفصلين

نص كائن الالتزام هو رسالة الالتزام .

المراجع (الروابط)

تشبه الارتباطات (أو العناوين ، أو الفروع) الملصقات التي تحتوي على ملاحظات تم لصقها على عقد DAG أو نوع من الملاحظات أو الإشارات المرجعية - "أنا أعمل هنا". على عكس العقد DAG ، التي لا يمكن تغييرها ، ويمكن إضافتها فقط ، يمكن نقل الروابط كما تريد. لا يتم تخزينها في السجل ولا يتم نقلها مباشرة بين المستودعات.

يضيف أمر git الالتزام عقدة جديدة إلى DAG وينقل إشارة مرجعية إليها للفرع الحالي.

توجد الروابط في مساحة اسم الرؤوس / الفرع ، ولكن يمكن حذف جزء من الرؤوس .

ارتباط HEAD منفصل - لا يشير إلى عقدة ، ولكن إلى رابط آخر - هذا مؤشر على الفرع النشط الحالي.

الحكام عن بعد

هذه ، بشكل تقريبي ، ملصقات ذات لون مختلف. الفرق هو أن الارتباطات البعيدة موجودة في مساحة اسم مختلفة ويتم إدارتها أيضًا بواسطة خادم بعيد. لتحديثها ، استخدم الأمر git fetch .

العلامة (علامة)

العلامة عبارة عن مزيج من عقدة DAG ولصق (لون آخر). تشير العلامة إلى الالتزام ، وتتضمن رسالة اختيارية وتوقيع GPG. الملصق (الرابط) هو وسيلة بسيطة للوصول إلى العلامة ، وفي حالة الفقد ، يمكن استعادتها باستخدام الأمر git fsck - المفقود .

وبالتالي ، فإن مستودع Git عبارة عن مزيج من DAG والروابط.

القصة

الآن ، ومعرفة كيفية تخزين Git لتاريخ الإصدار ، دعونا نحاول تصوير العمليات المختلفة ، وكذلك فهم كيف يختلف Git عن الأنظمة التي تمثل التاريخ كتغييرات خطية لكل فرع.

مستودع أبسط. قمنا فقط بنسخ ( git clone ) المستودع البعيد مع التزام واحد.

هنا نقرأ ( git fetch ) المستودع البعيد وحصلنا على التزام جديد ، لكننا لم ندمجه مع فرعنا بعد.

إليك ما يحدث بعد تشغيل الأمر git merge عن بعد / MYSERVER / master . نظرًا لأنه تم تنفيذ الدمج سريعًا للأمام (لم تكن هناك عمليات ارتكاب محلية في فرعنا المحلي) ، حدث ما يلي: تم تغيير ملفات نسخة العمل الخاصة بنا ، كما تم نقل المؤشر إلى الفرع.

تشغيل git ارتكاب محليًا ثم git fetish . الآن لدينا كل من الالتزام المحلية والبعيدة. من الواضح ، تحتاج إلى دمج .

هذا هو نتيجة git merge remotes / MYSERVER / master command. نظرًا لأن لدينا التزامًا محليًا ، فهذا ليس سريعًا للأمام ، ويتم إنشاء التزام منفصل للدمج في DAG. إشعار - لديه التزام الوالدين 2.

هذه هي الطريقة التي ستعتني بها شجرتنا بالعديد من العمليات ، في كلا الفرعين (محليين وبعيدين) + دمج. يمكنك أن ترى بوضوح كيف يلتقط Git DAG التاريخ الكامل لأعمالنا.

ومع ذلك ، من الصعب قراءة هذه القصة. إذا لم تكن قد قمت بنشر الفرع الخاص بك حتى الآن ، أو كنت تتفق مع أعضاء الفريق الآخرين على ألا يقوموا بالبناء عليه في عملهم ، فلديك بديل: يمكنك إعادة التسجيل لفرعك . في هذه الحالة ، يتم استبدال الالتزام الخاص بك بالتزام آخر ، مع أصل مختلف ، ينتقل إليه أيضًا ارتباط الفرع.

في هذه الحالة ، ستبقى الالتزامات القديمة في DAG حتى تجميع البيانات المهملة. من حيث المبدأ ، هذا نوع من التأمين ، في حالة حدوث خطأ ما. إذا كان لا يزال لديك ارتباطات بالالتزام القديم ، فسيتم حفظها طالما كانت الروابط موجودة.

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

إليك كيفية العناية بجمع البيانات المهملة (أو تجاهل الالتزامات التي يتعذر الوصول إليها) ، وإنشاء التزام جديد أعلى الفرع الذي تم تطبيق rebase عليه.

أيضًا ، مع rebase ، يمكنك نقل تعهدات متعددة في نفس الوقت.

هذا كل شيء. آمل أن تكون المادة مفيدة.