git deps
1.0.0
git-deps هي أداة لإجراء التحليل التلقائي للتبعيات بين الالتزامات في مستودع GIT. إليك مظاهرة Screencast:
لقد قمت بالتدوين حول git-deps والأدوات ذات الصلة ، وأيضًا تحدثت علنًا عن الأداة عدة مرات:
من الواضح إلى حد ما أنه يمكن اعتبار اثنين من GIT داخل ريبو واحد "مستقلة" من بعضها البعض بمعنى ما ، إذا لم يغيروا نفس الملفات ، أو إذا لم يغيروا أجزاء متداخلة من نفس الملف (الملفات).
على النقيض من ذلك ، عندما يغير الالتزام خط ما ، فإنه "يعتمد" ليس فقط على الالتزام الذي غير هذا الخط الأخير ، ولكن أيضًا أي ارتكاب مسؤول عن توفير الخطوط المحيطة بالسياق ، لأنه بدون تلك الإصدارات السابقة من الخط وسياقه ، قد لا ينطبق Diff الالتزام بشكل نظيف (اعتمادًا على كيفية تطبيقه ، بالطبع). لذلك ، يمكن استنتاج جميع تبعيات الالتزام برمجيًا عن طريق تشغيل الدولارات على السطور ، بالإضافة إلى أن العديد من خطوط السياق منطقية بالنسبة لحالة استخدام تحليل التبعية هذا.
لذلك يتأثر حساب التبعية بمعلمة عامل "الزغب" (تصحيح CF (1)) ، أي عدد خطوط السياق التي تعتبر ضرورية لتنفيذ Diff الالتزام بشكل نظيف.
كما هو الحال مع العديد من علاقات التبعية ، تشكل هذه التبعيات حواف في DAG (الرسم البياني الموجه) التي تتوافق عقدها مع الالتزامات. لاحظ أن العقدة يمكن أن تعتمد فقط على مجموعة فرعية من أسلافها.
من المهم أن ندرك أن أي رسم بياني تبعية مستخلص بواسطة git-deps قد يكون غير مكتمل بشكل دلالي ؛ على سبيل المثال ، لن يتم التبعيات للكشف التلقائي بين الالتزام A الذي يغير رمزًا ويلتمًا آخر ب الذي يغير الوثائق أو الاختبارات لتعكس تغييرات الكود في الالتزام A. لا ينبغي استخدام git-deps بالإيمان الأعمى. لمزيد من التفاصيل ، راجع القسم الخاص بالنص مقابل الاعتماد الدلالي (في) أدناه.
في بعض الأحيان يكون من المفيد فهم طبيعة أجزاء من هذا الرسم البياني التبعي ، حيث أن طبيعتها ستؤثر على نجاح أو فشل العمليات بما في ذلك الدمج ، Rebase ، خيار الكرز وما إلى ذلك ، يرجى الاطلاع على ملف USE-CASES.md .
يرجى الاطلاع على ملف INSTALL.md .
يرجى الاطلاع على ملف USAGE.md .
سوف يلاحظ القراء الأذكياء أن الاستقلال النصي الذي تم اكتشافه بواسطة git-deps ليس هو نفسه الاستقلال الدلالي / المنطقي. الاستقلال النصي يعني أنه يمكن تطبيق التغييرات بأي ترتيب دون تكبد تعارضات ، ولكن هذا ليس مؤشرًا موثوقًا بالاستقلال المنطقي.
على سبيل المثال ، كان هناك تغيير في وظيفة وتغييرات مماثلة للاختبارات و/أو الوثائق لتلك الوظيفة في ملفات مختلفة. لذا ، إذا كانت هذه التغييرات في ارتباطات منفصلة داخل فرع ، فإن تشغيل git-deps على الالتزامات لن يكتشف أي اعتماد بينها على الرغم من أنها مرتبطة بشكل منطقي ، لأن التغييرات في ملفات مختلفة (أو حتى في مناطق مختلفة من نفس الملفات) مستقلة من النصي.
لذلك في هذه الحالة ، لن تتصرف git-deps بالضبط كيف نريد. وطالما أن الذكاء الاصطناعى يمثل مشكلة لم يتم حلها ، فمن غير المرجح أن يطور سلوكًا موثوقًا به تمامًا. فهل هذا يعني أن git-deps عديمة الفائدة؟ بالتأكيد لا!
أولاً ، عندما يتم الالتزام بأفضل الممارسات للهيكل الالتزام ، ينبغي وضع التغييرات المرتبطة بشكل منطقي بقوة في نفس الالتزام على أي حال. لذلك في المثال أعلاه ، يجب أن يكون التغيير إلى وظيفة وتغييرات مماثلة للاختبارات و/أو الوثائق لتلك الوظيفة ضمن التزام واحد. (على الرغم من أن هذا ليس هو النهج الوحيد الصحيح ؛ بالنسبة لآلية تجميع تاريخية أكثر تقدماً ، انظر git-dendrify .)
ثانياً ، في حين أن الاستقلال النصي لا يعني الاستقلال المنطقي ، فمن المتوقع أن يكون العكس أكثر شيوعًا: الاستقلال المنطقي غالبًا ما ينطوي على الاستقلال النصي (أو ذكر بطريقة أخرى ، فإن الاعتماد على النص ينطوي غالبًا على الاعتماد المنطقي). لذا ، على الرغم من أنه قد لا يكون من غير المألوف جدًا أن تفشل في الكشف عن التبعية بين التغييرات المتعلقة منطقياً ، git-deps أنه يجب أن يكون نادرًا أنه يبعث بشكل غير صحيح على التبعية بين التغييرات غير ذات الصلة منطقيًا. بمعنى آخر ، من المتوقع عمومًا أن تكون سلبياته الخاطئة أكثر شيوعًا من إيجابياتها الخاطئة. نتيجة لذلك ، من المحتمل أن تكون أكثر فائدة في تحديد الحد الأدنى على التبعيات من الحد الأعلى. بعد قولي هذا ، هناك حاجة إلى مزيد من البحث في هذا الشأن.
ثالثًا ، غالبًا ما يكون من غير المفيد السماح بالسعي إلى الكمال أن يصبح عدو الخير - لا يجب أن تكون الأداة مثالية لتكون مفيدة ؛ يجب أن يكون أفضل فقط من أداء نفس المهمة بدون الأداة.
يمكن العثور على مزيد من النقاش حول بعض هذه النقاط في موضوع قديم من القائمة البريدية GIT.
في نهاية المطاف ، "الدليل موجود في الحلوى" ، لذا جربه وانظر!
يرجى الاطلاع على ملف CONTRIBUTING.md .
يرجى الاطلاع على ملف HISTORY.md .
شكر خاص لـ SUSE لرعاية تطوير هذا البرنامج جزئيًا. شكرًا أيضًا لكل من ساهم في الكود وتقارير الأخطاء وغيرها من التعليقات.
تم إصداره بموجب الإصدار 2 GPL من أجل أن أكون متسقًا مع ترخيص git ، لكنني منفتح على فكرة الترخيص المزدوج إذا كان هناك سبب مقنع.
