قفل الملفات الثنائية باستخدام نظام التحكم في إصدار git

Question

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

لتحقيق تأثيرات القفل، يجب تحديد مستودع "مركزي".بغض النظر عن الطبيعة الموزعة لـ git، سيكون لدى معظم الشركات مستودع "مركزي" لمشروع برمجي.يجب أن نكون قادرين على وضع علامة على الملف على أنه يتطلب قفلًا من مستودع git الحاكم على عنوان محدد.ربما يكون هذا صعبًا لأن git يتتبع محتويات الملف وليس الملفات؟

هل لدى أي منكم خبرة في التعامل مع ملفات git والملفات الثنائية التي يجب قفلها قبل التعديل؟

ملحوظة:يبدو أن مشروع التحكم في الإصدار الموزع الجديد مفتوح المصدر الخاص بـ Source Gear، Veracity، قد جعل القفل أحد أهدافه.

Answer 1

جيت LFS 2.0 أضاف دعمًا لقفل الملفات.

باستخدام Git LFS 2.0.0، يمكنك الآن قفل الملفات التي تعمل عليها بشكل نشط، مما يمنع الآخرين من الدفع إلى خادم Git LFS حتى تقوم بإلغاء تأمين الملفات مرة أخرى.

سيؤدي هذا إلى منع تعارضات الدمج بالإضافة إلى فقدان العمل على الملفات غير القابلة للدمج على مستوى نظام الملفات.على الرغم من أن هذا قد يبدو متعارضًا مع الطبيعة الموزعة والمتوازية لـ Git، إلا أن قفل الملفات يعد جزءًا مهمًا من العديد من عمليات سير عمل تطوير البرامج - خاصة بالنسبة للفرق الكبيرة التي تعمل مع الأصول الثنائية.

Answer 2

التخريب له أقفال، وهي ليست استشارية فقط.ويمكن تنفيذها باستخدام svn:needs-lock السمة (ولكن يمكن أيضًا كسرها عمدًا إذا لزم الأمر).إنه الحل الصحيح لإدارة الملفات غير القابلة للدمج.الشركة التي أعمل بها تخزن كل شيء تقريبًا في Subversion والاستخدامات svn:needs-lock لجميع الملفات غير القابلة للدمج.

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

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

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

وهنا قراءة مثيرة للاهتمام حول هذا الموضوع.

Answer 3

أوافق على أن قفل الملفات الثنائية يعد ميزة ضرورية لبعض البيئات.لقد فكرت للتو في كيفية تنفيذ ذلك، على الرغم من:

• لديك طريقة لوضع علامة على الملف على أنه "يحتاج إلى قفل" (مثل خاصية "svn:needs-lock").
• عند الخروج، سيضع git علامة على هذا الملف على أنه للقراءة فقط.
• أمر جديد git-lock سيتصل بخادم القفل المركزي الذي يعمل في مكان ما ليطلب الإذن بالقفل.
• إذا منح خادم القفل الإذن، فقم بوضع علامة على الملف للقراءة والكتابة.
• git-add سيبلغ خادم القفل بتجزئة محتوى الملف المقفل.
• سيراقب خادم القفل ظهور تجزئة المحتوى في التزام بالمستودع الرئيسي.
• عندما يظهر التجزئة، حرر القفل.

هذه فكرة غير مكتملة إلى حد كبير، وهناك ثغرات محتملة في كل مكان.كما أنه يتعارض مع روح git، ومع ذلك يمكن أن يكون مفيدًا بالتأكيد في بعض السياقات.

داخل مؤسسة معينة، ربما يمكن بناء هذا النوع من الأشياء باستخدام مجموعة مناسبة من أغلفة البرامج النصية وخطافات الالتزام.

Answer 4

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

وهذه بالفعل مشكلة محتملة.لذا تنتهي أليس أولاً وتدفع إلى المركز alice/update فرع.عادة، عندما يحدث هذا، ستقوم أليس بإصدار إعلان بضرورة مراجعته.يرى بوب ذلك ويراجعه.يمكنه إما (1) دمج تلك التغييرات بنفسه في نسخته (المتفرعة من alice/update وإجراء تغييراته على ذلك) أو (2) نشر تغييراته الخاصة على bob/update.مرة أخرى، يصدر إعلانًا.

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

نظرًا لأن (AFAIK) فإن أقفال Subversion هي مجرد نصائح استشارية، ويمكن أن يؤدي البريد الإلكتروني أو الرسالة الفورية نفس الغرض.ولكن حتى لو لم تفعل ذلك، فإن Git يتيح لك إصلاح الأمر.

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

Answer 5

لقد بدأنا مؤخرًا في استخدام Git (استخدمنا Subversion سابقًا) ولقد وجدت تغييرًا في سير العمل قد يساعد في حل مشكلتك، دون الحاجة إلى الأقفال.إنه يستفيد من كيفية تصميم git ومدى سهولة الفروع.

في الأساس، يتلخص الأمر في الدفع إلى فرع غير رئيسي، وإجراء مراجعة لذلك الفرع، ثم الدمج في الفرع الرئيسي (أو أيًا كان الفرع المستهدف).

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

users/a/feature1
users/a/feature2
users/b/feature3
teams/d/featurey

لا تتردد في استخدام الهيكل الخاص بك.لاحظ أنني أعرض أيضًا فروع المواضيع، وهي لغة git شائعة أخرى.

ثم في الريبو المحلي للمستخدم أ:

feature1
feature2

ولإيصاله إلى الخادم المركزي (الأصل):

git push origin feature1:users/a/feature1

