Git چیست؟ ساده‌تر از چیزی که اسمش به نظر می‌رسد

Git یه Version Control System یا همون سیستم کنترل نسخه است. اگه این اصطلاح در نگاه اول کمی فنی به نظر میاد، نگران نباشید؛ اصل ماجرا خیلی ساده‌تره.

تصور کنید چند هفته روی یه سایت یا نرم‌افزار کار کردید. توی این مدت فایل‌ها بارها تغییر کردن، قابلیت‌های جدید اضافه شدن، چند بخش حذف شده و احتمالاً چندتا باگ هم برطرف کردید.

حالا اگه یه روز متوجه بشید تغییری که سه روز قبل انجام دادید باعث یه مشکل شده، چی؟ از کجا باید بفهمید دقیقاً چه چیزی تغییر کرده بود؟

اینجاست که Git وارد ماجرا میشه. Git کمک می‌کنه مسیر تغییرات پروژه گم نشه. یعنی فقط نسخه‌ای که همین الان جلوی شماست مهم نیست؛ می‌تونید ببینید پروژه قبلاً چه وضعیتی داشته و چطور به نسخه فعلی رسیده.

اصلاً چرا برنامه‌نویس‌ها به Git نیاز دارند؟

توی پروژه‌های خیلی کوچیک شاید نبود Git اصلاً احساس نشه. چند فایل دارید، تغییرات محدوده و همه‌چیز هم دست خودتونه. ولی پروژه که یه مقدار جدی‌تر بشه، داستان فرق می‌کنه.

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

روش سنتی اینه که از پروژه چندتا کپی بگیرید: «نسخه قبلی»، «نسخه جدید»، «نسخه آخر»، «نسخه آخر واقعی» و احتمالاً چند پوشه دیگه که بعد از مدتی خودتون هم نمی‌دونید کدومشون واقعاً آخرین نسخه بوده!

Git دقیقاً برای جلوگیری از همین بی‌نظمی ساخته شده. به جای نگهداری چندین کپی پراکنده، تغییرات پروژه به شکل منظم داخل یه تاریخچه قرار می‌گیرن.

Version Control چیست و چه ارتباطی با Git دارد؟

Version Control یعنی تغییرات یه پروژه در طول زمان قابل مدیریت و پیگیری باشن. به جای اینکه فقط آخرین فایل‌ها رو داشته باشید، می‌دونید قبل از این چه اتفاقی افتاده.

مثلاً می‌تونید بفهمید یه فایل چه زمانی تغییر کرده، چه بخشی بهش اضافه شده یا یه قابلیت در چه مرحله‌ای وارد پروژه شده.

این موضوع توی کار تیمی حتی مهم‌تره. وقتی چند نفر روی یه پروژه کار می‌کنن، فقط دونستن اینکه «فایل تغییر کرده» کافی نیست؛ مهمه بدونیم چه کسی و با چه هدفی اون تغییر رو انجام داده.

Git یکی از ابزارهایی هست که این مدیریت نسخه رو خیلی سریع و قابل اعتماد وارد روند توسعه نرم‌افزار کرده.

چرا به Git سیستم کنترل نسخه توزیع‌شده می‌گویند؟

گاهی کنار اسم Git عبارت Distributed Version Control System رو می‌بینید. معنیش اینه که Git برای کار کردن کاملاً وابسته به یه سرور مرکزی نیست.

وقتی یه توسعه‌دهنده پروژه Git رو روی سیستم خودش داره، معمولاً فقط فایل‌های آخر پروژه رو نداره؛ بخش مهمی از تاریخچه پروژه هم همراهشه.

در نتیجه خیلی از کارها رو میشه روی همون سیستم انجام داد و لازم نیست برای هر بررسی کوچیکی ارتباط دائمی با یه سرور وجود داشته باشه.

شاید این ویژگی برای یه تازه‌کار خیلی مهم به نظر نرسه، ولی وقتی پروژه‌ها بزرگ‌تر میشن، مزیت این مدل بیشتر خودش رو نشون میده.

Repository در Git چیست؟

یکی از اولین اصطلاح‌هایی که بعد از آشنا شدن با Git می‌بینید Repository یا همون Repoـه.

ساده‌ترین توضیح اینه که Repository همون پروژه‌ایه که Git داره تغییراتش رو دنبال می‌کنه. فایل‌های پروژه اونجا هستن و تاریخچه تغییرات هم به همون پروژه مربوط میشه.

برای مثال یه توسعه‌دهنده ممکنه یه Repository برای سایت شخصیش داشته باشه، یه مورد برای پروژه محل کار و یه Repository دیگه برای پروژه‌ای که صرفاً برای تمرین ساخته.

پس وقتی جایی می‌شنوید «Repository پروژه»، منظور فقط یه پوشه عادی نیست؛ پروژه‌ایه که تغییراتش تحت مدیریت Git قرار گرفته.

Commit در Git چیست؟

Commit رو میشه یه جور نقطه ثبت‌شده در مسیر عمر پروژه در نظر گرفت.

