تفاوت Git Pull با Git Fetch

مقدمه

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

نحوه کار کردن گیت

خب قبل از بررسی تفاوت این دو دستور بزارید ببینیم git چطور کار میکنه. گیت در حالت کلی روی سه نسخه از پروژه شما کار میکنه (شاید بشه گفت Copy). خوب این سه تا نسخه چی هستن.

• staging area
• local repository
• remote repository

حالا باید ببینیم این نسخه‌ها چی هستند. ولی قبل اون یه نکته رو فراموش نکنید؛ این نسخه‌ها همشون مربوط میشن به کامپیوتر شما و هیچ ربطی به هیچ جای دیگه‌ای ندارن. در ادامه توضیح میدم که این‌ها کجا ذخیره میشن.

1. نسخه staging area

شاید کلمه staging رو تو git status دیده باشید. وقتی میگیم یه فایل رفته تو محدوده staging (یا همون Staging area) به این معنیه که گیت روی اون فایل نظارت داره و تغییراتش رو بررسی میکنه. وقتی شما یه فایل رو git add میکنی اون فایل میره به staging area و بعد اون هست که وقتی git status میزنید به شما نشون میده که این فایلی دارید الان تغییر کرده یا هر چیز دیگه‌ای. اما بعد از این که یه تغییری رو commit میکنیم چه اتفاقی میوفته؟ خب این رو تو مرحله بعد بررسی میکنیم.

2. نسخه local repository

بعد از مرحله staging وقتی یه سری تغییرات رو commit میکنیم، گیت میاد و این تغییرات رو توی جایی به
نام local repository ذخیره میکنه. اینجا دقیقا همون جاییه که branchها و commitهای شما ذخیره میشن. و احتمالا وقتی شما روی فایلی تغییرات ایجاد میکنی git گیت میاد و تغییرات این فایل رو با آخرین کامیت مقایسه میکنه و میبینه تو این خط‌ها تغییرات ایجاد شده. (قطعا داستان یکم پیچیده‌تر از این حرفاست)

3. نسخه remote repository

خب این نسخه یا copy از پروژه شما اطلاعات مربوط به repository که اون رو به صورت remote به git معرفی کردید رو تو خودش ذخیره میکنه. بزارید با یه مثال توضیح بدم. فرض کنید یه پروژه ماشین حساب دارید و میخواید اون رو به صورت open source بزارید تو GitHub. واسه این کار اول پروژتون رو تو ماشین خودتون درست میکنید، و بعد اون میرید تو GitHub و یه repository می‌سازید. بعد با استفاده از دستور زیر پروژتون رو به GitHub متصل می‌کنید.

git remote add origin https://github.com/repisitory-url

خب اینجا چه اتفاقی میوفته؟ اتفاقی که میوفته اینه که git میاد و copy از پروژه درست میکنه اون رو با پروژه‌ای که تو GitHub درست کردید مرتبط میکنه. منظور از مرتبط کردن اینه که اطلاعات این copy از طریق commit کردن تغییر نمیکنه.

عکس زیر به خوبی نحوه کار گیت رو ترسیم کرده.

گیت خیلی شبیه به عکس بالا کار میکنه اما خوب زمانی که pull یا fetch انجام میدیم چه اتفاقی میفته؟ با دیدی که الان نسبت به گیت پیدا کردیم الان خیلی راحت می‌تونیم این قضیه رو درک کنیم.

دستور Git Fetch

وقتی دستور Git fetch رو اجرا می‌کنیم اتفاقی که میفته اینه که git میره و اطلاعات رو از روی remote (که میتونه یه repository تو GitLab یا GitHub باشه) میگیره و اون اطلاعات رو نسخه remote repository ذخیره میکنه. نکتش اینه که نسخه staging area و نسخه local repository هیچ تغییری نمیکنن. یعنی بعد fetch کردن، کدتون هیج تغییری نمیکنه. خب اگه بخوایم تغییرات رو دریافت کنیم چیکار باید بکنیم؟ بزارین جواب این سوال رو تو مرحله بعد بدیم.

دستور Git Pull

خب pull هم دقیقا مثل fetch میره و اطلاعات رو از روی remote میگیره و اون اطلاعات رو نسخه remote repository ذخیره میکنه، بعد از اون میاد اطلاعات نسخه remote repository رو با نسخه local repository مرج میکنه. واسه همینه که شما بلافاصله بعد از pull کردن تغییرات رو تو کدتون دریافت میکنید. عکس زیر میتونه خیلی خوب تفاوت این دو دستور رو نشون بده.

همونطور که تو عکس هم میبینید git pull همون git fetch هست که بعد از عملیات fetch محتویات remote branch رو با local branch مرج میکنه. در واقع انگار دستور:

git pull origin master

مساویه با:

git fetch
git merge origin/master

کدوم گزینه رو انتخاب کنیم؟

خب وقتی دارید تو یه پروژه کار می‌کنید نسبت به نیازتون از این دو دستور استفاده می‌کنید اما من به شخصه زمانی که رو یه برنچ هستم مثلا master و میخوام اطلاعات اون برنچ رو اپدیت کنم از پول استفاده می‌کنم. و زمانی که از اطلاعاتی که قراره مرج بشه اطمینان ندارم اول اون رو fetch می‌کنم و بعد اون رو مرج می‌کنم. یک سناریو دیگه هست که بزارید با یه مثال توضیحش بدم.

مثلا فرض کنید که دارید رو برنچ master یه پروژه کار می‌کنید و دوستتون بهتون میگه که من یک سری باگ‌ رو روی برنچ bug پوش کردم لطفا اینارو بررسی کن و بعد با برنچ master مرجش کن. نکته داستان اینجاست که اگه شما تو برنچ master باشی و دستور زیر رو بزنی:

git pull origin bug

گیت میره و اطلاعات برنچ bug رو میگیره با برنچ که داریم روش کار می‌کنیم مرج میکنه. خب این چیزی نبود که ما می‌خواستیم، ما می‌خواستیم اطلاعات رو بررسی کنیم اگر همه چیز اوکی بود بعد با master مرجش کنیم. خب اینجا هم می‌تونیم از fetch استفاده کنیم کافیه که دستور زیر رو وارد کنیم:

git fetch

و بعدش:

git checkout bug 

و بعد این که کدهارو بررسی کردیم بریم و برنچ master رو با bug مرج کنیم.

نتیجه‌گیری

تو این مقاله برای این که بتونیم دوتا دستور fetch و pull رو عمیقا متوجه بشیم تا یه حدودی ساختار git رو بررسی کردیم و بعد این دو دستور رو مورد بررسی قرار دادیم. fetch فقط اطلاعات رو از سمت remote دریافت میکنه درصورتی که pull این اطلاعات رو با برنچ local مرج میکنه.

امیدوارم این مقاله براتون مفید بوده باشه. اگر دوست دارید می‌تونید این مقاله رو لایک کنید و لطفا برای بهبود این مقاله نظراتتون رو با من به اشتراک بگذارید.

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

https://github.com/payam-zahedi

و صفحه من در لینکدین:

https://www.linkedin.com/in/payam-zahedi/

منابع

1. Git - git-pull Documentation

2. Git - git-fetch Documentation

3. version control - Stack Overflow

4. Git Fetch vs Pull - freecodecamp

5. Git tower