Git Push و Git Pull چیست؟

Push و Pull دو فرمان رایج برای همگام‌سازی مخزن محلی با یک Remote هستند. طبق GitHub Docs: git push Commitهای محلی یک Branch را به Remote می‌فرستد؛ git pull خط توسعهٔ محلی را با همتای Remote به‌روز می‌کند. بدون این دو، Clone فقط یک عکس قدیمی می‌ماند و کار تیمی روی یک منبع مشترک شکل نمی‌گیرد.

Pull در عمل اغلب ترکیب Fetch (دانلود اشیاء و به‌روزرسانی remote-tracking) و سپس Merge (یا Rebase طبق تنظیم) است. فهم این ترکیب جلوی ترس بی‌مورد و استفادهٔ نادرست را می‌گیرد. فصل Working with Remotes در Pro Git همین مدل را توضیح می‌دهد.

این صفحه جایگزین سیاست تیم دربارهٔ Force Push یا Protected Branch نیست؛ پایهٔ امن برای کار روزمره است.

پاسخ کوتاه

Push = ارسال Commitهایی که محلی دارید و Remote هنوز ندارد، روی Branch مشخص (مثلاً git push origin main). Pull = گرفتن Commitهای جدید Remote و ادغام آن‌ها در Branch جاری. اگر فقط می‌خواهید ببینید Remote چه دارد بدون ادغام، از Fetch استفاده کنید. قبل از Pull بهتر است کار محلی Commit یا Stash شده باشد تا Conflict قابل مدیریت بماند.

Push منتشر می‌کند؛ Pull هم‌تراز می‌کند. هیچ‌کدام به‌تنهایی به‌معنی Deploy نیستند مگر pipeline به آن‌ها وصل باشد.

Remote و نام‌های رایج

بعد از Clone معمولاً یک Remote به نام origin دارید. می‌توانید چند Remote داشته باشید (مثلاً upstream برای پروژهٔ بالادست در مدل Fork). فرمان‌ها نام Remote و نام Branch را می‌گیرند:

bash

git remote -v git push origin main git pull origin main

با تنظیم upstream (-u در اولین Push)، دفعات بعد اغلب git push و git pull بدون آرگومان کافی‌اند:

bash

git push -u origin feature-login

Push دقیقاً چه می‌کند؟

طبق صفحهٔ Pushing commits to a remote repository، شکل رایج این است:

bash

git push REMOTE-NAME BRANCH-NAME

مثال: git push origin main. اگر Remote جلوتر باشد و تاریخچه‌ها واگرا شده باشند، Push رد می‌شود تا اول همگام شوید — این حفاظت است نه باگ. Force Push تاریخچهٔ Remote را بازنویسی می‌کند و روی Branchهای مشترک خطرناک است؛ بسیاری از تیم‌ها آن را روی main می‌بندند.

• Push تگ‌ها با قواعد جدا (مثلاً --tags) انجام می‌شود.
• حذف Branch روی Remote نحو خاصی دارد؛ قبل از استفاده مستند را بخوانید.
• مجوز Write و قوانین Protected Branch می‌توانند Push را مسدود کنند.

Pull، Fetch و Merge

GitHub Docs در Getting changes می‌گوید: Fetch کار جدید را می‌گیرد ولی وارد Branch شما Merge نمی‌کند؛ Merge تاریخچه‌ها را ترکیب می‌کند؛ Pull میان‌بر Fetch+Merge است.

bash

git fetch origin git status git merge origin/main # معادل رایج: git pull origin main

اگر Pull به Conflict بخورد، باید فایل‌ها را حل کنید، add کنید و Commit Merge را تمام کنید — یا با git merge --abort برگردید (جزئیات در مقالهٔ ۰۷۷).

جدول تصمیم سریع

ترتیب کار تیمی پیشنهادی

