التعامل مع التفريعات البعيدة (Remote Branches) في Git
يُعد Git من أقوى نظم التحكم في الإصدارات المستخدمة في البرمجة الحديثة، ويعود الفضل في ذلك إلى مرونته العالية وإمكاناته المتقدمة في إدارة الكود المصدري بين فرق العمل المتوزعة. ومن أهم ميزاته قدرته على التعامل مع التفريعات (Branches)، سواء كانت محلية (Local) أو بعيدة (Remote). إن التفريعات البعيدة تُعتبر من اللبنات الأساسية التي تُمكِّن فرق التطوير من التعاون والعمل على ميزات مختلفة ضمن نفس المشروع، دون التأثير على الفرع الرئيسي أو على عمل الزملاء الآخرين.
يهدف هذا المقال إلى تقديم فهم شامل للتعامل مع التفريعات البعيدة في Git، ابتداءً من مفاهيمها الأساسية، مرورًا بكيفية إنشائها وتتبعها، وانتهاءً بكيفية حذفها ومزامنتها، مع تقديم أمثلة عملية وحالات استخدام واقعية تدعم هذا الفهم.
أولًا: ما هي التفريعات البعيدة (Remote Branches)؟
التفريعات البعيدة هي نسخ من الفروع الموجودة على مستودع Git على الخادم (مثل GitHub، GitLab، Bitbucket)، وهي تُستخدم لتعقب التغييرات التي تحدث في مستودع مركزي خارجي. وتُخزن هذه الفروع محليًا في مجلد خاص باسم remotes/ داخل المستودع، حيث يمكن مشاهدتها باستخدام الأمر:
bashgit branch -r
على سبيل المثال، إذا كان اسم الريموت هو origin وكان هناك فرع اسمه develop على الريموت، فستظهر النتيجة بالشكل التالي:
bashorigin/develop
هذا يعني أن هناك فرعًا بعيدًا باسم develop موجودًا على المستودع البعيد المسمى origin.
ثانيًا: الفرق بين الفروع المحلية والبعيدة
| النوع | الفروع المحلية (Local Branches) | الفروع البعيدة (Remote Branches) |
|---|---|---|
| الموقع | تُخزن في جهاز المستخدم | تُخزن في الخادم (GitHub مثلًا) |
| التحديث | يمكن تعديلها مباشرة | تحتاج إلى مزامنة لجلب أو دفع التغييرات |
| الإنشاء | تُنشأ بالأمر git branch |
تُنشأ عند الدفع إلى الريموت أو باستخدام git push |
| الاستخدام | تُستخدم في التطوير اليومي | تُستخدم لتعقب العمل الجماعي والتغييرات على الخادم |
ثالثًا: إنشاء فرع محلي من فرع بعيد
لإنشاء فرع محلي يتتبع فرعًا بعيدًا، يتم استخدام الأمر:
bashgit checkout -b my-feature origin/my-feature
هذا الأمر يقوم بما يلي:
-
إنشاء فرع محلي باسم
my-feature -
ربطه بالفرع البعيد
origin/my-featureليقوم بتتبعه تلقائيًا -
التبديل إلى الفرع الجديد
وبذلك يصبح الفرع المحلي على علم بكل التغييرات القادمة من الفرع البعيد الذي يتبعه.
رابعًا: جلب التحديثات من الفروع البعيدة
عندما يعمل أكثر من شخص على نفس المشروع، قد تحدث تغييرات في الفروع البعيدة. لجلب آخر التحديثات دون دمجها تلقائيًا، يتم استخدام:
bashgit fetch
هذا الأمر يقوم بتحديث جميع الفروع البعيدة المخزنة محليًا من دون التأثير على حالة الفروع المحلية الحالية.
وإذا كان المطلوب جلب التحديثات من ريموت معين فقط:
bashgit fetch origin
وبعد تنفيذ fetch، يمكن مقارنة التغييرات أو دمجها يدويًا حسب الحاجة.
خامسًا: تتبع الفرع البعيد عند الإنشاء
في بعض الأحيان، يُرغب بإنشاء فرع محلي يتبع فرعًا بعيدًا بشكل مباشر، ويمكن فعل ذلك باستخدام:
bashgit checkout --track origin/feature-x
هذا الأمر يُنشيء فرعًا محليًا اسمه feature-x ويجعله يتتبع الفرع البعيد origin/feature-x.
وهناك أيضًا الطريقة الأقصر باستخدام:
bashgit checkout feature-x
لكن ذلك مشروط بوجود فرع بعيد واحد فقط يحمل الاسم feature-x.
سادسًا: دفع فرع محلي ليصبح فرعًا بعيدًا
عند إنشاء فرع محلي جديد وترغب في رفعه إلى الريموت ليكون متاحًا للآخرين:
bashgit push -u origin my-new-branch
الخيارات المستخدمة هنا تعني:
-
origin: اسم الريموت -
my-new-branch: اسم الفرع المحلي -
-u: يربط الفرع المحلي بالبعيد لتسهيل تنفيذ أوامرpullوpushمستقبلًا بدون تحديد الاسم الكامل للفرع
بعد هذا الإجراء، يمكن ببساطة استخدام git push أو git pull في هذا الفرع دون الحاجة إلى تحديد الريموت والفرع كل مرة.
سابعًا: حذف فرع بعيد
لحذف فرع من المستودع البعيد:
bashgit push origin --delete old-branch
هذا الأمر يُستخدم في حال تم الانتهاء من العمل على فرع معين ولم تعد هناك حاجة له على الخادم.
بعد تنفيذ هذا الأمر، يمكن استخدام git fetch -p (أو --prune) لتنظيف الفروع البعيدة المحذوفة من قائمة الفروع المحلية.
ثامنًا: تحديث الفروع البعيدة المحلية
عندما يُحدث أحد الزملاء فرعًا بعيدًا أو يحذفه، يجب مزامنة المستودع المحلي للحصول على هذه التحديثات:
bashgit fetch --prune
هذا الخيار يقوم بجلب جميع الفروع البعيدة وتحديث حالة الفروع المحذوفة، مما يضمن أن قائمة الفروع المحلية تعكس تمامًا ما هو موجود في المستودع البعيد.
تاسعًا: إعادة تسمية الفروع البعيدة
إعادة التسمية للفروع في Git تتم بشكل محلي أولًا ثم على الريموت. لعمل ذلك:
-
إعادة تسمية الفرع المحلي:
bashgit branch -m old-name new-name
-
حذف الفرع القديم من الريموت:
bashgit push origin --delete old-name
-
رفع الفرع الجديد:
bashgit push -u origin new-name
عاشرًا: مقارنة الفروع المحلية بالبعيدة
لمعرفة الفروقات بين الفرع المحلي والفرع البعيد الذي يتبعه:
bashgit fetch git diff origin/my-branch
أو لمعرفة عدد الـ commits التي تختلف بها الفروع:
bashgit log --oneline my-branch..origin/my-branch
هذا يُظهر الكمّية والنوعية الدقيقة للاختلافات، ويمكن استخدامه قبل عمليات الدمج أو الدفع للتأكد من حالة التفرع.
حادي عشر: التعامل مع أكثر من ريموت واحد
من الممكن أن يحتوي مشروع Git على أكثر من ريموت (مثل origin, upstream). ويتم ذلك باستخدام:
bashgit remote add upstream https://github.com/other/repo.git
ثم يمكن تنفيذ عمليات fetch، pull، أو push إلى الريموت الجديد:
bashgit fetch upstream
أو:
bashgit pull upstream main
يُستخدم هذا في حالات كثيرة مثل:
-
عندما يكون هناك مستودع رئيسي (upstream) ومستودع خاص بالتطوير (fork)
-
عند إدارة نسخ متعددة من المشروع لجهات مختلفة
ثاني عشر: جدول ملخص لأوامر Git الشائعة مع الفروع البعيدة
| المهمة | الأمر المستخدم |
|---|---|
| عرض الفروع البعيدة | git branch -r |
| إنشاء فرع محلي يتبع فرعًا بعيدًا | git checkout -b branch-name origin/branch-name |
| جلب التحديثات من الريموت | git fetch أو git fetch origin |
| رفع فرع جديد إلى الريموت | git push -u origin branch-name |
| حذف فرع بعيد | git push origin --delete branch-name |
| تتبع فرع بعيد بشكل مباشر | git checkout --track origin/branch-name |
| تنظيف الفروع البعيدة المحذوفة | git fetch --prune |
| مقارنة فرع محلي بفرع بعيد | git diff origin/branch-name |
ثالث عشر: ممارسات موصى بها عند التعامل مع الفروع البعيدة
-
تسمية الفروع بشكل واضح: يجب أن تعبر الأسماء عن الغرض منها مثل
feature/login-formأوbugfix/payment-error. -
التنظيف الدوري: من الضروري حذف الفروع التي انتهى استخدامها من الريموت لتجنب التكدس.
-
الاعتماد على
fetchبانتظام: جلب التحديثات يضمن مزامنة الحالة دون التسبب بتغييرات مفاجئة في الكود. -
عدم الدفع مباشرة إلى الفرع الرئيسي: يُفضل العمل على فروع منفصلة ودمجها لاحقًا بواسطة Pull Requests لمراجعة الكود.
-
التحقق قبل الدمج: يُوصى دائمًا بمقارنة الفروع قبل عمليات الدمج (merge) لتفادي تعارضات غير متوقعة.
المصادر والمراجع
-
Pro Git Book – Scott Chacon and Ben Straub (https://git-scm.com/book/)
-
Git Documentation – https://git-scm.com/docs

