الدمج والوسم والإصدار: تتبع ما يُنشر في الإنتاج

لقد انتهيت للتو من مراجعة طلب سحب (Pull Request). الكود يبدو جيدًا، الاختبارات نجحت، وزملاؤك وافقوا على التغييرات. ماذا الآن؟

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

دمج Commit هو سجلك الورقي

هناك عدة طرق لدمج التغييرات من فرع الميزة إلى الفرع الرئيسي. الطريقة الأكثر شيوعًا هي إنشاء merge commit.

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

قارن هذا مع الدمج السريع (fast-forward merge)، حيث يقوم Git ببساطة بتحريك المؤشر للأمام دون إنشاء commit جديد. الدمج السريع يحافظ على تاريخ خطي، لكنه يفقد السياق الذي حدث فيه الدمج. إذا احتجت لاحقًا إلى تتبع خطأ إلى مصدره، فإن merge commit يعطيك رابطًا مباشرًا لمناقشة طلب السحب، وتعليقات المراجعة، والتغييرات الدقيقة التي اجتمعت.

عند استخدام merge commits، فإن سجل git الخاص بك يروي قصة. يمكنك رؤية أن feature-x تم دمجه في main يوم الثلاثاء، و feature-y تم دمجه يوم الأربعاء. إذا حدث خطأ يوم الخميس، فأنت تعرف بالضبط أي دمج يجب التحقيق فيه أولاً.

المخطط التالي يوضح كيف ترتبط كل خطوة لإنشاء سجل ورقي واضح:

إليك التسلسل الدقيق للأوامر التي يجب اتباعها بعد الموافقة على طلب السحب:

# 1. الدمج مع merge commit غير سريع
$ git checkout main
$ git merge --no-ff feature-x -m "Merge feature-x into main"

# 2. وسم الإصدار على merge commit
$ git tag -a v1.2.3 -m "Release v1.2.3"

# 3. دفع main والوسم الجديد إلى المستودع البعيد
$ git push origin main --tags

# 4. حذف فرع الميزة محليًا وعن بعد
$ git branch -d feature-x
$ git push origin --delete feature-x
flowchart TD A[Feature Branch] --> B[Merge Commit] B --> C[Delete Feature Branch] C --> D[Create Tag: v1.2.0] D --> E[Generate Release Notes] E --> F[Deploy to Production] B -.-> G[Branch Info: source & target] D -.-> H[Permanent reference point] F -.-> I[Traceable to merge commit]

التنظيف بعد الدمج

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

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

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

الوسوم: إعطاء أسماء للإصدارات

الفرع الرئيسي الخاص بك يحتوي الآن على أحدث كود. لكن كيف تعرف بالضبط أي commit يعمل في الإنتاج الآن؟ الفرع الرئيسي يستمر في التقدم مع دخول تغييرات جديدة. بدون نقطة مرجعية ثابتة، أنت تخمن.

هنا يأتي دور الوسوم (Tags). الوسم هو تسمية تُلحق بـ commit معين. على عكس الفروع، الوسوم لا تتحرك. بمجرد إنشاء وسم، فإنه يشير إلى ذلك الـ commit بالضبط إلى الأبد.

عادةً ما تنشئ الفرق الوسوم عندما تُصدر إصدارًا جديدًا. على سبيل المثال، بعد اكتمال الاختبارات واستعداد الفريق للنشر في الإنتاج، ينشئون وسمًا مثل v1.2.0 على آخر commit في الفرع الرئيسي. يصبح هذا الوسم مرجعًا دائمًا. بعد ستة أشهر، إذا سأل شخص ما عن الكود الذي كان يعمل في ذلك التاريخ، تتحقق من الوسم.

تسمية الوسوم بشكل متسق

يجب أن تتبع أسماء الوسوم اتفاقية يفهمها الجميع في الفريق. التحكم الدلالي بالإصدارات (Semantic Versioning) هو خيار شائع: v1.2.3 حيث:

  • الرقم الأول يتغير للإصدارات الرئيسية التي تكسر التوافق مع الإصدارات السابقة
  • الرقم الثاني يتغير للميزات الجديدة
  • الرقم الثالث يتغير لإصلاحات الأخطاء والتحسينات الصغيرة

لكن التحكم الدلالي بالإصدارات ليس الخيار الوحيد. بعض الفرق تستخدم التواريخ: release-2024-11-15. أخرى تستخدم أرقام البناء: build-142. المهم هو الاتساق. اختر تنسيقًا، وثقه، واستخدمه لكل إصدار.

أيًا كان التنسيق الذي تختاره، تأكد من إنشاء الوسم من نفس الـ commit الذي تم نشره. إذا قمت بوسم commit مختلف، يفقد الوسم قيمته كنقطة مرجعية موثوقة.

ملاحظات الإصدار: ما الذي تغير ولماذا

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

ملاحظات الإصدار الجيدة تشمل:

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

ملاحظات الإصدار لا يجب أن تُكتب من الصفر. العديد من الفرق تُنشئها من عناوين طلبات السحب أو رسائل commits بين آخر وسم والوسم الحالي. مراجعة سريعة لإزالة التفاصيل التقنية وإضافة سياق موجه للمستخدم تكون كافية عادةً.

الجسر بين التطوير والإنتاج

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

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

قائمة ممارسات عملية

قبل إصدارك القادم، اتبع هذه الخطوات:

  • ادمج طلب السحب مع merge commit، وليس دمجًا سريعًا
  • احذف فرع الميزة بعد تأكيد الدمج
  • أنشئ وسمًا على نفس الـ commit الذي سيتم نشره
  • اكتب ملاحظات الإصدار تغطي ما تغير ولماذا هو مهم
  • تأكد من دفع الوسم إلى المستودع البعيد حتى يتمكن الفريق بأكمله من رؤيته

ماذا يعني هذا لفريقك

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