سير العمل في الفريق

كيف تصل تغييرات الواجهة البرمجية من الخادم إلى فريق الويب عبر Git، من أول تعديل في الواجهة حتى تكامل موثّق.

شاهد هذا في الشرح: تغيير في الخلفية، من أليس إلى بوب (7:33)
التعاون عبر Git

تغيير واحد في الـ API، من الخلفية إلى الواجهة.

حزمة التغيير تنتقل مع الكود، عبر مستودع Git الذي يستخدمه فريقك بالفعل. تابع عملية تسليم حقيقية خطوة بخطوة.

  1. مطوّر الخلفية
  2. Getman
  3. Git
  4. مطوّر الواجهة
  5. وكيل البرمجة
  1. في Shop API، تعيد أليس تسمية الحقل total إلى totalCents وتضيف currency إلى GET /orders/{id}، ثم تحدّث الطلب المحفوظ في Getman.

  2. يقارن Getman عقد OpenAPI 3.1 بالنسخة السابقة. الحقول الجديدة تغيير غير كاسر. أما حذف total فيُصنَّف «قد يكون كاسرًا»، لأن مخطط تلك الاستجابة استُنتج من الأمثلة، وهو دليل ضعيف.

  3. من Changes ثم New change package. تسجّل الحزمة نقطة النهاية وفروق العقد والأمثلة وملاحظة الترحيل: اقرأ totalCents (بالسنتات) وcurrency؛ الحقل total لم يعد موجودًا. ومرجعها GT-SHOP-001.

  4. الزر Verify now يشغّل الطلبات المتأثرة على الـ API العامل، وتُسجَّل النتيجة في الحزمة. لا أحد يكتب «نجح» بيده.

  5. تودِع أليس الكود ومجلد getman/‎ معًا في commit واحد ثم تدفعه. لا يوجد خادم لـ Getman في الطريق.

  6. يضغط بوب Fetch، فيقرأ Getman الـ commits الواردة ويعرض الحزمة قبل أن يسحبها.

  7. بما أن I integrate as مضبوط على web، تصل الحزمة إلى صندوق بوب مع درجة خطورتها ودليل التحقق.

  8. يعطي بوب وكيل البرمجة المرجع فقط. عبر MCP يستدعي الوكيل list_changes ثم get_change ويقرأ الفروق والأمثلة.

  9. يحدّث الوكيل عميل الويب واختباراته في مستودع بوب، مستعينًا بأمثلة الحزمة.

  10. الأداة report_integration تشغّل الطلبات أولًا، ولا تقبل الحالة verified إلا بتشغيل ناجح على العقد الحالي. وبعد السحب، ترى أليس Integration verified.

كل ما سبق يجري على جهازَي حاسوب ومستودع Git بعيد واحد. لا توجد خدمة سحابية لـ Getman.

تتبع هذه الصفحة تغييرًا واحدًا في الواجهة البرمجية، من المطوّرة الخلفية Alice إلى مطوّر الويب Bob. يعمل كل منهما في نسخته المحلية من المستودع نفسه، ويحمل Git التغيير بينهما. لا يحتاج الأمر إلى مستند تسليم.

قبل البدء

  • Git وGetman وNode.js 20 أو أحدث لسطر الأوامر.
  • مستودع يحتوي على مجلد getman/. راجع صفحة البدء إذا كنت بحاجة إلى إعداده.
  • اسمك كمستهلك. يستخدم مطوّر الويب الاسم web، ويستخدم مطوّر الخادم الاسم الذي اتفق عليه الفريق.

فتح مساحة عمل الفريق من نسخة جديدة

استنسخ المستودع، ثم افتح مجلد getman في Getman.

  1. استنسخ المستودع كالمعتاد.
  2. في Getman، اختر Open a team workspace من شاشة الترحيب. يمكنك أيضًا استخدام Open team workspace… من قائمة شريط العنوان، أو من لوحة الأوامر (⌘K).
  3. اختر مجلد getman داخل نسختك المستنسخة. هو المجلد الذي يحتوي على getman.yaml.
  4. افتح Environments وأدخل قيم الأسرار مرة واحدة. تُخفى القيم، وتُخزَّن في سلسلة المفاتيح لنظامك، ولا تُكتب في Git أبدًا.