1. صبح: git pull (یا fetch + merge) روی Branch پایه.
2. کار روی feature Branch؛ Commitهای محلی.
3. قبل از Push نهایی: دوباره پایه را به‌روز کنید تا Conflict زود دیده شود.
4. git push و باز کردن Pull Request (مقالهٔ ۰۷۸).
5. بعد از Merge در UI، محلی main را Pull کنید.

خطاها و سوءتفاهم‌ها

• «Push کردم پس روی Production است» — فقط اگر Deploy خودکار به آن Branch وصل باشد.
• Pull وقتی فایل‌های Uncommitted روی همان خطوط تداخل دارند متوقف می‌شود؛ اول وضعیت را پاک کنید.
• رمز/توکن اشتباه روی HTTPS، یا کلید SSH نادرست، شبیه «شبکه خراب است» به نظر می‌رسد.
• دو نفر بدون Pull طولانی روی یک Branch → واگرایی و Conflict بیشتر.

برای مدیر غیرفنی

وقتی می‌شنوید «هنوز Push نکرده»، یعنی کار روی ماشین فرد است و روی Remote تیم دیده نمی‌شود. وقتی «باید Pull کند»، یعنی نسخهٔ محلی‌اش عقب است. این واژه‌ها را در وضعیت پروژه به‌جای «پس چرا من نمی‌بینم؟» مبهم استفاده کنید.

جمع‌بندی

Push کار شما را با Remote به اشتراک می‌گذارد؛ Pull کار دیگران را وارد خط فعلی شما می‌کند؛ Fetch اطلاعات را بدون ادغام می‌آورد. با این سه، چرخهٔ همکاری روی GitHub یا هر هاست دیگر کامل می‌شود. عادت سالم: قبل از Push بزرگ، یک‌بار وضعیت Remote را Fetch کنید.

در مقالهٔ بعد، Branch را به‌عنوان خط موازی توسعه می‌بینید — جایی که Push/Pull روی featureها معنی‌دارتر می‌شود.

upstream و tracking را درست بفهمید

وقتی git push -u origin feature می‌زنید، Branch محلی به origin/feature وصل می‌شود. بعداً git status می‌گوید جلوتر یا عقب‌تر از همتای Remote هستید. این اطلاعات از همان tracking می‌آید. اگر tracking نباشد، باید همیشه نام Remote و Branch را صریح بدهید.

bash

git branch -vv git status -sb

اگر Branch را روی Remote Rename کردید، tracking محلی ممکن است کهنه بماند؛ با set-upstream-to اصلاحش کنید. گیج شدن اینجا منشأ خیلی از Pushهای ردشده است.

Fetch منظم؛ Pull آگاهانه

بعضی تیم‌ها عادت سالمی دارند: صبح git fetch --all --prune و بررسی وضعیت، بعد تصمیم برای Merge/Rebase. Pull خودکار همیشه بد نیست، ولی اگر نمی‌دانید Merge می‌کند یا Rebase (تنظیم pull.rebase)، ممکن است تاریخچه‌ای بسازید که انتظارش را ندارید.

prune ارجاع Branchهای حذف‌شده روی Remote را از لیست remote-tracking پاک می‌کند و از شلوغی می‌کاهد.

سناریوهای Conflict در Pull

اگر شما و همکارتان یک فایل را عوض کرده باشید، Pull ممکن است Conflict بدهد. مراحل:

1. آرام بمانید و status را بخوانید.
2. فایل‌ها را ویرایش و نشانگرها را کامل پاک کنید.
3. تست حداقلی.
4. add و اتمام Merge.
5. اگر اشتباه شد، merge --abort — به شرطی که وضعیت اجازه بدهد.

پیشگیری بهتر از درمان است: Pullهای کوتاه‌فاصله و تقسیم کار روی فایل‌های کمترهم‌پوشان.

Force Push — خط قرمزها

