كيفية استخدام Git Push لرفع الفرع المحلي إلى المستودع البعيد Origin
مقدمة سريعة إلى أمر git push
يُعد الأمر git push من أكثر أوامر Git استخداماً في العمل اليومي، إذ يتيح لك إرسال التعديلات من الفرع المحلي إلى المستودع البعيد. ورغم أن الأمر يبدو بسيطاً، فإنه يدعم عدداً من الخيارات المهمة التي تساعدك على التحكم في طريقة رفع الفروع وإدارة سجل التعديلات بكفاءة وأمان.
في هذا الدليل، ستتعرف إلى أشهر الطرق العملية لاستخدام git push، بدءاً من رفع الفرع الحالي إلى origin، وصولاً إلى الرفع الإجباري، والرفع الآمن باستخدام --force-with-lease، وكذلك رفع فرع محلي إلى فرع بعيد باسم مختلف.

ما وظيفة الأمر git push؟
تتمثل الوظيفة الأساسية للأمر git push في نقل commits الموجودة في جهازك المحلي إلى مستودع بعيد مثل GitHub أو GitLab. والصيغة العامة للأمر هي:
$ git push <remote> <branch>
في هذا التركيب:
<remote>: اسم المستودع البعيد، وغالباً يكونorigin.<branch>: اسم الفرع الذي تريد رفعه.
عند تشغيل الأمر git push دون تحديد معاملات إضافية، يحاول Git استخدام الإعدادات الافتراضية، والتي تكون عادة المستودع origin والفرع الحالي الذي تعمل عليه.
كيفية رفع فرع محلي إلى origin
إذا كنت تعمل على الفرع الحالي، مثل main، فإن تنفيذ الأمر البسيط التالي يكون كافياً في كثير من الحالات:
$ git push
عملياً، سيتصرف Git كما لو أنك نفذت:
$ git push origin main
أي أنه سيرفع الفرع المحلي main إلى الفرع البعيد main داخل المستودع origin.
في المثال التالي، يمكنك رؤية إعداد المستودع البعيد ثم تنفيذ عملية الرفع:
(main)$ git remote -v
origin git@github.com:johnmosesman/burner-repo.git (fetch)
origin git@github.com:johnmosesman/burner-repo.git (push)
(main)$ git push
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 16 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 274 bytes | 274.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:johnmosesman/burner-repo.git
b7f661f..ab77dd6 main -> main
يوضح السطر الأخير أن الفرع المحلي main تم رفعه إلى الفرع البعيد main بنجاح:
main -> main
متى تحتاج إلى force push في Git؟
في الوضع الطبيعي، تضيف commits جديدة إلى سجل الفرع ثم ترفعها بشكل اعتيادي. لكن في بعض الحالات، قد تحتاج إلى استبدال سجل الفرع البعيد قسرياً، وهنا يظهر خيار --force.
من أشهر الحالات التي يحدث فيها ذلك:
- تصحيح خطأ بعد إعادة كتابة سجل التعديلات.
- استخدام عمليات مثل
rebaseالتي تغيّر بنية السجل وتعيد إنشاءcommitsجديدة.
من المهم فهم أن rebase لا يعيد ترتيب السجل فقط، بل قد ينشئ commits جديدة بالكامل. لذلك، عندما تحاول رفع فرع تم تنفيذ rebase عليه محلياً بينما لا يزال الفرع البعيد يعتمد على السجل القديم، سيرفض Git العملية عادة لحماية السجل من الكتابة غير المتوافقة.
مثال على رسالة الرفض:
(my-feature)$ git push
To github.com:johnmosesman/burner-repo.git
! [rejected] my-feature -> my-feature (non-fast-forward)
error: failed to push some refs to 'git@github.com:johnmosesman/burner-repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
إذا كنت متأكداً من أنك تريد استبدال السجل البعيد بالسجل المحلي، يمكنك استخدام:
(my-feature)$ git push --force origin my-feature
وقد ترى نتيجة مشابهة لما يلي:
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 184 bytes | 184.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To github.com:johnmosesman/burner-repo.git
+ edb64e2...52f54da my-feature -> my-feature (forced update)
كما يمكنك استخدام الاختصار -f بدلاً من --force.
لكن انتبه: الرفع القسري إجراء قد يكون مدمراً، لأنه قد يستبدل تاريخ الفرع البعيد ويؤدي إلى فقدان تغييرات مهمة إن لم تكن متأكداً مما تفعله.
الرفع الآمن باستخدام --force-with-lease
أحياناً تحتاج إلى تنفيذ force push، لكنك لا تريد المخاطرة بالكتابة فوق تغييرات أضافها زميل آخر إلى الفرع نفسه. هنا يُفضل استخدام الخيار --force-with-lease.
فكرة هذا الخيار بسيطة: أخبر Git أن ينفذ الرفع القسري فقط إذا كان الفرع البعيد لا يزال بالحالة التي تتوقعها أنت محلياً. وإذا قام شخص آخر برفع تعديلات جديدة منذ آخر مرة قمت فيها بالمزامنة، فسيتم إيقاف العملية بدلاً من الكتابة فوق تلك التغييرات.
لذلك، إذا كنت تعمل ضمن فريق، فمن الأفضل:
- تجنب استخدام
--forceقدر الإمكان. - استخدام
--force-with-leaseعند الحاجة إلى إعادة كتابة السجل. - إبلاغ الفريق قبل تنفيذ أي عملية قد تغيّر تاريخ الفرع المشترك.
كيفية رفع فرع محلي إلى فرع بعيد باسم مختلف
في أغلب الأحيان، يتم رفع الفرع المحلي إلى فرع بعيد يحمل الاسم نفسه. لكن هذا ليس شرطاً دائماً. إذا أردت رفع فرع محلي إلى فرع بعيد باسم مختلف، فاستخدم النقطتين : للفصل بين الاسمين.
الصيغة تكون كالتالي:
git push origin local-branch:remote-branch
مثال عملي:
(some-branch)$ git push origin some-branch:my-feature
Total 0 (delta 0), reused 0 (delta 0)
To github.com:johnmosesman/burner-repo.git
+ 728f0df...8bf04ea some-branch -> my-feature
في هذا المثال، تم رفع الفرع المحلي some-branch إلى الفرع البعيد my-feature.
تُعد هذه الطريقة مفيدة عندما:
- تريد اختبار اسم مختلف للفرع على الخادم.
- تعمل وفق سياسة تسمية مختلفة بين البيئة المحلية والبعيدة.
- تحتاج إلى رفع فرعك إلى فرع مراجعة محدد داخل المشروع.
كيفية رفع جميع الفروع المحلية إلى المستودع البعيد
لن تحتاج إلى هذا الأمر كثيراً، لكنه مفيد في بعض السيناريوهات، مثل إعداد بيئة جديدة أو مزامنة عدة فروع دفعة واحدة. في هذه الحالة يمكنك استخدام الخيار --all:
(main)$ git branch
* main
my-feature
(main)$ git push --all
...
To github.com:johnmosesman/burner-repo.git
b7f661f...6e36148 main -> main
* [new branch] my-feature -> my-feature
سيؤدي ذلك إلى رفع جميع الفروع المحلية المرتبطة إلى المستودع البعيد المحدد.
ومع ذلك، من الأفضل استخدام هذا الخيار بحذر، لأن رفع كل الفروع قد ينشر فروعاً تجريبية أو غير جاهزة للمشاركة مع الفريق.
نصائح عملية لاستخدام git push بكفاءة
تحقق من الفرع الحالي قبل الرفع
قبل تنفيذ git push، تأكد من اسم الفرع الحالي باستخدام git branch أو git status، حتى لا ترفع التعديلات إلى وجهة غير مقصودة.
تجنب الرفع القسري على الفروع المشتركة
إذا كان الفرع مستخدماً من عدة مطورين، فحاول ألا تستخدم --force إلا عند الضرورة القصوى، لأن هذا قد يربك بقية أعضاء الفريق ويصعّب استعادة السجل الصحيح.
افهم الفرق بين push وpull
الأمر push يرسل تغييراتك إلى المستودع البعيد، بينما الأمر pull يجلب أحدث التغييرات من المستودع ويُحدّث نسختك المحلية. فهم هذا الفرق أساسي لتجنب التعارضات وسوء إدارة الفروع.
استخدم الأوامر الصريحة عند الحاجة
رغم أن git push بدون معاملات مريح، فإن كتابة git push origin main بشكل صريح تكون أحياناً أكثر وضوحاً، خاصة في المشاريع الكبيرة أو عند العمل على عدة مستودعات.
الخلاصة التقنية
يُعد git push أمراً محورياً في أي سير عمل يعتمد على Git. ومع أن استخدامه الأساسي بسيط، فإن فهم خيارات مثل --force و--force-with-lease و--all يمنحك قدرة أكبر على إدارة الفروع بأمان واحترافية. من الناحية التقنية، أفضل ممارسة هي الاعتماد على الرفع العادي كلما أمكن، وعدم اللجوء إلى الرفع القسري إلا بعد فهم تأثيره الكامل على سجل المشروع والفريق.