(ربما يمكن تبسيط ذلك من خلال تغييرات التكوين)

على أي حال، بمجرد مراجعة الميزة 1، أيًا كان المسؤول (في حالتنا، هو مطور الميزة، يمكن أن يكون لديك مستخدم واحد مسؤول عن عمليات الدمج لإتقانها)، يقوم بما يلي:

git checkout master
git pull
git merge users/name/feature1
git push

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

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

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

Answer 6

عندما كنت أستخدم Subversion، قمت بتعيين ملف svn:needs-lock خاصية على جميع الملفات الثنائية وحتى الملفات النصية التي يصعب تحريرها.أنا أبداً شهدت فعلا أي صراعات.

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

شيء آخر قمت به هو استبدال العديد من التنسيقات الثنائية بتنسيقات نص عادي.أستخدم reStructuredText أو LaΤ_ΕΧ بدلاً من Word، وCSV بدلاً من Excel، وASCII-Art بدلاً من Visio، وYAML بدلاً من قواعد البيانات، وSVG بدلاً من OO Draw، وabc بدلاً من MIDI، وما إلى ذلك.

Answer 7

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

Answer 8

لقد ناقشت هذه المشكلة في مجموعات مناقشة git وخلصت إلى أنه يوجد حاليًا لا طريقة متفق عليها لقفل الملفات المركزي لـ git.

Answer 9

يدعم TortoiseGit سير عمل git الكامل لمستندات Office التي تفوض الاختلافات إلى Office نفسه.يعمل أيضًا على التفويض إلى OpenOffice لتنسيقات OpenDocument.

Answer 10

لا أتوقع أن يصبح قفل الملفات ميزة في git على الإطلاق.ما نوع الملفات الثنائية التي تهتم بها في المقام الأول؟هل أنت مهتم بالفعل بقفل الملفات، أو مجرد منع التعارضات الناجمة عن عدم القدرة على دمجها.

يبدو أنني أتذكر شخصًا يتحدث (أو حتى ينفذ) الدعم لدمج مستندات OpenOffice في git.

Answer 11

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

Answer 12

كل ما عليك فعله هو وضع ملف نصي في نسخة cc مع الملف الذي تريد قفله ثم جعل رابط التحديث يرفضه.

Answer 13

قد يكون صحيحًا أن إعادة تنظيم المشروع يمكن أن تساعد في تجنب الأقفال، ولكن:

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

إن المطالبة بأن تقوم شركة بأكملها بإعادة تنظيم سير عملها واستبدال جميع أدواتها التي تنتج الثنائيات، فقط لتتمكن من العمل مع git، بسبب عدم وجود أقفال، يبدو غير فعال تمامًا.

لا تتناسب الأقفال مع فلسفة git (التي لم يتم إنشاؤها مطلقًا للثنائيات)، ولكن هناك مواقف لا يمكن إهمالها، حيث تكون الأقفال هي الطريقة الأكثر فعالية لحل مثل هذه المشكلة.

Answer 14

هذا ليس حلاً ولكنه تعليق على سبب الحاجة إلى آليات القفل.هناك بعض الأدوات المستخدمة في بعض المجالات التي تستخدم التنسيقات الثنائية فقط والتي تعد مهمة بالغة الأهمية و"استخدام أدوات أفضل/مختلفة" ليس خيارًا.لا توجد أدوات بديلة قابلة للتطبيق.الأشخاص الذين أعرفهم حقًا لن يكونوا مرشحين للدمج حتى لو قمت بتخزين نفس المعلومات بتنسيق ascii.أحد الاعتراضات التي سمعتها هو أنك تريد أن تكون قادرًا على العمل دون اتصال بالإنترنت.الأداة المحددة التي أفكر فيها لا تعمل في وضع عدم الاتصال على أي حال بسبب الحاجة إلى سحب التراخيص، لذلك إذا كانت لدي بيانات على جهاز كمبيوتر محمول، فلا يبدو الأمر وكأنني أستطيع تشغيل الأداة أثناء وجودي في القطار على أي حال.ومع ذلك، ما الذي توفره git إذا كان اتصالي بطيئًا، يمكنني الحصول على تراخيص وسحب التغييرات أيضًا ولكن لدي نسخة محلية سريعة للنظر في الإصدارات المختلفة.وهذا شيء جميل يقدمه لك DVCS حتى في هذه الحالة.

وجهة نظر واحدة هي أن git ليس ببساطة الأداة التي يمكن استخدامها ولكنه جيد لجميع الملفات النصية التي تتم إدارتها أيضًا ومن المزعج الحاجة إلى أدوات مختلفة للتحكم في الإصدار لملفات مختلفة.

إن أسلوب تقديم المشورة والقفل عبر البريد أمر كريه حقًا.لقد رأيت ذلك وتعبت من التدفق اللامتناهي من رسائل البريد الإلكتروني مثل "أنا أقوم بتحريره" و"لقد انتهيت من التحرير" وشاهدت التغييرات المفقودة بسبب ذلك.الحالة الخاصة التي أفكر فيها هي الحالة التي كان من الممكن أن تكون فيها مجموعة من ملفات ascii الأصغر حجمًا أجمل بكثير ولكن هذا جانبًا.

Answer 15

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

Answer 16

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

إذا كانت مؤسستك تتطلب بيئة جماعية (عادةً لتجريد المطورين من الأمان الوظيفي)، فاستخدم svn، git ليس مناسبًا لك.يوفر Svn التحكم في المصدر والتواصل بين المطورين حول الأقفال.

Answer 17

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