Force Push وقتی مطرح می‌شود که تاریخچهٔ محلی را بازنویسی کرده‌اید و Remote همان مسیر قبلی را دارد. روی Branch شخصی تازه گاهی با توافق مجاز است؛ روی main/shared معمولاً ممنوع. GitHub می‌تواند Force را مسدود کند. اگر مجبور شدید، با تیم هماهنگ کنید و از --force-with-lease به‌جای --force خام استفاده کنید تا کار دیگران را ندیده بازنویسی نکنید.

آموزش این مقاله عمداً Force را توصیهٔ روزانه نمی‌کند. اول مدل امن را یاد بگیرید.

Push بدون Deploy و Deploy بدون Push

ممکن است به Remote Push کنید ولی Pipeline خراب باشد و Production عوض نشود. ممکن است کسی مستقیماً روی سرور فایل بگذارد و Push در کار نباشد — ضدالگو. هدف تیم سالم این است که مسیر رسمی همیشه Push/Merge به Branch محافظت‌شده و سپس Deploy خودکار/کنترل‌شده باشد.

برای مدیر: وضعیت «روی GitHub هست» را با «روی Production هست» یکی ندانید؛ محیط‌ها را در مقالهٔ ۰۴۸ از هم جدا کردیم.

چک‌لیست پایان روز

• کار مهم Push شده یا آگاهانه فقط محلی مانده؟
• Branch فیچر با Remote tracking دارد؟
• main محلی عقب نیست؟
• Conflict باز یا Merge ناتمام نمانده؟

پنج دقیقه صرف این چک، صبح بعد را نجات می‌دهد.

پروتکل، credential و خطاهای احراز هویت

روی HTTPS، توکن یا credential helper جای رمز حساب را می‌گیرد (بسیاری از هاست‌ها دیگر رمز عبور خام را برای Git نمی‌پذیرند). روی SSH، عامل ssh-agent و کلید درست مهم است. خطای authentication را از خطای permission جدا کنید: اولی هویت، دومی دسترسی به آن مخزن.

توکن را در چت و اسکرین‌شات نگذارید. اگر لو رفت، فوراً revoke کنید — همان منطق مقالات Secret.

Push تگ و Release

تگ‌های Annotated برای نشانه‌گذاری نسخهٔ انتشار رایج‌اند. Push عادی همیشه تگ‌ها را نمی‌فرستد؛ باید صریح تگ یا --tags را Push کنید طبق سیاست. Release روی GitHub اغلب از تگ ساخته می‌شود. قبل از تگ زدن روی Commit اشتباه، با تیم هماهنگ کنید چون جابه‌جایی تگ منتشرشده گیج‌کننده است.

bash

git tag -a v1.2.0 -m "Release 1.2.0" git push origin v1.2.0

چند Remote و جریان Upstream

در Fork: origin معمولاً Fork شماست، upstream اصلی. جریان رایج: fetch upstream، Merge/Rebase روی Branch خود، Push به origin، PR به upstream. قاطی کردن Push به upstream بدون مجوز خطا یا رد دسترسی می‌دهد — و اگر مجوز داشته باشید ممکن است اشتباه مستقیم به اصلی بزنید.

نام Remote را در README تیم بنویسید تا کسی حدس نزند.

Pull با rebase — انتخاب آگاهانه

بعضی تیم‌ها pull.rebase را true می‌کنند تا تاریخچه خطی‌تر بماند. این انتخاب روی Branch مشترک Pushشده می‌تواند نیاز به Force ایجاد کند. پیش‌فرض Merge امن‌تر برای تازه‌کار است. هرچه انتخاب می‌کنید، در سند تیم یک جمله بنویسید تا هر کس یک طور نباشد.

اگر نمی‌دانید الان در وسط Merge/Rebase هستید، status را بخوانید؛ Git معمولاً می‌گوید下一步 چیست.

نشانه‌های سلامت همگام‌سازی

• صبح‌ها تعداد کمی «عقب از origin» روی main محلی.
• نبود Force Push روی Branchهای محافظت‌شده.
• PRها قبل از Merge با پایهٔ تازه.
• کاهش Conflictهای چندروزهٔ انباشته.

