پش کرنا — یہ کیا ہے، git push کیسے کام کرتا ہے اور کب ضروری ہے

Git میں پش کیا ہے

Git push ایک کمانڈ ہے جو commits کو مقامی ریپوزٹری سے ریموٹ ریپوزٹری میں منتقل کرتی ہے۔ commit کے برعکس، جو تبدیلیاں صرف ڈیولپر کی مقامی مشین پر محفوظ کرتا ہے، پش ان تبدیلیوں کو پوری ٹیم کے لیے شائع کرتا ہے۔ Push Pull Request بنانے اور ڈپلائمنٹ سے پہلے ایک لازمی مرحلہ ہے۔

Git کا فن تعمیر فرض کرتا ہے کہ ہر ڈیولپر اپنی مقامی ریپوزٹری میں کام کرتا ہے۔ commits مقامی طور پر بنائے جاتے ہیں اور اس وقت تک جمع ہوتے رہتے ہیں جب تک ڈیولپر انہیں پش کرنے کا فیصلہ نہ کرے۔ یہ آزادی فراہم کرتا ہے: آپ بہت سے مقامی commits کر سکتے ہیں، تجربہ کر سکتے ہیں اور ساتھیوں کو متاثر کیے بغیر تاریخ کو دوبارہ لکھ سکتے ہیں۔

# origin remote، main برانچ میں پش کریں
git push origin main

# موجودہ برانچ کو upstream کے ساتھ remote میں پش کریں
git push -u origin feature/new-dashboard

# مماثل ناموں والی تمام برانچز پش کریں
git push --all origin

# لیز کے ساتھ فورس پش (محفوظ فورس پش)
git push --force-with-lease

پش کرنے کے بعد، ریموٹ ریپوزٹری refs (برانچ حوالہ جات) کو اپ ڈیٹ کرتی ہے تاکہ وہ نئے commits کی طرف اشارہ کریں۔ دوسرے ڈیولپرز git pull یا git fetch کے ذریعے یہ تبدیلیاں حاصل کر سکتے ہیں۔ commits کا یہ تبادلہ باہمی تعاون پر مبنی ڈیولپمنٹ کی بنیاد بناتا ہے۔

git push کیسے کام کرتا ہے

git push کمانڈ مقامی اور ریموٹ برانچز کا موازنہ کرتی ہے اور صرف گمشدہ commits کو منتقل کرتی ہے۔ Git تمام فائلیں دوبارہ نہیں بھیجتا — یہ صرف ڈیلٹا منتقل کرتا ہے، جو بڑی ریپوزٹریز کے لیے بھی پش کو تیز بناتا ہے۔ Git پروٹوکول سمارٹ ٹرانسفر استعمال کرتا ہے، جو منتقل کردہ ڈیٹا کی مقدار کو کم سے کم کرتا ہے۔

اگر ریموٹ برانچ میں ایسے commits ہیں جو مقامی طور پر موجود نہیں ہیں، تو پش مسترد کر دیا جائے گا۔ یہ ایک حفاظتی طریقہ کار ہے جو تبدیلیوں کے ضیاع کو روکتا ہے۔ اس صورت میں، ڈیولپر کو پہلے git pull چلانا چاہیے، تبدیلیوں کو ضم کرنا چاہیے، اور پھر دوبارہ پش کرنا چاہیے۔ ایک متبادل فورس پش ہے، جو ریموٹ برانچ کو اوور رائٹ کرتا ہے، لیکن اسے احتیاط سے استعمال کرنا چاہیے۔

ریموٹ ریپوزٹریز کو سمجھنا صحیح پش کی کلید ہے۔ عام طور پر، origin ڈیفالٹ ریموٹ ریپوزٹری کا نام ہے۔ git remote -v کمانڈ ریموٹ ریپوزٹریز اور ان کے URLs کی فہرست دکھاتا ہے۔ آپ متعدد ریموٹ شامل کر سکتے ہیں (مثال کے طور پر، مرکزی ریپوزٹری کے لیے origin اور فورک کے لیے upstream)۔

تبدیلیاں کب پش کرنی چاہئیں

بنیادی قاعدہ: کام کے ہر منطقی طور پر مکمل مرحلے کے بعد پش کریں۔ اگر ڈیولپر نے کوئی کام یا اس کا حصہ مکمل کر لیا ہے — تو پش کرنے کا وقت آ گیا ہے۔ تاہم، نامکمل کام جس سے بلڈ ٹوٹتا ہے پش کرنا تجویز نہیں کیا جاتا۔ بلڈ نہ ٹوٹنا کسی بھی برانچ میں پش کرنے کے لیے کم از کم ضرورت ہے۔