فرض کنید چند ساعت روی یه قسمت از برنامه کار کردید و حالا اون بخش به وضعیت خوبی رسیده. وقتی این مرحله داخل تاریخچه Git ثبت میشه، بعداً می‌تونید بفهمید پروژه در اون نقطه چه وضعیتی داشته.

طبیعتاً یه پروژه واقعی فقط یه Commit نداره. با ادامه توسعه، Commitهای مختلف پشت سر هم شکل می‌گیرن و در نهایت یه تاریخچه نسبتاً دقیق از رشد پروژه ساخته میشه.

همین تاریخچه بعدها موقع پیدا کردن مشکلات، بررسی تغییرات یا حتی فهمیدن دلیل یه تصمیم قدیمی خیلی به درد تیم می‌خوره.

Branch در Git چیست و چرا این‌قدر مهم است؟

فرض کنید سایت الان کاملاً سالمه، ولی می‌خواید یه قابلیت جدید و نسبتاً بزرگ بهش اضافه کنید. طبیعتاً دوست ندارید وسط کار نسخه اصلی سایت رو خراب کنید.

Branch دقیقاً اینجا به کار میاد. به جای اینکه تغییرات جدید مستقیم روی مسیر اصلی انجام بشن، یه شاخه جدا ساخته میشه و کار داخل اون ادامه پیدا می‌کنه.

اگه قابلیت جدید خوب از آب دراومد، بعداً میشه اون رو دوباره وارد نسخه اصلی کرد. اگه هم تصمیم گرفتید کنارش بذارید، نسخه اصلی همچنان سالم و دست‌نخورده باقی مونده.

این مدل کار کردن هم برای پروژه‌های شخصی مفیده و هم وقتی چند برنامه‌نویس به شکل هم‌زمان روی قسمت‌های مختلف یه نرم‌افزار کار می‌کنن.

Merge در Git چیست؟

Branchها معمولاً برای همیشه جدا نمی‌مونن. اغلب یه شاخه برای انجام یه کار مشخص ساخته میشه و بعد از اینکه کار تموم شد، تغییراتش باید وارد مسیر اصلی پروژه بشه.

به این ترکیب شدن تغییرات Merge گفته میشه.

مثلاً ممکنه یه نفر روی صفحه پرداخت کار کنه و یه نفر دیگه روی پنل کاربری. هر کدوم می‌تونن مسیر خودشون رو داشته باشن و بعد از کامل شدن کار، تغییرات رو با پروژه اصلی ترکیب کنن.

این دقیقاً همون چیزیه که باعث میشه Git برای تیم‌های چندنفره تا این حد کاربردی باشه.

Merge Conflict چیست؟ وقتی دو تغییر با هم جور درنمی‌آیند

گاهی دو برنامه‌نویس دقیقاً روی یه قسمت مشابه از پروژه کار می‌کنن. مثلاً هر دو نفر یه بخش مشخص از یه فایل رو تغییر دادن.

وقتی زمان ترکیب تغییرات می‌رسه، Git همیشه نمی‌تونه خودش تشخیص بده کدوم تغییر باید نگه داشته بشه.

این وضعیت با اسم Merge Conflict شناخته میشه.

اسم Conflict شاید کمی ترسناک باشه، ولی در اصل فقط یعنی Git تصمیم رو به برنامه‌نویس سپرده. توسعه‌دهنده بررسی می‌کنه و مشخص می‌کنه نسخه نهایی باید چه شکلی باشه.

Git در کار تیمی چه کاربردی دارد؟

قدرت واقعی Git معمولاً وقتی بهتر دیده میشه که چند نفر هم‌زمان روی یه پروژه کار کنن.

فرض کنید پنج برنامه‌نویس دارن یه فروشگاه اینترنتی رو توسعه میدن. یکی روی پرداخت کار می‌کنه، یکی بخش محصولات رو می‌سازه، یه نفر API رو تغییر میده و یه نفر دیگه مشغول پنل مدیریت شده.

اگه قرار باشه فایل‌ها دائماً برای هم ارسال بشن، خیلی زود یه سؤال ساده به وجود میاد: آخرین نسخه دست کیه؟

Git کمک می‌کنه تغییرات هر نفر مشخص باشه و اعضای تیم مجبور نباشن برای هر تغییر کل پروژه رو دوباره بین خودشون جابه‌جا کنن.

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

تفاوت Git و GitHub چیست؟

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

اما Git خود سیستم کنترل نسخه است. یعنی همون ابزاری که تاریخچه و تغییرات پروژه رو مدیریت می‌کنه.

در مقابل، GitHub یه پلتفرم آنلاین برای میزبانی پروژه‌های Gitـه. یعنی می‌تونید Repository رو اونجا نگهداری کنید، با بقیه به اشتراک بذارید و همکاری تیمی رو ساده‌تر کنید.

اگه بخوایم خیلی خلاصه بگیم: Git ابزار مدیریت نسخه است؛ GitHub یکی از جاهایی است که پروژه‌های Git می‌توانند روی آن قرار بگیرند.

تفاوت Git و GitHub در یک نگاه

