افزایش کارایی روزانه با کمک Git
ما با مفاهیم سیستم کنترل نسخه آشنا شدیم تا بفهمیم Git چطور میتونه به ما توی انجام بهتر کارهامون کمک کنه. یه نسخه از Git رو هم بلافاصله روی سیستم نصب کردیم تا ازش استفاده کنیم. دارم میشنوم که فریاد میزنید: «بیاین شیرجه بزنیم داخل».
باشه باشه کاپیتان، بزن بریم. توی این قسمت شما با 5 مفهوم مهم آشنا میشین که تمام چیزی هستن که در اغلب مواقع توی کار بهش نیاز دارین:
- آماده سازی مخزن (Repository)
- اضافه کردن فایلها به مخزن
- ثبت یا کامیت (Commit) فایلهای اضافه شده
- بررسی تغییرات
- بازگشت (لغو) تغییرات
درسته، فقط 5 مفهوم، تمام چیزی هستن که شما برای متفاوت بودن بهشون نیاز دارین. و البته یاد میگیرین که اگه در طول راه گم شدین، با کمک توابع راهنمای داخلی Git چطور به مسیر برگردین.
آماده شدن برای استفاده از Git خودتون
بگذارین بگیم که یه چوب جادویی دارین و دقیقاً همون کاری که شما میخواین رو انجام میده! بله درسته، شما الآن Git رو دارین. شما باید به Git دستور بدین که چه کاری برای شما باید انجام بده.
جالب بنظر میاد نه؟
ما تا اینجا فهمیدیم که برای نگهداری نسخه های مختلف فایلها، باید اونها رو توی یه پوشه نگه داریم. پس یه پوشه به اسم Workbench توی مسیر موردنظر خودتون بسازین تا مفاهیمی که توی آموزش گفته میشه رو یاد بگیرین. وقتی نوبت به مدیریت کامپیوترها میرسه، هر کسی یکی از روشهای زیر رو انتخاب میکنه:
- GUI (رابط گرافیکی کاربر یا Graphical User Interface)
- CLI (رابط خط فرمان یا Command Line Interface)
ترکیبی از دو روش بالا هم قابل استفاده است. برای راضی کردن مخاطبان مختلف، سعی میکنیم هر دو روش پیاده سازی رو پوشش بدیم.
آماده سازی
آماده سازی، چیزی بجز اشاره کردن به پوشه توسط انگشتتون نیست! اینطوری Git میفهمه که باید محتوای اون و تغییراتش رو از این لحظه به بعد باید تحت نظر بگیره.
همونطور که قبلاً گفتیم، میخوایم هر دو روش GUI و CLI رو پوشش بدیم.
آماده سازی با GUI
رابط گرافیکی Git رو اجرا کنید و گزینه Create New Repository رو انتخاب کنید:
[
attachment=170]
Git به شما یه صفحه جدید نشون میده که از شما میخواد موقعیت پوشه ای که میخواین ازش یه مخزن بسازین رو مشخص کنین. روی دکمه Browse کلیک کنید و بعد از انتخاب پوشه Workbench، روی دکمه Create کلیک کنید:
[
attachment=171]
حالا باید صفحه ای مثل تصویر زیر ببینید:
[
attachment=172]
این پنجره رو
نبندین؛ میخوایم از این صفحه برای ادامه مفاهیم استفاده کنیم.
چه اتفاقی افتاد؟
شما با موفقیت به Git دستور دادین که پوشه Workbench شما و محتویاتش رو تحت نظر بگیره. تصویر قبل، صفحه اصلی رو نشون میده که ما خیلی باهاش سروکار داریم. این صفحه شامل 4 قسمته که اجازه بدین به این شکل صداشون بزنیم:
- Unstaged Changes تغییراتی که هنوز بعنوان یه مرحله درنظر گرفته نشدن (بالا و چپ)
- Staged Changes تغییراتی که بعنوان یه مرحله ثبت شدن (پایین و چپ)
- Differential Content محتوای تغییریافته (بالا و راست)
- Action عملیات (پایین و راست)
توی مثال ما، یه پوشه به اسم Workbench ساخته و بعنوان یه مخزن آماده شد. میتونید از روش مشابهی برای تبدیل یه پوشه موجود (که حاوی فایلهایی از قبل هست) به یه مخزن برای اینکه Git اون رو تحت نظر بگیره هم استفاده کنید. وقتی که این کار رو انجام دادین، فایلهای داخل پوشه توی بخش Unstaged Changes نشون داده میشن.
آماده سازی با CLI
برای اون دسته از کسانی که دوست دارن صداهای بیشتری از دکمه های صفحه کلید نسبت به کلیک ماوس بشنون، همیشه یه حالت خط فرمان وجود داره.
درصد کسانی که توی تایپ کردن سریع هستن، بطور ثابت درحال رشده که باعث میشه اولویت بیشتری به انجام کارها توسط صفحه کلید نسبت به ماوس در هر جای ممکن داده بشه. این موضوع دلیل اصلی اینه که Gmail تقریباً برای تمامی قابلیتهاش کلید میانبر تعریف کرده.
برای ایجاد یا آماده سازی مخزن با کمک رابط خط فرمان باید کارهای زیر رو انجام بدین:
- شِل رو باز کنید (Command Prompt توی ویندوز یا Terminal/Console توی لینوکس یا مک)
- به پوشه Workbench با کمک دستور cd منتقل بشین
- وقتی داخل پوشه Workbench هستین، دستور git init رو تایپ کنید و کلید Enter رو بزنید.
- باید یه پیام وضعیت از Git دریافت کنید که میگه Initialized empty Git repository in و در ادامه، مسیر پوشه Workbench شما ذکر میشه.
[
attachment=173]
آه! صدای صفحه کلید، چقدر شنیدنش لذت بخشه.
چه اتفاقی افتاد؟
شما با موفقیت به GIT گفتین که پوشه Workbench و محتویاتش رو تحت نظر بگیره. init کلمه کلیدی عملیاتی هست که یه مخزن رو آماده سازی (Initialize) میکنه.
پشت صحنه
آماده سازی، یه پوشه به اسم git. داخل پوشه Workbench شما میسازه که معمولاً توسط Git بصورت مخفی و فقط خواندنی در میاد تا از حذف یا ویرایش تصادفی توسط کاربران در امان باشه. این پوشه مکانی هست که Git تمام تاریخچه فایلها و تغییرات اونها رو نگهداری میکنه.
بنابراین مراقب این پوشه باشین؛ حذف کردن اون باعث از بین رفتن تمام تاریخچه تغییرات فایلهایی که توی اون پوشه هستن میشه.
پیکربندی Git
نصب Git رو با تنظیم کردن صحیح اون باید تکمیل کنیم. دلایل مختلفی وجود دارن که چرا باید Git رو قبل از استفاده از اون پیکربندی کنید، اما بحث درمورد تمام تنظیمات Git فعلاً مقدور نیست و هروقت نیاز بود، درمورد گزینه های مختلف توضیح میدیم. فعلاً بعنوان حداقل تنظیمات، اسم و آدرس ایمیل خودمون رو به Git میگیم تا بتونه تغییراتی که ایجاد میکنیم رو تحت هویت خودمون ثبت کنه.
تنظیم Git با کمک GUI
برای اینکه به Git نام و آدرس ایمیلتون رو با کمک GUI بگین، مراحل زیر رو انجام بدین:
- از منوی Edit گزینه Options رو انتخاب کنید.
[attachment=174]
همونطور که میبینید، صفحه تنظیمات به دو نیمه تقسیم شده:
- تنظیمات محلی (سمت چپ - مخصوص مخزن جاری که الآن Workbench هست)
- تنظیمات سراسری (سمت راست - به تمام مخازنی که با Git نصب شده ایجاد میشن، بطور پیشفرض نسبت داده میشه)
- نگذارین این صفحه بزرگ با گزینه های زیادش گیجتون کنه. فعلاً روی بخش بالایی که با کادر قرمز توی عکس بالا مشخص کردیم تمرکز کنید و نام و آدرس ایمیل خودتون رو توی هر دو بخش محلی و سراسری مثل تصویر قبل بنویسید و روی دکمه Save کلیک کنید.
چه اتفاقی افتاد؟
با دادن نام کاربری و آدرس ایمیلمون توی هر دو بخش محلی و سراسری، هویتمون رو به Git توی این مخزن و تمام مخازنی که از این به بعد میسازیم، اعلام کردیم تا تغییراتی که ما ایجاد میکنیم رو با این هویت، گروهبندی کنه.
خارج از جریان
اگه پنجره Git رو بعد از آماده سازی بسته باشین و حالا میخواین دوباره به همون صفحه قبل برگردین، نگران نباشین. دو راه برای اینکار وجود داره:
- پنجره Git GUI رو باز کنید. میبینید که مخزن جدید توی بخش Open Recent Repository لیست شده و میتونین انتخابش کنین. میتونید از گزینه Open Existing Repository هم برای بازکردن مخازنی که توی لیست نیستن استفاده کنید.
[attachment=175]
- پوشه Workbench رو توی سیستم عامل پیدا کنید و روی اون کلیک راست کرده و گزینه Git GUI یا Git GUI here رو انتخاب کنید. کسانی که میخوان از CLI به GUI مهاجرت کنن هم میتونن از این گزینه استفاده کنن.
تنظیم Git با کمک CLI
برای تنظیم Git با کمک CLI میتونید از دستورات زیر استفاده کنید:
$ git config --global user.name "Mohammad Mostafa Shahreki"
$ git config --local user.name "Mohammad Mostafa Shahreki"
$ git config --global user.email admin@ncis.ir
$ git config --local user.email admin@ncis.ir
دقت کنید که اگه عبارت موردنظرتون دارای کارکتر فاصله است، باید اون رو توی کوتیشن جفت بگذارین.
[
attachment=176]
چه اتفاقی افتاد؟
config کلمه کلیدی عملیاتی موردنیاز برای تنظیم پیکربندی Git هست. برای تنظیم یه مقدار سراسری از پارامتر global-- استفاده میکنیم و برای تنظیم پارامترهای محلی (مخصوص پروژه جاری) پارامتر local-- رو بکار میبریم.
همونطور که اسامی این پارامترها مشخص میکنن، تنظیمات سراسری شامل مقادیر عمومی هست که برای تمام مخازنی که توی سیستم توسط اون کاربر ایجاد میشن، بکار میره درحالیکه تنظیمات محلی دقیقاً نقطه مقابلش هستن و فقط توی همون پروژه ای که داخلش هستین اعمال میشن. همونطور که میتونید حدس بزنید، پارامترهای user.name و user.email برای ثبت اسم و آدرس ایمیل کاربر بکار میرن.
برای نمایش فهرست تنظیمات Git میتونید از پارامتر list-- توی دستور git config استفاده میکنیم. این کار باعث نمایش فهرست متغیرهای پیکربندی به شما میشه.
اضافه کردن فایلها به پوشه
حالا که شما یه پایگاه کامل برای کار ساختین، اجازه بدین یه قدم جلوتر بریم و فایلها رو به مخزنی که ساختین اضافه کنیم.
وای، صبر کنید! این کلمه
مخزن که مدام بکار میبریم چیه؟ خوب، پوشه ای که توسط Git تحت نظر گرفته شده و داره بهش اشاره میشه رو مخزن صدا میزنیم. آره رفیق، زبان Git رو یاد بگیر و بقیه رو تحت تأثیر قرار بده! روند اضافه کردن فایلها به مخزن به سادگی Copy و Paste کردن اونها توی مخزن و درخواست کردن از Git برای نگاه کردن به اونهاست.
اضافه کردن فایلها به مخزن (GUI و CLI)
اجازه بدین یه فایل متنی به اسم content.txt بسازیم که شامل این متن هست:
I love working with Git. It's a simple, fast, and superb version control system.
میخوایم از این فایل برای یادگیری عملیاتی که توی ابتدای این قسمت از آموزش گفتیم استفاده کنیم. خوب فایل رو با محتوایی که گفته شد، توی پوشه Workbench بسازین. خوب بسازین دیگه نکنه اینم باید یاد بدیم؟!
Git به شما اطلاع میده که فایلهایی به مخزن اضافه شدن و منتظر دستور شما میمونه. خوب حالا میتونیم به Git بگیم این فایلها رو برای تغییر با انجام کارهایی که بعداً میگیم، تحت نظر بگیره.
توی محیط GUI روی دکمه Rescan توی بخش Action کلیک کنید (یا کلید F5 رو بزنید) :
[
attachment=177]
حالا روی آیکن کنار اسم فایل کلیک کنید تا تغییرات به بخش Staged Changes منتقل بشن.
اگه از CLI استفاده میکنید، دستورات زیر رو اجرا کنین:
$ git status
$ git add content.docx
[
attachment=178]
چه اتفاقی افتاد؟
ما با موفقیت فایلمون رو به مخزن اضافه کردیم. با کلیک کردن روی دکمه Rescan یا واردکردن دستور git status به کارپرداز خودمون (Git) دستور دادیم که فهرست تغییراتی که ما توی مخزن ایجاد کردیم رو نسبت به آخرین وضعیتش نمایش بده. این تغییرات،
مرحله بندی نشده نام دارن که معناش اینه که بعد از آخرین تغییراتی که بعنوان یه مرحله توی مخزن ثبت کردیم، اتفاق افتادن.
این تغییرات باید توسط کاربر با منتقل کردنشون به یه وضعیت
مرحله بندی شده تأیید بشن که این کار با کلیک کردن روی آیکن کنار اسم فایل یا با کمک دستور git add انجام میشه.
اونها رو نادیده بگیر
ما راههای قراردادن فایلها زیر رادار Git رو دیدیم ولی موقعیتهایی هم ممکنه پیش بیاد که بخوایم Git یکسری از فایلهای داخل مخزن رو نادیده بگیره. برای مثال، اگه یه فایل Word داشته باشیم، وقتی اون رو با Microsoft Office باز میکنیم، یه فایل مخفی کنار فایل ایجاد میشه. برای مثال اگه فایل اصلی content.docx باشه، یه فایل به اسم content.docx$~ ایجاد میشه که برای استفاده های داخلی خود Office کاربرد داره (البته تا وقتی که فایل رو نبستین تا اگه یه موقع وسط کار برق رفت، تغییرات شما رو طبق تنظیماتی که گذاشتین، توی فواصل زمانی مشخص توی این فایل قرار بده که قابل بازیابی باشه). بنابراین اگه قبل از بستن فایل توی Word مخزن رو چک کنید (با دکمه Rescan یا دستور git status)، این فایل رو هم خواهید دید. خوب یقیناً ما کاری به این فایل نداریم و نمیخوایم روند تغییراتش رو توی تاریخچه مخزن ذخیره کنیم. بعضی وقتها هم ممکنه یکسری فایل دیگه داشته باشین که جزئی از پروژه نیستن (مثلاً فایلهای توضیحات که برای مراجعات بعدی خودتون مینویسین). اینجور مواقع درنظر گرفتن فایلهای موقت برنامه ها و فایلهایی که ربط مستقیمی به پروژه ندارن و بعدها هم به احتمال زیاد پاک میشن، ارزشی نداره.
اینجور وقتها، خیلی مهمه که قبل از اضافه کردن فایلها به مخزن، این فایلهای موقت یا غیرمرتبط رو از فهرست بررسی Git خارج کنین و بهش بگین اونها رو نادیده بگیره. خوب وقتی با یکی دوتا فایل طرفیم، اضافه نکردن فایلهای موردنظر و نادیده گرفتن فایلهای غیرضروری و غیرمرتبط راحته. کافیه فقط روی آیکن اون فایلهایی که میخوایم به Staged Changes اضافه بشن کلیک کنیم یا فقط همونها رو با git add اضافه کنیم ولی وقتی تعداد فایلها زیاد میشه یا میخوایم همزمان، چندین فایل رو نادیده بگیریم، این کار تا حدود زیادی زجرآور میشه.
عملیات دسته ای
وقتی میخواین چندین فایل رو از وضعیت Unstaged به وضعیت Staged منتقل کنید، میتونید از روشهای زیر استفاده کنید:
- GUI : کلیدهای Ctrl+I رو فشار بدین و روی Yes کلیک کنید تا تمام فایلهای ناشناخته بصورت یکجا به وضعیت Staged منتقل بشن.
- CLI : دستور زیر معادل روش بالاست:
$ git add .
این دستور تمام تغییرات رو با یه شلیک به وضعیت Staged میبره. استفاده از کارکترهای جایگزین مثل txt.* هم مجازه:
$ git add *.txt
استفاده از این روشها به ما توی خلاصی از دردسر اضافه کردن فایلها بصورت جداگانه کمک میکنه ولی قابلیت تفکیک کردن موارد ناخواسته رو هم از ما میگیره و همه فایلها به مخزن اضافه میشن. خوب چطور میتونیم قدرت عملیات دسته ای و کنترل جداسازی فایلهای خاص رو با هم داشته باشیم؟
gitignore. برای نجات شما
برای مدیریت هوشمندانه این موضوع، Git یه قابلیت خوب داره. با ساخت یه فایل به اسم gitignore. داخل مخزن (به . اول اسم فایل دقت کنید) و واردکردن اسامی یا الگوی فایلها میتونیم به Git بگیم چه مواردی رو نادیده بگیره. برای امتحان، یه فایل به اسم ontent.txt$~ داخل مخزن بسازین و Rescan رو بزنید (یا git status رو اجرا کنید). حالا قبل از اینکه فایلها رو به وضعیت Staged ببرین، کارهای زیر رو انجام بدین:
- یه فایل به اسم gitignore. داخل مخزن بسازین و این کد رو داخلش بنویسید:
~*.*
.gitignore
- حالا دوباره دکمه Rescan رو بزنید یا git status رو اجرا کنید تا متوجه شگفتی اون بشین (دقت کنید که باید خود gitignore. رو هم از فهرست فایلهایی که باید بررسی و اضافه بشن، خارج کنید).
چه اتفاقی افتاد؟
ما با موفقیت به Git دستور دادیم که فایلهای موقت و غیرضروری که خودمون یا برنامه های دیگه میسازیم رو نادیده بگیره. با اینکه اضافه کردن gitignore. یکبار انجام میشه، باید برحسب تغییراتی که توی فایلهای ناخواسته شما انجام میشه، الگوهای این فایل رو هم اصلاح کنید. ما با الگوی *.*~ گفتیم که هر فایلی با کارکتر ~ شروع میشه رو نادیده بگیره. ضمناً خود فایل gitignore. رو هم نادیده گرفتیم. البته اگه میخواین در آینده gitignore. رو هم تغییر بدین و روند این تغییرات رو هم ذخیره کنید، بهتره خود gitignore. رو به فهرست نادیده گرفتن اضافه نکنید.
لغو تغییرات
توی هر مرحله از کار قبل از ثبت (Commit) اگه بخواین میتونید یه فایل رو از وضعیت Staged به وضعیت Unstaged برگردونید. برای انجام این کار میتونید از روشهای زیر استفاده کنین:
ثبت (کامیت) فایلهای اضافه شده
تا حالا ما مخزن رو ساختیم، فایلها رو اضافه کردیم و تغییرات رو با مرحله بندی اونها (قراردادن اونها توی وضعیت Staged Changes) تأیید کردیم اما تا وقتی که این تغییرات رو ثبت نکنیم، فایلها تحت کنترل نسخه نخواهند بود. این مسئله بخاطر اینه که فقط وقتی شما تغییرات رو ثبت میکنید، Git محتوای فایلها رو ثبت میکنه و اون رو بعنوان یه فاز جدید از فایل/فایلها درنظر میگیره، تا دفعه بعد بتونه ازطریق مقایسه با محتوای فایلها توی این فاز، بفهمه که تغییر کردن یا نه. درواقع Git هربار محتوا رو با آخرین وضعیت ثبت (Commit) شده، مقایسه میکنه تا تغییرات رو کشف کنه.
این یه کلمه جدید توی زبان Git شماست: این فرآیند رو
کامیت کردن میگن.
خوب بگذارین یه کامیت اولیه از فایلها داشته باشیم. اولین باری که یه فایل رو به مخزن اضافه و کامیت میکنید، Git فایل جدید رو ثبت میکنه. هر کامیتی بعد از اون توی این فایلها داخل همون مخزن روی این فایلها، یه کامیت برای تغییرات برمبنای آخرین نسخه از همون فایل هست که توی مخزن موجود بوده.
اگرچه Git از دستورات شما پیروی میکنه، اما یه عادت خوب هم داره که باید یه توضیح در زمان ثبت هر کامیت بنویسید تا بعداً بتونه بفهمه رفتارها و کارهای شما رو با توجه به انواع مختلف فایلها بفهمه و یه سیستم هوش مصنوعی برمبنای الگوهای مختلف رفتاری شما ایجاد کنه تا روال کارهای شما رو خودکار کنه.
توضیحاتی که توی هر کامیت ارائه میکنید، فقط به شما یا هر کسی که تاریخچه تغییرات مخزن رو میخونه برای فهمیدن هدف و تغییرات فایلها کمک میکنه. خیلی خوبه که توضیحی بنویسید که بتونه اطلاعات خوبی بده.
کامیت کردن فایلها توی GUI
دلیل کامیت کردن این تغییرات رو توی قسمت Initial Commit Message توی بخش Action بنویسین و روی دکمه Commit کلیک کنید. با این کار، توی نوار وضعیت برنامه GUI شناسه کامیت و توضیحاتتون دیده میشه:
[
attachment=179]
کامیت کردن فایلها توی CLI
با فرض اینکه هنوز خط فرمان رو باز دارین، این دستور رو توی پوشه مخزن اجرا کنید:
git commit -m "Initial commit to showcase the commit functionality of Git"
اگه پیغامی مشابه پیغام GUI دریافت کردین، به معنای تأیید کامیت قبلیه (که معناش اینه که از آخرین کامیت، تغییری اتفاق نیفتاده) :
[
attachment=180]
چه اتفاقی افتاد؟
شما با موفقیت فایلهاتون رو توی مخزن کامیت کردین. از این به بعد هر تغییری توی این فایلها، نسبت به محتواشون در لحظه این کامیت سنجیده خواهد شد. بگذارین ببینیم اگه محتوای فایلها رو تغییر بدین چی میشه؟
من ناگهان احساس کردم که باید بجای اینکه بگم گیت یه سیستم کنترل نسخه فوق العاده و سریع و ساده است، باید بگم Git توی کارم تأثیرگذار بوده. بنابراین محتوای content.txt رو به این شکل تغییر دادم:
I love working with Git.
It increases my productivity on multiple folds when working with files which have frequent changes.
[
attachment=181]
شما همین تازگیا یاد گرفتین که چطور تغییرات رو به وضعیت Staged برده و کامیت کنید. پس بقیه کار رو بعهده شما میگذارم. دوستان CLI کار هم دستورات زیر قطعاً یادشونه:
$ git status
$ git add .
$ git commit -m "your comments"
اگه به قسمت Content نگاه کنید، تغییراتی که بعد از آخرین کامیت اتفاق افتاده رو میبینید. برای کامیت جدید، توضیح Added more text that explains why I use Git بنظر مناسب میاد.
سرکشی (Check out)
خوب، تا اینجا ما توی نسخه های فایلهامون دستور دادن به Git طبق چیزایی که یاد گرفتیم، به سمت جلو حرکت میکردیم. هر چیزی که تا الآن یاد گرفتین، یه فرآیند یه طرفه بوده!
برای اینکه موضوع رو شفاف تر کنیم: چه حسی بهتون دست میده اگه ندونین چطوری باید از Undo و Redo توی برنامه Word استفاده کنید؟
خوب پس اجازه بدین توی سفر زمان، به عقب حرکت کنیم و محتوای قبلی خودمون رو با کمک Git بازیابی کنیم.
«چک اوت» یکی از کارهاییه که به شما توی پرش از/به تغییراتی که توی هر فایل جداگانه یا کل مجموعه فایلهایی که توی مخزن در زمان کامیت کردن داشتین، کمک میکنه.
میتونید به کامیتی که قبلاً انجام دادین برگردین تا محتوای یه فایل یا گروهی از فایلها رو ببینید و دوباره به آخرین نسخه از همون فایل(ها) با آخرین تغییرات برگردین. همه توی یه پلک زدن.
چطور خوب، اینطور نیست؟
کارهای دیگری هم بجز دیدن فایلها توی کامیت قبلی هم میتونید انجام بدین که توی قسمتهای بعدی آموزش توی قسمت «شاخه سازی (Branching)» بهشون میپردازیم.
با تئوری که گفتیم، کار عملی رو شروع میکنیم.
چک اوت با GUI
- از منوی Repository گزینه Visualize All Branch History رو انتخاب کنید تا برنامه gitk اجرا بشه. باید صفحه ای مشابه تصویر زیر ببینید:
[attachment=182]
Gitk یه مرورگر مخزن گرافیکی قدرتمنده که به ما اجازه میده کارهای مختلفی رو ازقبیل نمایش تصویری (Visual) از مخزن، برچسب گذاری، برگردوندن تغییرات و... رو انجام بدیم.
مجدداً تأکید میکنم از شلوغی پنجره گیج نشین؛ مرحله به مرحله با همه چیز آشنا میشیم.
فعلاً بگذارین تمرکزمون روی کادر بالا و چپ باشه که مسیری رو نشون میده که دایره های رنگی مشخص کننده کامیتهایی هستن که انجام دادین و درکنار هر دایره، توضیحاتتون نوشته شده.
مستقیماً پایین این کادر، قسمت SHA1 ID قرار داره که به شما ID کامیتی که توی کادر بالا انتخاب کردین رو نشون میده. همونطور که قبلاً گفتیم، ما از این ID برای شناسایی یه کامیت خاص برای بازگشت به عقب استفاده میکنیم.
- اولین کامیت رو انتخاب کنید که میگه Initial commit to showcase the commit functionality of Git تا ID اون توی بخش SHA1 ID نمایش داده بشه و ID اون رو از کادر مربوطه، با دوبار کلیک کردن روی اون و فشردن کلیدهای Ctrl+C کپی کنید.
- به Git GUI برگردین و از منوی Branch گزینه Checkout رو انتخاب کنید تا پنجره عملیات چک اوت ظاهر بشه (میتونید از کلیدهای Ctrl+O هم استفاده کنید). ID کامیت رو توی کادر Revisition Expression با کلیدهای Ctrl+V الصاق (Paste) کرده و روی دکمه Checkout کلیک کنید:
[attachment=183]
- روی دکمه OK توی پنجره ظاهرشده کلیک کنید. درمورد اصطلاح Detached Checkout بعداً توی بخش شاخه سازی توضیح میدیم.
[attachment=185]
چه اتفاقی افتاد؟
شما با موفقیت توی زمان به عقب سفر کردین. اگه فایل content.txt رو باز کنید، میتونید محتوای قبلی اون رو مشاهده کنید.
توی هر مرحله میتونید به آخرین تغییرات برگردین. کافیه توی پنجره Checkout گزینه Local Branch رو انتخاب کنید و مطمئن بشین که master انتخاب شده و روی دکمه Checkout کلیک کنید:
[
attachment=186]
همونطور که میبینید، دوباره به آخرین محتوای خودتون برگشتین.
آره، فوق العاده است، اینطور نیست؟
چک اوت با CLI
- خوب بگذارین دو دستور جدید رو یاد بگیریم:
$ git log
$ git checkout COMMIT_ID
دستور git log برای نمایش تاریخچه یه مخزن بکار میره و اطلاعاتی مثل ID کامیت، نویسنده، تاریخ و توضیحات مربوط به کامیت رو نشون میده. ما به ID کامیت برای استفاده های بعدی نیاز داریم:
[attachment=187]
نگران حفظ کردن یه رشته 40 کارکتری نباشین. بجز قابلیت Copy و Paste خط فرمان، چوب جادویی ما (Git) قسمت سخت کار رو انجام میده و اگه 5 کارکتر اول رو تایپ کنیم، بقیه رو خودش تکمیل میکنه.
- از دستور git checkout برای رفتن به کامیت اول استفاده کنید و محتوای فایل رو چک کنید. هروقت خواستین میتونید با دستور زیر به آخرین نسخه برگردین:
$ git checkout master
بازگشت دائمی (Reset)
برخلاف چک اوت که قبلاً یاد گرفتیم، ریست کردن، یه سفر دائمی به گذشته است. سه نوع ریست وجود داره:
اگه هدفمون نادیده گرفتن تمامی تغییراتی باشه که بعد از یه کامیت خاص اتفاق افتاده، فقط میتونیم از ریست سخت استفاده کنیم. بنابراین توی این قسمت از آموزش فقط همین مدل رو یاد میگیریم.
ریست با GUI
- از منوی Repository گزینه Visualize All Branch History رو انتخاب کنید تا پنجره gitk باز بشه.
- توی پنجره بالا و چپ میتونید تاریخچه مخزن رو ببینید. الآن فقط یه تاریخچه خطی با 2 کامیت داریم. روی اولین کامیت کلیک راست کرده و گزینه Reset master branch to here رو انتخاب کنید:
[attachment=188]
- یه پنجره تأیید ظاهر میشه که 3 نوع ریست رو بعنوان انتخاب، در اختیارتون میگذاره. نوع Hard رو انتخای کنید و روی دکمه OK کلیک کنید:
[attachment=189]
- gitk باید بطور خودکار بروزرسانی بشه تا به شما تاریخچه تغییریافته مخزن رو نشون بده که توی اون، از کامیتی که انتخاب کردین به بعد، دیگه کامیتی وجود نداره. اگه این اتفاق نیفتاد، خودتون از منوی File گزینه Reload رو انتخاب کنید یا کلیدهای Shift+F5 رو بزنید.
ریست با CLI
ریست کردن با CLI میتونه با دستورات زیر انجام بشه:
$ git log
$ git reset --hard COMMIT_ID
[
attachment=190]
چه اتفاقی افتاد؟
تبریک میگم. ما با موفقیت مخزنمون رو بطور دائمی به یک وضعیت قبل برگردوندیم. میتونید این موضوع رو با بررسی محتوای فایلها چک کنید.
راهنمای Git
Git یه بستر دائماً درحال رشد و مطالعه است. مهم نیست که چقدر تا حالا بهش مسلط بودین. ممکنه همیشه یه چیز جدید در هربار استفاده ازش یاد بگیرین چون راههای زیادی برای انجام کارها وجود داره. تقریباً هر دستوری که میخواین توی CLI برای کار با Git بنویسین با الگوی زیر نوشته میشه:
git keyword parameters and/or values
وقتی میگیم تقریباً تمام دستورات Git محلی/آفلاین هستن، واقعاً همینطوره.
Git یه ماژول راهنمای داخلی داره که میتونه به شما هروقت توی نحوه استفاده از یه دستور خاص یا حتی اسم خود دستور شک داشتین، کمک کنه. میتونید بلافاصله به مستندات داخلی Git با دستورات زیر مراجعه کنید:
- git help برای نمایش فهرستی از پارامترهای خط فرمان و پرکاربردترین کلمات کلیدی و توضیح اونها
- git help keyword برای نمایش مرجع کامل دستور موردنظر توی مرورگر/ویرایشگر پیشفرض سیستم شما
جمع بندی
ما یاد گرفتیم که چطور کارهای زیر رو توی هر دو محیط GUI و CLI انجام بدیم:
- راه اندازی یه مخزن
- پیکربندی Git
- اضافه کردن فایلها به مخزن
- نادیده گرفتن فایلهای ناخواسته که توی مخزن ما قرار دارن
- کامیت کردن فایلهای جدید یا تغییرات فایلهای موجود
- سرکشی به کامیتهای قبلی در مواقعی که نیاز به مراجعه به داده های قبلی داریم و برگشت به آخرین کامیت
- ریست کردن مخزن بطور دائم به یک کامیت دلخواه و حذف تمام کامیتهای بعد از اون
- استفاده از ماژول راهنمای داخلی Git
خیلی زود یاد میگیرین که چطور این کارها و خیلی کارهای دیگه رو هم انجام بدین:
- مدیریت چند محیط و سوئیچ بین اونها که توسط کاربران مختلفی واردشون شدین
- ادامه دادن به ایجاد تغییرات از یه کامیت خاص و درنتیجه مدیریت مسیرهای مختلفی که توی یه مخزن ایجاد میشه (که ازنظر فنی بهش شاخه یا Branch) میگن