ٹیم ڈیولپمنٹ میں مندرجہ ذیل تال اپنایا جاتا ہے: صبح — ساتھیوں کی تبدیلیاں حاصل کرنے کے لیے git pull، دن میں — کئی commits اور ایک یا دو پش، شام — تمام مکمل کاموں کا آخری پش۔ ڈیولپر جتنی بار پش کرتا ہے، ضم کرنے کے تصادم کا خطرہ اتنا ہی کم اور کام کی پیشرفت اتنی ہی شفاف ہوتی ہے۔

• کام مکمل کرنے کے بعد — commit کریں اور فیچر برانچ میں حتمی حل پش کریں
• جانے سے پہلے — نامکمل کام کو فیچر برانچ میں پش کریں (main میں نہیں!)
• PR بنانے سے پہلے — یقینی بنائیں کہ تمام commits پش ہو چکے ہیں اور جائزے کے لیے دستیاب ہیں
• ری بیس کے بعد --force-with-lease کے ساتھ اپنی فیچر برانچ میں پش کریں

محفوظ پش کے قواعد

محفوظ پش قواعد کا ایک مجموعہ ہے جو ٹیم میں ڈیٹا کے ضیاع اور تصادم کو روکتا ہے۔ پہلا اور سب سے اہم قاعدہ: کبھی بھی براہ راست main یا master برانچ میں پش نہ کریں اگر پروجیکٹ میں براہ راست ڈپلائمنٹ کنفیگر نہ ہو۔ جدید ٹیموں میں، main برانچ کی حفاظت GitHub برانچ پروٹیکشن کی سطح پر کنفیگر کی جاتی ہے۔

دوسرا قاعدہ: پش کرنے سے پہلے ریموٹ برانچ کے ساتھ ہم آہنگ ہو جائیں۔ ضم کرتے وقت مرج commits سے بچنے کے لیے git pull --rebase چلائیں۔ یہ تاریخ کو آسان اور لکیری بناتا ہے۔ اگر پش مسترد ہو جائے — تو ننگا فورس پش استعمال نہ کریں، بلکہ پہلے معلوم کریں کہ ریموٹ برانچ پر کون سے commits آئے ہیں۔

تیسرا قاعدہ: پری پش ہکس ترتیب دیں جو بھیجنے سے پہلے خود بخود ٹیسٹ اور لنٹر چلائیں۔ اگر ٹیسٹ ناکام ہوتے ہیں — تو پش بلاک ہو جاتا ہے۔ ایسے ہکس Husky یا Git ہکس (.git/hooks میں pre-push فائل) کے ذریعے ترتیب دیے جاتے ہیں۔

چوتھا قاعدہ: بڑی بائنری فائلیں پش نہ کریں۔ Git بائنری آرٹیفیکٹس کو ذخیرہ کرنے کے لیے ڈیزائن نہیں کیا گیا — یہ ریپوزٹری کو پھولاتے ہیں اور کارروائیوں کو سست کرتے ہیں۔ بڑی فائلوں کے لیے، Git LFS (Large File Storage) استعمال کریں۔ اگر کوئی بائنری پہلے ہی پش ہو چکی ہے اور تاریخ میں ہے، تو اسے git filter-branch کے ذریعے ہٹایا جانا چاہیے۔

پش ناکام ہو جائے تو کیا کریں

پش ناکام ہونے کی سب سے عام وجہ یہ ہے کہ ریموٹ برانچ میں ایسے commits ہیں جو مقامی طور پر موجود نہیں ہیں۔ یہ اس وقت ہوتا ہے جب کسی دوسرے ڈیولپر نے اپنی تبدیلیاں اسی برانچ میں پش کی ہوں۔ حل: git pull چلائیں، کسی بھی تصادم کو حل کریں اور دوبارہ پش کریں۔

# پش مسترد — پہلے fetch اور rebase کریں
git fetch origin
git rebase origin/main
# تصادم حل کریں، پھر:
git push --force-with-lease

# یا صرف ریموٹ تبدیلیوں کو ضم کریں
git pull origin main
git push

دوسری وجہ — برانچ پر لکھنے کی اجازت کا فقدان۔ اگر main برانچ برانچ پروٹیکشن قواعد سے محفوظ ہے، تو براہ راست پش ممنوع ہیں۔ حل: فیچر برانچ میں پش کریں اور Pull Request بنائیں۔ حفاظتی ترتیبات عام طور پر GitHub سیٹنگز یا GitLab کی محفوظ برانچز کے ذریعے منظم کی جاتی ہیں۔

تیسری وجہ — توثیق کے مسائل۔ پرانی اسناد، SSH میں تبدیلی یا ذاتی رسائی ٹوکن میں تبدیلی۔ حل: ریموٹ URL (git remote -v) چیک کریں اور اسناد کو اپ ڈیٹ کریں۔ 2021 سے، GitHub نے HTTPS کے لیے پاس ورڈ کی توثیق ختم کر دی ہے — ذاتی ٹوکن یا SSH کلید استعمال کریں۔