این‌ها را می‌توان بدون داشبورد گران دید. اگر همه مدام غافلگیر می‌شوند، ریتم Fetch/Pull را اصلاح کنید نه اینکه فقط ابزار UI عوض کنید.

همگام‌سازی در تیم‌های نیمه‌وقت و توزیع‌شده

وقتی هم‌زمانی کم است، واگرایی بیشتر می‌شود. قانون ساده: قبل از شروع کار معنادار Pull/Fetch کنید؛ قبل از پایان روز Push کنید اگر کار قابل اشتراک است. کار نیمه‌تمام خطرناک را روی Branch شخصی Push کنید تا لپ‌تاپ تنها کپی نباشد — ولی با پیام WIP روشن.

در مناطق با اینترنت ناپایدار، Commit محلی همچنان پیش می‌رود؛ Push را وقتی شبکه پایدار شد انجام دهید. Git برای همین توزیع‌شده طراحی شده است. فقط مراقب باشید هفته‌ها بدون Push نمانید که پشتیبان از بین برود.

اگر دو نفر روی یک Branch مشترک Push می‌کنند، توافق کنید چه کسی Merge Conflict را نهایی می‌کند. Branch شخصی + PR معمولاً برای تیم توزیع‌شده کم‌اصطکاک‌تر از یک Branch مشترک شلوغ است.

ابزار چت را جایگزین Push ندانید: فرستادن پچ در پیام‌رسان تاریخچه را دور می‌زند و ممیزی را می‌کشد.

جدول Troubleshoot Push/Pull

قبل از کپی کردن فرمان‌های خطرناک از اینترنت، پیام را با این جدول تطبیق دهید. بیشتر مواقع راه‌حل ملایم وجود دارد. Force آخرین گزینه است نه اولین.

عادت پایانی: بعد از Push، یک‌بار در UI Remote همان Commit را ببینید. این تأیید بصری اشتباهات remote غلط را زود لو می‌دهد.

پیوند Push/Pull با Branch و Merge

Push وقتی روی feature Branch است کم‌ریسک‌تر از Push مستقیم به main است. Pull روی main قبل از ساخت Branch جدید، پایه را تازه می‌کند. Merge Conflictها اغلب نتیجهٔ Pull نکردن به‌موقع‌اند نه بدشانسی. این سه فرمان را با هم ببینید نه جدا.

در اسکرام دو هفته‌ای، یک آیین روزانهٔ کوتاه «همگام شدی؟» در استندآپ کافی است تا کسی سه روز آفلاین از Remote نماند. ابزار چت را برای یادآوری بگذارید؛ منبع حقیقت همان Remote باشد.

اگر Pipeline روی Push به Branch خاص Deploy می‌کند، بدانید هر Push می‌تواند اثر عملیاتی داشته باشد. نام Branch و محیط را در سند استقرار روشن کنید تا کسی اشتباهی به Branch حساس Push نکند.

جمع این صفحه: Push برای اشتراک، Pull برای هم‌ترازی، Fetch برای مشاهده بدون تعهد. با این سه، از انزوای محلی به کار تیمی می‌رسید.

یادداشت پایانی همگام‌سازی

اگر امروز فقط یک تغییر در عادت بدهید، این باشد: قبل از شروع کار Fetch یا Pull کنید و قبل از ترک میز، کار قابل‌اشتراک را Push کنید. همین دو نقطه، نصف غافلگیری‌های هفته را حذف می‌کند و تیم را روی یک حقیقت مشترک نگه می‌دارد.

منابع و مراجع

• GitHub Docs — Pushing commits to a remote repository — https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository
• GitHub Docs — Getting changes from a remote repository — https://docs.github.com/en/get-started/using-git/getting-changes-from-a-remote-repository
• git-push documentation — https://git-scm.com/docs/git-push
• git-pull documentation — https://git-scm.com/docs/git-pull
• Pro Git — Working with Remotes — https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes
• GitHub Docs — About Git — https://docs.github.com/en/get-started/using-git/about-git