سیستم ورژن کنترل گیت توسط لینوس توروالدز (خالق کِرنِل لینوکس) به منظور توسعهٔ لینوکس به صورت گروهی خلق شد چرا که در آن بازه بسیاری از توسعه‌دهندگان لینوکس از استفادهٔ‌ سیستم کنترل نسخهٔ BitKeeper امتناع ورزیدند. در حقیقت، لینوس توروالدز تمایل داشت تا از یک سیستم توزیع‌شده همچون BitKeeper استفاده کند اما هیچ کدام از نرم‌افزارهایی که تا زمان به بازار عرضه شده بودند نیازش را مرتفع نمی‌ساختند و همین شد که توسعهٔ‌ Git در سوم آوریل 2005 شروع شد. واژهٔ Git در زبان کوچه و بازار بریتانیا به معنای «آدم نَچسب» است و وجه‌تسمیهٔ این سیستم نیز از آن سو است که لینوس توروالدز در جایی گفته است که «... من پروژه‌هایم را از روی شخصیتم نام‌گذاری می‌کنم!»

درآمدی بر مزایای سیستم کنترل نسخهٔ Git

پیش از این توضیح دادیم که انواع و اقسام سیستم‌های کنترل نسخه توسط شرکت‌های مختلف نرم‌‌افزاری به دنیا عرضه شده‌اند که یکی از محبوب‌ترین آن‌ها گیت می‌باشد اما ممکن است این پرسش شکل گیرد که «چرا گیت را باید انتخاب کنیم؟» که در پاسخ به چنین پرسشی می‌توان گفت که گیت این امکان را در اختیار توسعه‌‌دهندگان قرار می‌دهد تا حتی به صورت آفلاین نیز بتوانند دست به نسخه‌بندی پروژهٔ خود بزنند.

همچنین علیرغم گستردگی گیت، صرفاً‌ با فراگیری تعداد معدودی از کامندها می‌توان شروع به استفاده از این ابزار نمود مضاف بر این که به دلیل استفادهٔ پروژه‌های اپن‌سورس مطرحی همچون Linux Kernel یا فریمورک Ruby on Rails از این ابزار، مسلماً کامیونیتی بزرگی در حال استفاده از گیت می‌باشد و همین مسئله‌ این تضمین را ایجاد می‌کند که در صورت بروز هر گونه مشکلی در حین استفاده از این ابزار،‌ به سادگی بتوان در سایت‌هایی همچون اِستک‌اورفلو پاسخ‌های فراوانی برای پرسش‌های احتمالی خود یافت.

درآمدی بر اصطلاحات رایج در Git

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