آیا Git فقط با GitHub کار می‌کند؟

نه. Git و GitHub دو چیز مستقل هستن و استفاده از Git شما رو مجبور نمی‌کنه حتماً پروژه‌تون رو روی GitHub قرار بدید.

سرویس‌های دیگه‌ای مثل GitLab و Bitbucket هم وجود دارن که می‌تونن Repositoryهای Git رو میزبانی کنن.

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

پس بهتره اول Git رو به عنوان مفهوم اصلی بشناسیم و GitHub رو یکی از ابزارهای اطراف این اکوسیستم بدونیم.

آیا Git بدون اینترنت هم کار می‌کند؟

بله. برخلاف چیزی که خیلی از تازه‌کارها تصور می‌کنن، Git الزاماً یه ابزار آنلاین نیست.

بخش مهمی از اطلاعات Repository و تاریخچه پروژه روی سیستم خود توسعه‌دهنده قرار داره. برای همین خیلی از کارهای مربوط به Commitها، Branchها و بررسی تاریخچه بدون اینترنت هم قابل انجامه.

وقتی بخواید پروژه رو با یه سرور یا سرویس آنلاین همگام کنید، اون موقع طبیعتاً اینترنت وارد ماجرا میشه.

همین موضوع هم یکی از ویژگی‌های مهم ساختار توزیع‌شده Git محسوب میشه.

Git چه فایده‌ای برای یه برنامه‌نویس دارد؟

Git فقط برای شرکت‌هاست یا پروژه شخصی هم به درد می‌خورد؟

یکی از تصورهای اشتباه اینه که Git فقط برای تیم‌های بزرگه. در حالی که حتی اگه تنها برنامه‌نویس پروژه باشید، باز هم داشتن تاریخچه تغییرات می‌تونه خیلی مفید باشه.

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

Git کمک می‌کنه این تغییرات تبدیل به یه مسیر قابل پیگیری بشن، نه یه مجموعه فایل پراکنده که بعداً خودتون هم نتونید پیداشون کنید.

پس حتی اگه فعلاً هیچ تیمی ندارید، استفاده از Git روی پروژه شخصی کاملاً معنی داره.

Git برای Front-end است یا Back-end؟

هیچ‌کدوم؛ یا بهتره بگیم برای هر دو. Git به حوزه خاصی از برنامه‌نویسی محدود نیست.

Front-end Developer می‌تونه پروژه خودش رو با Git مدیریت کنه، Backend Developer هم همین‌طور.

برنامه‌نویس Python، JavaScript، PHP، Java، C#، توسعه‌دهنده اپلیکیشن موبایل یا حتی کسی که روی پروژه‌های سیستمی کار می‌کنه هم می‌تونه از Git استفاده کنه.

Git بیشتر از اینکه به یه زبان برنامه‌نویسی مربوط باشه، به خود فرآیند توسعه نرم‌افزار مربوطه.

Git همون Backup گرفتن از پروژه است؟

نه. این دو ممکنه یه جاهایی شبیه به نظر برسن، ولی هدف اصلیشون با هم فرق داره.

Git برای نگهداری تاریخچه و مدیریت تغییرات ساخته شده. اما Backup بیشتر برای اینه که اگه اطلاعات اصلی از بین رفت، یه نسخه امن برای بازیابی وجود داشته باشه.

پس حتی اگه پروژه Git داشته باشه، بهتره Git رو به عنوان جایگزین کامل سیستم Backup در نظر نگیریم.

Git برای یه برنامه‌نویس تازه‌کار سخت نیست؟

اوایلش ممکنه همین‌طور به نظر برسه. Repository، Commit، Branch، Merge، Conflict... چندتا اصطلاح جدید پشت سر هم وارد ماجرا میشن.

اما وقتی بفهمید هر کدوم چه مشکلی رو حل می‌کنن، قضیه خیلی ساده‌تر میشه.

مشکل معمولاً زمانی شروع میشه که کسی قبل از فهمیدن خود Git، مستقیم میره سراغ حفظ کردن تعداد زیادی دستور. اون موقع همه‌چیز بی‌دلیل پیچیده به نظر میاد.

اگه اول مفهوم Version Control، Repository، Commit و Branch رو خوب بفهمید، بقیه مسیر Git خیلی قابل فهم‌تر میشه.

از چه زمانی باید Git را یاد بگیریم؟

لازم نیست همون روز اول برنامه‌نویسی خودتون رو درگیر همه جزئیات Git کنید.

ولی وقتی از تمرین‌های چند خطی عبور کردید و شروع کردید پروژه واقعی بسازید، دیگه زمان خوبیه که Git هم وارد روند کارتون بشه.

حتی یه سایت یا اپلیکیشن شخصی کوچیک می‌تونه محیط خوبی برای آشنا شدن با Version Control باشه.

اینطوری وقتی بعداً وارد یه تیم برنامه‌نویسی می‌شید، Git براتون یه مفهوم کاملاً غریبه نیست.

مهم‌ترین اصطلاحات Git به زبان ساده

سوالات متداول درباره Git