لربط مشروع أنشأته بنفسك، افتح Project settings، ثم انتقل إلى Team sync، واختر Choose folder. اختر مجلدًا داخل المستودع.

تغيير الخادم (Alice)

  1. غيّر الواجهة البرمجية. ثم حدّث طلبات Getman المقابلة في التطبيق، أو دع الوكيل يعدّل ملفات الطلبات. حدّث الأمثلة والتأكيدات وأي نقاط نهاية جديدة.

  2. أنشئ حزمة التغيير. استخدم New change package في عرض Changes، أو عنصر لوحة الأوامر New change package…، أو الأمر التالي:

    getman change new --workspace getman --title "Order totals in cents, with currency" \
      --summary "GET /orders/{id} returns totalCents and currency." \
      --migration "Read totalCents (integer cents) and currency. total is gone." \
      --author "Alice (backend)"

    يطبع الأمر المرجع، مثل GT-SHOP-001.

  3. تحقق مقابل واجهة برمجية تعمل. استخدم Verify now في التغيير، أو شغّل getman change verify GT-SHOP-001 --workspace getman --env Local. تُسجَّل التشغيلات الفاشلة كأدلة أيضًا.

  4. انشر التغيير عندما يصبح نهائيًا. استخدم Publish في رأس التغيير، أو شغّل getman change state GT-SHOP-001 published --workspace getman.

  5. نفّذ commit للكود وملفات getman/ معًا، ثم ادفع التغييرات.

تغيير الويب (Bob)

  1. اضغط Fetch في شريط Git. تظهر الحزمة الجديدة في Inbox بحالة Not pulled.

  2. اضغط Pull. يسألك Getman قبل أن يستبدل السحب طلبات عدّلتها.

  3. اقرأ الحزمة: الفرق والأمثلة وملاحظات الترحيل والأدلة. من الطرفية، شغّل getman change show GT-SHOP-001 --workspace getman.

  4. حدّث عميل الويب وشغّل اختباراته.

  5. أبلغ عن الحالة. استخدم Report status في التغيير، أو شغّل الأمر التالي:

    getman change report GT-SHOP-001 --workspace getman --consumer web --status verified --author "Bob (web)"

    تُقبل الحالة verified فقط بعد تشغيل ناجح مقابل العقد الحالي. شغّل Verify now أولًا إذا لم تفعل ذلك.

  6. نفّذ commit وادفع التغييرات.

بعد أن يدفع Bob، ويضغط Alice Fetch وPull، يظهر التغيير بحالة Integration verified في عرضها.

البحث عن التغيير المطلوب

يحتوي عرض Changes على أربعة عروض: Inbox وCompleted وAll changes وTimeline. اضبط I integrate as على اسم المستهلك لديك، حتى يعرض Inbox التغييرات التي ما زالت تنتظر فريقك.

يعرض العرض Completed التغييرات التي أنهاها المستهلك لديك.

إجراءات Git صريحة

يقرأ Getman المجلد والفرع الذي جُلب، ويُبرز الحزم الواردة وتعديلات الطلبات. لا يغيّر Git من تلقاء نفسه.

الإجراء ما يفعله
Fetch ينفّذ git fetch.
Pull ينفّذ git pull --ff-only. لا يدمج أبدًا.
Commit… ينفّذ commit للملفات التي تحددها من Getman فقط.
Push يدفع الفرع الحالي. لا يفرض التحديث أبدًا.

يتم الدمج وحل التعارضات في Git كالمعتاد. إذا رُفض السحب بسبب تغييرات محلية، فاحفظها بـ commit أو تخلّص منها أولًا.

أسئلة شائعة

  • أنشأ شخصان GT-SHOP-007. أعطِ أحدهما الرقم الحر التالي، وأعد تسمية الملف ليطابقه، ثم نفّذ commit. راجع استكشاف الأخطاء وإصلاحها.
  • تفشل اختبارات Bob بعد Pull. هذا متوقع في التغيير الكاسر. حدّث العميل، ثم تحقق مجددًا.
  • لا ترى Alice حالة Bob. تحتاج إلى Fetch وPull بعد أن يدفع Bob.

لمعرفة صيغة الملفات وقواعد التحقق، راجع حزم التغيير. ولترك وكيل برمجي ينفّذ هذه الخطوات، راجع ربط وكيل برمجي.