Repo: این اصطلاح برگرفته از واژهٔ Repository به معنی «مخزن» یا «منبع» است. به عبارتی،‌ چنانچه پروژه‌ای داشته‌ باشیم با نامی فرضی همچون sokan-site که با استفاده از ابزار گیت قصد داریم آن را مدیریت کنیم، این پوشه تحت عنوان یک ریپو یا ریپازیتوری شناخته خواهد شد.
Clone: چنانچه بخواهیم یک ریپازیتوری آنلاین را دریافت نموده و روی سیستم لوکال خود شروع به کار روی آن نماییم، نیاز است تا ابتدا به ساکن کل پروژه را دانلود نماییم که به این کار کلون کردن گفته می‌شود.
Stage: به منظور درک بهتر این اصطلاح، مثالی از زندگی روزمره می‌زنیم. فرض کنیم که قصد فروش یک خودرو را داریم و از همین روی آن را به کارواش برده و خودروی خود را آمادهٔ فروش می‌‌کنیم. با مد نظر قرار دادن این توضیحات، در سیستم گیت اِستِیج کردن پروژه بدان معنا است که قصد داریم تا تغییراتی که در سورس‌کد پروژهٔ خود اِعمال نموده‌ایم را آماده سازیم تا در تاریخچهٔ تغییرات گیت ذخیره گردند. به عبارت دیگر، با اِستِیج کردن پروژه به سیستم می‌فهمانیم که قصد داریم کدام فایل‌ها و فولدرها به عنوان یک نسخهٔ جدید از پروژه ذخیره گردند (تصور کنیم در ریپازیتوری sokan-site که پیش از این پیرامونش صحبت کردیم، یکصد فایل جدید اضافه نموده‌ایم اما فقط و فقط قصد داریم تا ده مورد از آن‌‌ها را در تاریخچهٔ تغییرات پروژه ذخیره‌ سازیم که این کار در گیت با کامند خاصی انجام می‌شود و به کل این پروسه «اِستیجینگ» گفته می‌شود.)
Commit: پیش از این توضیح دادیم که سیستم‌های ورژن کنترلی همچون گیت همچون یک سیستم بک‌آپ عمل می‌کنند به طوری که نسخه‌های مختلفی از فایل‌ها و فولدرهای پروژه‌ را ذخیره خواهند کرد. اساساً برای آن که بتوانیم دست به نسخه‌بندی ریپازیتوری خود بزنیم، نیاز است تا در صورت اِعمال هر گونه تغییری آن را به اصطلاح کامیت نماییم. معنی لغوی این اصطلاح «مرتکب شدن» است اما در فضای سیستم‌های کنترل نسخه می‌توان معادلی همچون «ذخیره کردن تغییرات» برایش در نظر گرفت (در واقع می‌توان به نوعی آن را معادل کلیدهای ترکیبی Ctrl + S تلقی کرد.)
Push: چنانچه بخواهیم علاوه بر داشتن یک ریپازیتوری به صورت آفلاین آن را در سرویس‌های مطرحی همچون گیت‌هاب یا گیت‌لَب نیز ذخیره‌ سازیم،‌ نیاز به ارسال کلیهٔ‌ فایل‌ها و فولدرهای پروژه روی یک ریپازیتوری آنلاین داریم که به این فرآیند «پوش» گفته می‌شود.
Pull: در صورتی که بخواهیم تغییراتی که سایر دولوپرها روی یک ریپازیتوری آنلاین همچون گیت‌هاب انجام داده‌اند را دریافت کنیم، نیاز به دریافت تغییرات داریم که به این فرآیند «پول» گفته می‌شود.
Pull Request: اگر هم روی یک ریپازیتوری عمومی همچون کِرنِل لینوکس کار می‌کنیم و فرضاً تغییری در آن داده‌ایم و یا باگی را فیکس کرده‌ایم، نیاز است تا توسعه‌دهندهٔ اصلی کِرنِل را از این موضوع مطلع سازیم تا پس از بررسی تغییراتی که توسط ما صورت گرفته از یکسو و همچنین چنانچه مورد تأیید بودند از سوی دیگر، آن‌ها را با شاخهٔ اصلی ادغام نماید که به چنین درخواستی اصطلاحاً «پول ریکوئست» گفته می‌شود.
Branch: معنی لغوی این اصطلاح «شاخه» است و به نظر می‌رسد که نامی باسمی‌ برای این قابلیت گیت انتخاب شده است. به عبارتی، هر ریپازیتوری یک شاخهٔ اصلی دارد که تحت عنوان Master شناخته می‌شود اما این در حالی است که تک‌تک اعضای تیم می‌توانند شاخه‌هایی با نام‌هایی کاملاً دلخواه از شاخهٔ اصلی جدا کرده و شروع به کار روی آن‌ها کنند و در نهایت دولوپر اصلی پروژه می‌تواند شاخه‌های فرعی را، در صورت تأیید شدن، با شاخهٔ اصلی ادغام نماید.
Merge: همان‌طور که پیش از این توضیح داده شد، چنانچه در یک ریپازیتوی علاوه بر شاخهٔ اصلی شروع به ساخت یک سری شاخهٔ‌ فرعی نماییم،‌ در نهایت نیاز است تا کلیهٔ شاخه‌‌های فرعی با شاخهٔ به اصطلاح مَستر ادغام شوند که به این پروسه «مِرج» گفته می‌شود.

آشنایی با تاریخچه، مزایا و برخی اصطلاحات رایج در Git