ما هو "البيع"؟

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

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

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

الأشياء التي تتوقعها من نظام بائع جيد التصميم (بغض النظر عن Git it is or not):

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

وبالنظر إلى طبيعة بوابة Git ، فأنت تريد أن يكون هذا النظام صديقًا للفرع. إذا كان الفرع A يحتوي على رمز مُباع في الإصدار a1 والفرع B في الإصدار b1 ، فأنت تريد التبديل بينهما في كل مرة تقوم فيها بالتبديل بين A و B. وعلاوة على ذلك ، فأنت تريد أن تكون قادرًا على تغيير الإصدار من a1 إلى a2 ، والإصدار b1 إلى B2 دون قلق بشأن الإصدارات في فرع آخر.

... وتريد أن تكون قادرًا على بيع أكثر من مستودع خارجي ، لذلك لا ينبغي أن يكون البائع حدثًا لمرة واحدة لكل ريبو.

كما ترون انها قائمة طويلة من المتطلبات. لقد قمت بتحليل الحلول الحالية (الأخرى) قبل الوصول إلى أفضل الحلول (بائع git).

نسخ لصق

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

جيت في بوابة

هذه خدعة غبية ولكنها تعمل إلى حد ما. قم بإنشاء مجلد vendored_foobar في المستودع الخاص بك ، وانتقل إلى vendored_foobar واستنساخ foobar. عد إلى المستوى الأعلى وارتكب كل التغييرات التي لديك.

الايجابيات: بسيطة للقيام ، وتوفير الأصل المحلي ، والحكم و patchablity ممتازة.

السلبيات: إنه هش ، لا ينجو من الدفع (لم يتم تضمين مجلد git المتداخل في الريبو الخاص بك ، لذلك بالنسبة للمراقبين الخارجيين ، لا يمكن تمييز الشفرة التي تم بيعها عنك). لذلك سوف تفقد قابلية النقل ، ومصدر في المدى الطويل.

وحدات فرعية

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

ولا تنسى مدى صعوبة استنساخ هذا الريبو.

بوابة الشجرة

يمكن لـ Git استخدام طريقة "الشجرة الفرعية" لدمج البوابات الخارجية كمجلدات في مستودع git المحلي. إنه مثالي تقريبًا ، باستثناء التحديث ، التكرار ، والأصل ، والرؤية. باستثناء الحفر اليدوي في سجل git ، من المستحيل معرفة أي جزء من git repo يتم بيعه وهو ليس كذلك. وليس لديك أي فكرة عن مصدر هذه التغييرات. إذا لم يكتب committer ذلك ، فستفقد المعلومات. وإذا كان لديه / لا ، فإنه غير قابل للتكرار حيث يمكن أن تحدث تغييرات بسيطة أثناء ملء هذه المعلومات.

لذلك ، أدخل الفائز الفائز ، بائع git.

بائع بوابة

يعد Git vendor امتدادًا مدهشًا لـ git كتبها Brett Langdon منذ حوالي ثلاث سنوات. إنه ما يقرب من 200 سطر في bash ، لكنه مكتوب بشكل جيد بحيث لا أشعر بأي شكوى على الإطلاق (يحتوي على كل شيء يجب أن يحتوي عليه البرنامج الجيد: الصفحات اليدوية ، والمساعدة ، وإكمال bash ، ومعالجة الأخطاء المعقولة ، والحماية من الفشل).

يستخدم git subtree ويمدها مع وظائف لتغطية الجوانب الفضفاضة من البائع بواسطة git subtree.

يتم فحص كل نقطة مهمة:

وضوح. فقط اتصل git vendor list وشاهد كل الأشياء المباعة.
الأصل. فإنه يظهر الريبو عن بعد ويسمح لمعرفة ما تم بيعه الالتزام.
التحديث. git vendor update ، وهو يدعم للفروع والعلامات ويلتزم كوسيلة دبوس نقطة بالضبط ما يجب اتخاذها. ويمكنك أن تفعل git vendor remove ، بطبيعة الحال.
التكرار. لا توجد عمليات تشغيل يدوي ، لذلك سيحصل الجميع على نفس النتيجة عند البيع الأولي أو متابعة التحديثات.
قابلية النقل. يتم تخزين جميع التغييرات كعلامات خاصة في سجل git ، لذلك فهي سهلة الدفع / السحب. وهم يعملون بشكل رائع مع الفروع وتاريخ الخروج التعسفي.
govenrance. يتم تخزين جميع التعليمات البرمجية المباعة داخل الريبو الخاص بك.
patchability. إنه (ستشاهد دمجًا واضحًا يتعارض مع تغييراتك) ، لكنه الجانب الأضعف لبائع git. أفضل الحصول على "قائمة انتظار التصحيح" (كما هو الحال في debian / pathes لحزم deb) ، ولكن مع ذلك ، يوجد حد أدنى من الدعم لذلك.

لديه سياسة محددة حول كيفية بيع الأشياء: إذا كنت ترغب في استنساخ https://github.com/serverscom/dibctl فإنه يذهب إلى vendor/github.com/serverscom/dibctl/ . يمكنك تغيير جزء " vendor/ " ، ولكن الباقي هو سياسة صعبة. Symlinks يمكن أن أسهل ، على الرغم من.

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

الخاتمة

git-vendor هو أداة مثالية لبائع repo git إلى آخر. يوفر جميع الوظائف المطلوبة لأفضل ممارسات البيع: الحفاظ على الأصل ، وتوفير الرؤية والتحديث.

كيفية بائع بوابة في بوابة أخرى