پوش کردن — چیست، چگونه git push کار می‌کند و چه زمانی نیاز است

پوش در Git چیست

Git push دستوری است که کامیت‌ها را از مخزن محلی به مخزن راه‌دور منتقل می‌کند. برخلاف commit که تغییرات را فقط در ماشین محلی توسعه‌دهنده ذخیره می‌کند، push این تغییرات را برای کل تیم منتشر می‌کند. Push گامی اجباری قبل از ایجاد Pull Request و استقرار است.

معماری Git فرض می‌کند که هر توسعه‌دهنده در مخزن محلی خود کار می‌کند. کامیت‌ها به صورت محلی ایجاد و انباشته می‌شوند تا زمانی که توسعه‌دهنده تصمیم به پوش بگیرد. این آزادی می‌دهد: می‌توان کامیت‌های محلی زیادی انجام داد، آزمایش کرد و تاریخچه را بدون تأثیر بر همکاران بازنویسی نمود.

# پوش به remote اصلی، شاخه main
git push origin main

# پوش شاخه جاری به remote با upstream
git push -u origin feature/new-dashboard

# پوش همه شاخه‌ها با نام‌های منطبق
git push --all origin

# force push با lease (force push امن)
git push --force-with-lease

پس از پوش، مخزن راه‌دور refs (ارجاعات به شاخه‌ها) را به‌روزرسانی می‌کند تا به کامیت‌های جدید اشاره کنند. سایر توسعه‌دهندگان می‌توانند این تغییرات را از طریق git pull یا git fetch دریافت کنند. این تبادل کامیت‌ها اساس توسعه مشارکتی را تشکیل می‌دهد.

git push چگونه کار می‌کند

دستور git push شاخه‌های محلی و راه‌دور را مقایسه می‌کند و فقط کامیت‌های گم‌شده را منتقل می‌کند. Git همه فایل‌ها را دوباره ارسال نمی‌کند — فقط تفاوت (delta) را منتقل می‌کند که پوش را حتی در مخازن بزرگ سریع می‌کند. پروتکل Git از انتقال هوشمند استفاده می‌کند که حجم داده‌های ارسالی را به حداقل می‌رساند.

اگر شاخه راه‌دور حاوی کامیت‌هایی باشد که در محلی وجود ندارند، پوش رد می‌شود. این یک مکانیسم محافظتی برای جلوگیری از از دست رفتن تغییرات است. در چنین شرایطی توسعه‌دهنده باید ابتدا git pull را اجرا کند، تغییرات را ادغام نماید و سپس دوباره پوش کند. جایگزین force push است که شاخه راه‌دور را بازنویسی می‌کند، اما باید با احتیاط استفاده شود.

درک مخازن راه‌دور کلید پوش صحیح است. معمولاً از origin — نام پیش‌فرض مخزن راه‌دور استفاده می‌شود. دستور git remote -v لیست مخازن راه‌دور و URL آن‌ها را نشان می‌دهد. می‌توان چندین remote اضافه کرد (مثلاً origin برای مخزن اصلی و upstream برای fork).

چه زمانی باید پوش کرد

قانون اصلی: بعد از هر مرحله منطقیاً تکمیل‌شده کار باید پوش کرد. اگر توسعه‌دهنده یک کار یا بخشی از آن را تمام کرده است — وقت پوش است. با این حال، پوش کار ناتمامی که بیلد را می‌شکند توصیه نمی‌شود. بیلد نسوخته حداقل نیاز برای پوش به هر شاخه‌ای است.

در توسعه تیمی ریتم زیر پذیرفته شده است: صبح — git pull برای دریافت تغییرات همکاران، در طول روز — چند کامیت و یکی دو پوش، عصر — پوش نهایی تمام کارهای تکمیل‌شده. هرچه توسعه‌دهنده بیشتر پوش کند، خطر تداخل در ادغام شاخه‌ها کمتر و پیشرفت کار شفاف‌تر است.

• پس از اتمام کار — commit کردن و پوش راه‌حل نهایی به شاخه feature
• قبل از رفتن — پوش کار ناتمام به شاخه feature (نه به main!)
• قبل از ایجاد PR — اطمینان از اینکه همه کامیت‌ها پوش شده و برای بازبینی در دسترس هستند
• پس از rebase — پوش با --force-with-lease به شاخه feature خود

قوانین پوش امن

پوش امن مجموعه‌ای از قوانین برای جلوگیری از از دست رفتن داده‌ها و تداخل در تیم است. اولین و مهم‌ترین قانون: هرگز مستقیماً به شاخه main یا master پوش نکنید، مگر اینکه در پروژه استقرار مستقیم پیکربندی شده باشد. در تیم‌های مدرن، حفاظت از شاخه main در سطح GitHub branch protection پیکربندی می‌شود.

قانون دوم: قبل از پوش با شاخه راه‌دور همگام‌سازی کنید. git pull --rebase را اجرا کنید تا از commit ادغام در هنگام ترکیب جلوگیری شود. این کار تاریخچه را ساده و خطی می‌کند. اگر پوش رد شد — از force push خام استفاده نکنید، بلکه ابتدا بررسی کنید چه کامیت‌هایی در شاخه راه‌دور ظاهر شده‌اند.

قانون سوم: هوک‌های pre-push را پیکربندی کنید که به طور خودکار تست‌ها و لینتر را قبل از ارسال اجرا می‌کنند. اگر تست‌ها مردود شوند — پوش مسدود می‌شود. چنین هوک‌هایی از طریق Husky או Git hooks (فایل pre-push در .git/hooks) پیکربندی می‌شوند.

قانون چهارم: فایل‌های باینری بزرگ را پوش نکنید. Git برای ذخیره مصنوعات باینری طراحی نشده است — آنها مخزن را حجیم کرده و عملیات را کند می‌کنند. برای فایل‌های بزرگ از Git LFS (Large File Storage) استفاده می‌شود. اگر فایل باینری قبلاً پوش شده و به تاریخچه راه یافته است، باید از طریق git filter-branch حذف شود.

اگر پوش انجام نشد چه کنیم

شایع‌ترین دلیل پوش ناموفق — شاخه راه‌دور حاوی کامیت‌هایی است که در محلی وجود ندارند. این زمانی اتفاق می‌افتد که توسعه‌دهنده دیگری تغییرات خود را به همان شاخه پوش کرده است. راه‌حل: git pull را اجرا کنید، تداخل‌های احتمالی را حل کنید و پوش را تکرار کنید.

# پوش رد شد — ابتدا fetch و rebase کنید
git fetch origin
git rebase origin/main
# تعارض‌ها را حل کنید، سپس:
git push --force-with-lease

# یا به سادگی تغییرات راه‌دور را ادغام کنید
git pull origin main
git push

دلیل دوم — نداشتن مجوز نوشتن در شاخه. اگر شاخه main با قانون branch protection محافظت می‌شود، پوش‌های مستقیم ممنوع هستند. راه‌حل: به شاخه feature پوش کنید و Pull Request ایجاد کنید. تنظیمات حفاظت معمولاً از طریق GitHub settings یا GitLab protected branches مدیریت می‌شود.

دلیل سوم — مشکلات احراز هویت. اعتبارنامه‌های قدیمی، انتقال به SSH یا تغییر توکن دسترسی شخصی. راه‌حل: URL راه‌دور (git remote -v) را بررسی کنید و اعتبارنامه‌ها را به‌روز کنید. از سال ۲۰۲۱، GitHub احراز هویت با رمز عبور برای HTTPS را لغو کرده است — از توکن شخصی או کلید SSH استفاده می‌شود.