VCS یا کنترلِ نسخه، سیستمی است که تغییرات را در فایل یا دسته‌ای از فایل‌ها ذخیره می‌کند و به شما این امکان را می‌دهد که در آینده به نسخه و نگارش خاصی برگردید.
اگر شما یک گرافیست یا طراح وب هستید و می‌خواهید نسخه‌های متفاوت از عکس‌ها و قالب‌های خود داشته باشید، استفاده از یک Version Control System یا سیستمِ کنترلِ نسخه انتخاب درستی است. VCS به شما این امکان را می‌دهد که فایل‌های انتخابی یا کل پروژه را به یک حالت قبلی خاص برگردانید، روند تغییرات را بررسی کنید، ببینید چه کسی آخرین بار تغییری ایجاد کرده که احتمالاً مشکل آفرین شده، چه کسی و چه وقت مشکلی را اعلام کرده و موارد کاربردی دیگر.
همچنین استفاده از VCS به این معناست که اگر شما در حین کار چیزی را خراب کردید و یا فایل‌هایی از دست رفت، به سادگی می‌توانید کارهای انجام شده را بازیابی نمایید. همچنین مقداری سربار به فایل‌های پروژه‌تان افزوده می‌شود.
هر چیزی در گیت قبل از اینکه ذخیره شود چک‌سام و سپس متعاقباً با آن چک‌سام فراخوانی می‌شود. این بدان معناست که غیرممکن است که محتوای فایل یا پوشه‌ای را بدون اینکه گیت متوجه شود ویرایش کنید. این کارکرد درون گیت و در پایین‌ترین مرتبه‌ها ساختار یافته و با تاروپود فلسفه‌اش همراه است. ممکن نیست که شما اطلاعات را حین انتقال یا بر اثر خرابی از دست بدهید بدون اینکه گیت آن را تشخیص دهد.
وقتی که کاری در گیت می‌کنید، تقریباً تمام آن افزودن به اطلاعات درون پایگاه‌داده گیت است. به بیان دیگر، انجام کاری که سیستم نتواند آن را بازگردانی کند یا اجبار آن به پاک‌سازی کامل اطلاعات به هر نحو بسیار دشوار است. اما در هر VCS دیگر، شما می‌توانید تغییراتی که هنوز کامیت نکرده‌اید بهم بریزید یا از دست بدهید، اما بعد از اینکه یک اسنپ‌شات به گیت کامیت کردید، از دست دادن آن بسیار مشکل است، بخصوص اگر به طور منظم پایگاه‌داده‌تان را به مخزنی دیگر پوش (Push) کنید.
برای آشنایی بیشتر با این مفهوم می‌توانید از لینک زیر استفاده کنید:
برای استفاده از امکانات Git در محیط Terminal یا CMD، باید برنامه‌ی Git را دانلود و نصب کنید که برخی از IDEها نیز برای اینکه امکانات این ابزار را در قالبی گرافیکی در اختیار کاربر بگذارند، به عنوان پیشنیاز به این برنامه نیاز دارند، پس پیشنهاد می‌شود فارغ از ترجیحات، این نرم‌افزار را نصب کنید.
ابزار دیگری که امکانات Git را در قالبی گرافیکی در اختیار شما می‌گذارد نرم‌افزار GitHub Desktop می‌باشد که با داشتن اکانت GitHub می‌توانید از امکانات آن بهره‌مند شوید.
برای آشنایی بیشتر با این مفهوم می‌توانید از لینک زیر استفاده کنید:
اطلاعات درون گیت می‌توانند سه وضعیت داشته باشند: ویرایش شده، استیج شده و کامیت شده.
- ویرایش‌شده یا Modified به این معناست که شما تغییری در فایل ایجاد کرده‌اید اما هنوز آن را به پایگاه داده خود کامیت نکرده‌اید.
- استیج‌شده یا Staged به این معناست که شما ویرایشی در نسخه حال فایل را علامت‌گذاری کرده‌اید تا به اسنپ‌شاتِ کامیت بعدی شما اضافه شود.
- کامیت‌شده یا Committed به این معناست که اطلاعات با امنیت کامل در پایگاه‌داده محلی شما ذخیره شده‌اند.
البته وضعیت «دنبال نشده» نیز داریم که به معنی عدم حضور داده در Git می‌باشد، ولی این وضعیت از دیدگاهی میان «وضعیت داده‌ها در گیت» طبقه‌بندی نمی‌شود.
برای آشنایی بیشتر با این مفهوم می‌توانید از لینک زیر استفاده کنید:
برای ایجاد پروژه می‌توان یکی از دو مسیر زیر را دنبال کرد:
- یک پوشۀ جدید ایجاد کنید
- Terminal یا CMD را باز کرده و به پوشه مورد نظر وارد شوید
- با اجرای دستور
git initدر داخل پوشه، یک فولدر به نام .git ایجاد می‌شود و از این به بعد گیت تغییرات درون این پوشه را دنبال خواهد کرد
cd "/your/project/path"
git init- وارد یکی از سرورهای گیت (Github، Gitlab، Microsoft Azure یا ...) شوید
- لینک یک مخزن را کپی کنید
- یک پوشه جدید در سیستم خود ایجاد کنید
- Terminal یا CMD را باز کرده و به پوشه مورد نظر وارد شوید
- از اتصال به اینترنت اطمینان حاصل کنید و دستور
git cloneرا اجرا کنید تا فایل‌های روی سرور به پوشۀ شما منتقل شوند
cd "/your/project/path"
git clone https://example.come/repositoryبرای آشنایی بیشتر با این مفهوم می‌توانید از لینک زیر استفاده کنید:
برای آگاهی از وضعیت فایل‌ها از دستور زیر استفاده می‌شود که فایل‌های ویرایش شده و استیج شده را به شما نمایش می‌دهد:
git statusبرای استیج کردن فایل‌های ویرایش شده مطابق دستورات زیر، هم می‌توان از نام فایل استفاده کرد و هم می‌توان از کاراکتر نقطه برای انتخاب تمامی فایل‌های تغییر کرده استفاده کرد:
git add <some-file-name.ext>
git add .در نهایت برای کامیت کردن فایل‌های استیج شده می‌توانید از دستور زیر استفاده کنید که اسنپ‌شاتی از فایل‌ها تهیه کرده و در پایگاه دادۀ محلی ذخیره می‌کند:
git commit -m "some brief description about changes you have made"برای مشاهده لیست کامیت‌های انجام شده روی مخزن خود نیز می‌توانید از دستور زیر استفاده کنید:
git logهمچنین می‌توانید گزارش بالا با دستور زیر به صورت خلاصه‌تر مشاهده کنید:
git log --onelineبرای آشنایی بیشتر با این مفهوم می‌توانید از لینک زیر استفاده کنید:
همانگونه که پیشتر گفته شد یکی از مزایای استفاده از ابزارهای کنترل نسخه امکان بازگشت به عقب و اصلاح اشتباهات است، در این قسمت به راه‌حل‌های موجود می‌پردازیم.
یکی از برگشت‌های معمول زمانی صورت می‌گیرد که زودتر از آن‌چه که باید تغییرات را کامیت کرده‌اید
یا بعد از کامیت کردن متوجه مشکلی در فایل‌های کامیت شده یا تگ کامیت می‌شوید.
در این حالت با استفاده از گزینۀ amend-- می‌توانید فایل‌های استیج شده را به کامیت قبلی اضافه کنید و توضیحات کامیت را نیز ویرایش کنید:
git commit -m "new description" --amendبرداشتن داده از حالت استیج شده یکی دیگر از امکانات مورد نیاز می‌باشد:
git restore --staged <some-file-name.ext>بازگرداندن فایل به وضعیتی که در آخرین کامیت داشته است یکی از راه‌های معمول برای درست کردن چیزی است که خراب کرده‌ایم؛ با این کار تمام تغییراتی که از آخرین کامیت بر روی یک فایل صورت گرفته است برگردانده می‌شوند و فایل به وضعیت سابق خود باز می‌گردد:
git restore <some-file-name.ext>برای آشنایی بیشتر با این مفهوم می‌توانید از لینک زیر استفاده کنید:
در بسیاری از تکنولوژی‌ها برای نگهداری اطلاعات حساس مانند اطلاعات مربوط به پایگاه داده، برخی اطلاعات هویتی و داده‌های وابسطه به پلتفرم، از فایل‌های محلی در مسیر پروژه استفاده می‌شود که باید از انتشار این فایل‌ها پرهیز کرد. همچنین بسیاری از تکنولوژی‌ها برای اجرای کدها علاوه بر کامپایلر یا مفسر به تعدادی کتابخانه و فایل‌های اضافه نیاز دارند که عموما حجم بالایی را اشغال می‌کنند بنابراین پیشنهاد می‌شود از قرار دادن این داده‌ها در گیت پرهیز کنید.
گیت امکانی برای نادیده گرفتن برخی داده‌ها فراهم کرده است تا کاربر قادر باشد برخی فایل‌ها را از دید گیت مخفی کند.
برای انجام این کار کافی است در پوشه‌ای که می‌خواهید در آن فایل‌هایی را از دید گیت مخفی کنید
یک فایل با پسوند gitignore ایجاد کنید و نام فایل‌ها یا مسیر منتهی به آن‌ها را در این فایل متنی بنویسید.
در صورتی که فایل‌های مورد نظر در گیت ذخیره نشده باشند از این پس نیز توسط گیت دنبال نمی‌شوند.
در سطح وب ابزارهایی برای ایجاد محتوای فایل gitignore با توجه به تکنولوژی‌هایی که در پروژه خود استفاده کرده‌اید وجود دارند که ما لینک زیر را پیشنهاد می‌کنیم:
برای اینکه بتوانید در هر پروژهٔ گیت همکاری کنید، دانستن شیوهٔ مدیریت مخزن‌های ریموت لازم است. مخازن ریموت یک نسخه از پروژهٔ شما هستند که در اینترنت یا جایی دیگر در شبکه قرار دارند. می‌توانید چند تا از آن‌ها داشته باشید که معمولاً هر کدام برای شما یا فقط قابل خواندن یا خواندنی/نوشتی هستند. همکاری با دیگران شامل درگیری با مدیریت این مخازن ریموت و پوش/پول کردن داده از/به آن‌ها است.
مدیریت مخازن ریموت به مفهوم دانستن نحوۀ افزودن مخازن ریموت، حذف کردن ریموت‌های منقضی، مدیریت شاخه‌های گوناگون ریموت و تعریف آن‌ها به عنوان دنبال‌شده یا دنبال‌شنده و ... است. در این بخش ما درباره برخی از مهارت‌‌های مدیریت ریموت صبحت خواهیم کرد.
مشاهدۀ ریموت‌های پروژۀ محلی به سادگی با دستور زیر امکان‌پذیر است:
git remoteمخازنی که به وسیله دستور git clone بر روی سیستم خود کپی کردید، همواره یک ریموت دارند؛
اما برای اضافه کردن ریموت جدید به یک مخزن محلی می‌توانید از دستور زیر استفاده کنید،
که یک ریموت با آدرس نوشته شده و نام دلخواه به مخزن شما اضافه می‌کند:
git remote add <any-name-that-you-want> <remote-url>معمولاً نام ریموت را origin می‌گذارند.
دستور fetch تمام اطلاعات ریموت را به سیستم محلی شما کپی می‌کند،
اما دستور pull علاوه بر کپی کردن اطلاعات از سرور، این اطلاعات را با اطلاعات محلی شما نیز ادغام می‌کند:
git fetch <remote-name>
git pull <remote-name>در مرحله‌ای شما نیاز دارید که تغییرات اعمال شده روی نسخه محلی (کامیت‌ها) را به ریموت خود ارسال کنید، این کار با دستور زیر صورت می‌گیرد که در آینده به موضوع branch خواهیم پرداخت:
git push <remote-name> <branch-name>با دستور rename به سادگی می‌توانید نام ریموت را تغییر بدهید
و با دستور remove می‌توانید ریموت و تمام شاخه‌های پیگیر و پیکربندی‌های مربوط به ریموت را پاک کنید:
git remote rename <old-name> <new-name>
git remote remove <name>برای آشنایی بیشتر با این مفهوم می‌توانید از لینک زیر استفاده کنید:
شاخه یا branch و شعبه‌سازی یا Branching به این معناست که شما از مسیر اصلی توسعه جدا شده و بدون ایجاد تغییر در مسیر اصلی، به ادامهٔ کار بپردازید.
وقتی یک کامیت می‌سازید، گیت یک آبجکت کامیت را که شامل یک نشانگری به اسنپ‌شات دربرگیرندهٔ اطلاعات صحنهٔ شماست، ذخیره می‌کند. این آبجکت همچنین شامل نام نویسنده، آدرس ایمیل او، پیغامی که وارد کرده و یک نشانگر به کامیت یا کامیت‌هایی که مستقیماً قبل این کامیت (والد یا والدین) آمده‌اند، است؛ به طوری که صفر والد برای کامیت اولیه، یک والد برای کامیت معمولی و چند والد برای کامیت مرج وجود خواهد داشت.
وقتی کامیتی را با اجرای دستور git commit می‌سازید،
گیت تمام زیرپوشه‌ها را چک‌سام می‌کند و آن‌ها را به عنوان یک آبجکت درخت در مخزنش ذخیره می‌کند.
سپس یک کامیت آبجکت، شامل متادیتا و نشانگری به ریشۀ درخت پروژه، می‌سازد تا بتواند اسنپ‌شات پروژه را هنگامی که نیاز بود بازسازی کند.
برنچ یک نشانگر سبک‌وزن قابل انتقال به یکی از کامیت‌هاست. نام پیش‌‌فرض برنچ در گیت master یا main است. همچنان که کامیت می‌سازید، یک برنچ master برایتان ساخته می‌شود که به آخرین کامیتی که ساخته‌اید اشاره می‌کند. هر بار که کامیت می‌کنید نشانگر برنچ master به طور خودکار به جلو حرکت می‌کند.
گیت نشانگر خاصی به نام HEAD را در خود دارد. HEAD نشانگری است که به برنچ محلی که روی آن هستید اشاره می‌کند.
برای ساخت یک برنچ جدید (اشاره‌گر به مکان کنونی HEAD) کافی است از دستور زیر استفاده کنید تا یک برنچ جدید با نام دلخواه برای شما ساخته شود:
git branch <branch-name>برای تعویض یا جابه‌جایی به یک برنچ از پیش ساخته شده، می‌توانید دستور زیر را اجرا کنید:
git checkout <branch-name>عموماً از برنچ‌ها برای مدیریت دسترسی و حفاظت از شاخۀ اصلی استفاده می‌شود.
برای ادغام first-branch با second-branch ابتدا به second-branch میرویم و سپس با استفاده از دستور merge، محتویات شاخۀ first-branch را به شاخۀ second-branch نیز منتقل می‌کنیم:
git checkout second-branch
git merge first-branchبرای آشنایی بیشتر با این مفهوم می‌توانید از لینک زیر استفاده کنید: