آموزش کار با کنترل نسخه Git

[ADMIN]

Git دقیقاً چیه؟

توی این تاپیک قصد دارم شما رو با یکی از مهمترین مفاهیم دنیای بازمتن آشنا کنم. البته این مفهوم، مخصوص پروژه های Open Source نیست ولی بیشترین استفاده رو توی این نوع پروژه ها داشته. بله درسته. میخوایم درمورد Git صحبت کنیم. چیزی که واقعاً توی مقالات فارسی هیچ صحبتی ازش نشده. البته اگه منصفانه نگاه کنیم، در حد یه اشاره و اینکه کلاً چیز خوبیه خیلیا حرف زدن ولی محض رضای خدا یه سایت رو پیدا نمیکنید که مرحله به مرحله بیاد مفاهیم Git مثل Repository و Commit و Fork و Clone و... رو توضیح بده و یه پروژه واقعی بسازه تا بفهمیم این سیستم چطوری کار میکنه. طبیعیه که وقتی از چنین ابزارهایی اطلاع نداشته باشیم، نمیتونیم تصور کنیم که کار تیمی هم میتونه یه چیز ساده باشه. البته کار تیمی هم فقط یکی از چندین امتیازی هست که Git در اختیار شما میگذاره. این شد که تصمیم گرفتم برای اولین بار توی سایتهای ایرانی و فارسی زبان، به آموزش این مقوله مهم در برنامه نویسی تیمی و فردی بپردازیم.

توی این آموزش از چند منبع و کتاب معتبر استفاده شده تا مطالب به شکل روان و ساده بیان بشه و هرجا لازم بوده، تجربه شخصی خودم رو هم بیان کردم. برای رعایت حق تألیف (Copyright)، منابعی که از اونها استفاده کردم رو ذکر میکنم:

• Git: Version Contron for Everyone
• Git from the bottom up
• Getting Good With Git
• Pro Git
• Git Recipes
• و بالأخره Introducing GitHub
  

علت اینکه آخری رو یکم متمایز کردم اینه که از همین الان بدونین Git با GitHub یکی نیست. درست همونطور که Unix و Linux یکی نیستن. GitHub یه پروژه جهانی و بزرگه که با Git ساخته شده و قدرتش رو از اون میگیره. پس ما اول یاد میگیریم Git چیه و بعد به سراغ GitHub میریم. بد نیست بدونید که میتونین Git رو روی سیستم خودتون هم داشته باشین.

پرحرفی بسه! با nCIS توی این آموزش همراه باشین.

[ADMIN]

راحت نفس بکشین - آشنایی با سیستم کنترل نسخه
همه ما ممکنه بارها دلمون خواسته باشه که یه راهی برای برگشتن به گذشته برای تغییر یه کاری که توی زندگی انجام دادیم وجود داشت. خوب با وجود اینکه بنظر افسانه ای میاد، اما میخوایم به شما روشی رو یاد بدیم که چطور این کار رو درباره فایلهای دیجیتال انجام بدین! بله درست خوندین؛ میخوایم به شما سیستمی رو معرفی کنیم که این کار رو ممکن میکنه. کار رو با یه درک مفهومی محکم درباره کنترل نسخه با کمک Git شروع میکنیم.

توی این قسمت به سؤالات زیر جواب میدیم:

• سیستم کنترل نسخه (Version Control System) چیه؟
• چه موقع به یکی از این سیستمها نیاز دارین؟
• چطور کار و رشد میکنن؟
• چرا Git بهترین گزینه شماست؟
  

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

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

   

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

بازیهای کامپیوتری رشد کردن و از این وضعیت خارج شدن درحالیکه نحوه کار ما با فایلها به همون شکل باقی مونده. گزینه هایی مثل Undo و Redo موقتاً به ما وقتی که فایل موردنظرمون هنوز باز هست، کمک میکنن، اما از این فراتر نمیتونن برن. نمیتونید یه فایل رو باز کنید و تغییراتی رو که قبل از آخرین ذخیره سازی (و بستن فایل) انجام دادین رو برگردونید به وضعیت قدیمی تر.

حتی ممکنه موقعیتهایی پیش بیاد که بخوایم چندین نسخه از یه فایل داشته باشیم. حتی رایج ترین روش مدیریت نسخه های مختلف یه فایل یعنی نامگذاری ترتیبی فایلها (برای مثال Inventory_2011-09-21.doc و System_v6.xls و امثال اون) بعد از مدتی عذاب آور میشن چون عدد نسخه موردنظر و حجم فایلهایی که باید مدیریت بشن، مدام درحال افزایشه.

حالا اگه شما چنین موقعیتهایی رو تجربه کردین یا درباره هرکدوم میتونید تصور کنید و میخواین بدونین که آیا روشی وجود داره که این کار رو بهتر انجام بدیم، در انتهای این قسمت خوشحال خواهید شد. اینجا همون جاییه که سیستم کنترل نسخه (Version Control System یا VCS) وارد بازی میشه.

سیستم کنترل نسخه چیه؟
یه سیستم که قادر به ذخیره تغییرات ایجادشده توی یه فایل یا مجموعه ای از فایلها درطول زمان به شکلی که اجازه بده از آینده به گذشته برگردیم و یه نسخه خاص از اون فایل (یا فایلها) رو صدا بزنیم، سیستم کنترل نسخه نام داره.

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

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

[bچرا به یه سیستم کنترل نسخه احتیاج دارین؟[/b]
سعی کنید به سؤالات زیر با توجه به وضعیت فعلی سیستمتون جواب بدین:

• میتونین چند نسخه از یه فایل رو با یه نام یکسان نگه دارین تا از درهم و برهمی فایلها با تغییرات کوچکی توی اسامیشون که این نسخه ها رو نشون میدن جلوگیری کنین؟
• آیا راهی دارین که بخشی از فایل(ها)تون رو که بعداً ممکنه بهش نیاز داشته باشین رو قبل از اینکه بخاطر نیازهای فعلی تغییر بدین، علامت بگذارین تا دوباره بتونین اونها رو بازیابی کنین؟
• آیا از سناریوی فعلی که تنها راه امن شما برای بازگشت محتوای خودتون، کپی گرفتن از فایل یا گروهی از فایلها توی یه پوشه جدا به اسم backup و بروزرسانی مرتب اون هست، راضی هستین؟
  

اگه جواب شما به هرکدوم از این سؤالات، یه «نه» گنده است، این دقیقاً دلیل نیاز شما به یه سیستم کنترل نسخه و البته این آموزشه.

اگه جواب شما به سؤالات بالا «بله» است، معناش اینه که یکسری راه برای دورزدن این مشکلات پیدا کردین. روشهای ساده ممکنه شامل ایجاد نقاط بازگشت توی نسخه های اخیر ویندوز باشه که بطور داخلی نسخه های تمام اسناد مثل فایلهای Word و Excel و Powerpoint شما رو به وضعیتی که در زمان ایجاد نقطه بازگشت بودن، برمیگردونه.

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

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

تصویر زیر جریان ساخت محتوا رو با و بدون یه سیستم کنترل نسخه نشون میده:

   

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

اگه بخوایم طبق تصویر توضیح بدیم، شما نمیتونید از وضعیت نهایی (Final) به هیچکدوم از وضعیتهای میانی (Intermediate) برگردین تا یه پاراگراف سوم کاملاً متفاوت بنویسین، مگه اینکه بخشی از اطلاعات رو از دست بدین (شما نمیتونید از Undo استفاده کنید چون محتوا در طی دوره های زمانی مختلفی تولید شده و شما فایل رو ذخیره کردین و بستین).

امروزه ما با کمک Save As به این قابلیت دست پیدا کردیم که با ما اجازه میده فایل رو با نام متفاوتی ذخیره کنیم و پاراگراف سوم رو حذف کنیم و یه نسخه جدید بنویسیم.

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

   

بهترین قسمت ماجرا اینه که شما توی این موارد محدودیتی ندارین:

• تعداد رفت و برگشت ها
• تعداد مراحل بین مبدأ و مقصد رفت و برگشت
• جهت حرکت
  

معناش اینه که بدون هیچ نگرانی میتونید از هر مرحله به مراحل بعدی یا قبلی بدون هیچگونه از دست دادن اطلاعات حرکت کنید. حالا با این اوصاف، بنظرتون به این سیستم نیاز دارین؟

انواع سیستمهای کنترل نسخه
سه نوع سیستم کنترل نسخه وجود داره که براساس نوع عملیاتشون دسته بندی شدن:

• سیستم کنترل نسخه محلی
• سیستم کنترل نسخه مرکزی
• سیستم کنترل نسخه توزیع شده
  

بگذارین خیلی خلاصه به تاریخچه این سیستم بریم.

سیستم کنترل نسخه محلی
بعد از فهمیدن اینکه مدیریت نسخه های مختلف فایلها با کمک نامگذاری سریالی خیلی خطا پیش میاره، یه «سیستم کنترل نسخه محلی» اولین تلاش موفقیت آمیز برای حل این مشکل بود.

سیستم کنترل بازبینی (Revision control system یا RCS) یکی از محبوبترین سیستمهای کنترل نسخه در این چهارچوب بود.

این ابزار خیلی ساده با نگهداری مجموعه تغییرات (یعنی تفاوت بین محتوای فایل از یه وضعیت به وضعیت بعدی) با کمک یه ساختار خاص توی دنبال کننده نسخه (Version Tracker) کار میکرد که توی هارد دیسک سیستم شما قرار میگرفت.

   

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

وقتی که یه فایل توی RCS قرار میگرفت، یه ورودی دنبال کننده نسخه براش میساخت که جزئیاتی مثل تنظیمات RCS برای اون فایل خاص رو همراه با شماره نسخه، تاریخ، زمان، نویسنده، وضعیت، شاخه، و یه لینک به وضعیت بعدی و در ادامه، محتوای فایل توی یه ساختار با قالب خاص رو داخلش ذخیره میکرد. بعد از این کار، فایل شما حذف میشد!

بازیابی فایل همونطور که قبلاً گفته شد، ازطریق دنبال کردن تمام تغییرات از ابتدا تا مرحله موردنظر شما انجام میشد.

سیستم کنترل نسخه مرکزی
مثل هر بسته نرم افزاری یا مفهوم دیگه، با رشد نیازمندیها، کاربران احساس کردن که سیستمهای کنترل نسخه محلی فعالیتهاشون رو محدود میکنه.

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

خوب چطور این مشکل رو حل کنیم؟

این موضوع با نگه داشتن فایلها توی یه مکان مشترک (سرور) که هر کسی میتونست از کامپیوتر شخصی خودش (کلاینت) بهش دسترسی پیدا کنه حل شد. این موضوع باعث تولد سیستم کنترل نسخه مرکزی (Centralized Version Control System - با CVS اشتباه نگیرین) شد.

   

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

از اونجا که فایلها توی یه مکان ذخیره میشد هر تغییری توی فایلها بطور خودکار با بقیه افراد به اشتراک گذاشته میشد.

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

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

خوب چیکار باید بکنین؟

دقیقا! مزایای هر دو سیستم رو ادغام کنید و یه سیستم ترکیبی بسازین. این یکی از دلایل کلیدی هست که چرا سیستمهای کنترل نسخه توزیع شده (Distributed Version Control Systems) وارد صحنه شدن.

   

سیستمهای کنترل نسخه توزیع شده مزایای سیستمهای کنترل نسخه محلی رو دارن. مثل:

• ایجاد تغییرات محلی بدون نیاز به اتصال دائمی به سرور
• تکیه نکردن به یک نسخه از فایلها که روی سرور ذخیره شده
  

اینها با مزایای سیستمهای کنترل نسخه مرکزی ترکیب میشن. مثل:

• امکان استفاده مجدد از کار
• کار تیمی، بدون تکیه به تاریخچه ذخیره شده روی سیستمهای افراد
  

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

مزایای زیادی شامل کارآیی، سادگی استفاده و مدیریت هم وجود دارن. یه جمله عمومی و معروف هست که میگه «هر چیزی که یه سیستم کنترل نسخه مرکزی میتونه انجام بده رو نام ببرین؛ یه سیستم کنترل نسخه توزیع شده میتونه همون کار رو به شکل بهتر انجام بده.

حرکت به سمت Git
ما از انواع مختلف سیستمهای کنترل نسخه گذشتیم و چیزی که فهمیدیم این بود که یه سیستم کنترل نسخه توزیع شده، چیزیه که میتونه زندگی ما رو راحت، امن و مطمئن کنه.

امروزه سیستمهای توزیع شده زیادی در جهان وجود داره. پس کدوم رو انتخاب کنیم؟

Git نسبتاً یه بسته نرم افزاری جدیده (طرح اولیه اون توی 7 آوریل 2005 ارائه شد) که از پایه برای جلوگیری از مشکلاتی که توی اکثر سیستمهای کنترل نسخه دیگه وجود داشتن ساخته شد.

لینوس توروالدز (Linus Torvalds)، کسی که هسته لینوکس رو به ما هدیه کرده، افتخار ایجاد این پروژه رو هم توی کارنامه اش داره. معماری GIT برای سرعت، کارآیی، انعطاف پذیری و قابلیت استفاده بیشتر طراحی شده. وقتی اولین بار جمله قبلی رو شنیدم، همون فکری رو کردم که شما الان تو ذهنتون دارین: «این Git که اینقدر خوب حرف میزنه؛ در عمل هم خوبه؟»

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

برای اون دسته از شما که هیچ ذهنیتی درباره هسته لینوکس و اینکه چرا بهش لقب پیچیده میدن ندارین میگم، فقط درمورد حدود 9 میلیون خط کد فکر کنین که در بین تقریباً 25 هزار فایل قرار گرفتن و کارهای مختلفی مثل ویرایش محتوا، حرکت به سمت عقب و جلو، بارها و بارها هرروز توسط صدها برنامه نویس در سرتاسر دنیا داره روی اونها انجام میشه. و هنوز هم سرعت پاسخ عملیات Git در حد چند ثانیه است.

چرا اونها به Git برای چنین کارهای پر چالشی اعتماد کردن و چطور Git نیازهای اونها رو در موارد زیر جواب داده:

• قابلیت اطمینان
• سرعت و کارآیی
• امنیت
  

قابلیت اطمینان
قابلیت اطمینان بالا چیزی بجز قابلیت انجام یه کاری که توی یه لحظه کوتاه بین فراخوانی و جواب گرفتنش انجام میشه نیست.

بعنوان مثال بگذارین یه سیستم بانکی رو درنظر بگیریم. وقتی پول رو از حسابتون به یه حساب دیگه منتقل میکنید، یا عملیات بطور کامل انجام میشه یا رد میشه که معناش اینه که یا پول از حساب شما کم شده و به حساب طرف مقابل منتقل شده و یا کل عملیات لغو شده و هیچ پولی جابجا نشده.

این سیستمها از انجام بخشی از عملیات (مثل کم شدن پول از حساب شما و واریزنشدن به حساب مقصد) جلوگیری میکنن.

مثال دیگه میتونه سیستم رزرو صندلی باشه که یا پول پرداخت میشه و صندلی رزرو میشه و یا پول پرداخت نمیشه و صندلی هم رزرو نمیشه.

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

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

حتی وقتی چند میلیون فایل رو مدیریت میکنید، عملیاتی که با کمک Git انجام میشه فقط چند ثانیه زمان برای اجرا نیاز داره. یکی از مهمترین دلایل این موضوع، روشی هست که Git فایلها رو مدیریت میکنه. ازنظر مفهومی، اغلب سیستمهای دیگه (مثل CVS و Subversion و Perforce و Bazaar و...) به داده های شما بعنوان مجموعه ای از فایلها و تغییراتی که روی اونجا توی نسخه های مختلف اتفاق میفته نگاه میکنن.

تصویر زیر یه نمای کلی از نحوه مدیریت فایلها و نسخه های اونها توی سایر سیستمها نشون میده:

   

درمقابل، Git یه ارتباط بین فایلهای شما و کارهایی که روی اونها انجام میشه میبینه. یه تصویر از کل مجموعه فایلها بجای ذخیره کردن تغییرات بین نسخه های هر فایل ذخیره میکنه. این کار به سرعت رعدآسای Git توی کارهای خاصی مثل بازیابی محتوای فایلها به نسخه های قبلی (که در آینده میبینیم) کمک میکنه. هربار که یه نسخه تولید میشه، یه تصویر گرفته میشه. این به معنای ذخیره کردن کپی های مختلف از فایلها نیست. اگه Git متوجه بشه تغییری توی هرکدوم از فایلهای شما رخ نداده، فقط یه ارجاع به اون فایل توی تصویر قبلی رو توی تصویر جدید ذخیره میکنه، مثل تصویر زیر:

   

بهترین قسمت ماجرا اینه که Git سعی میکنه تا جایی که میشه برای مدیریت تاریخچه تغییرات فایلهای شما، فضای کمتری اشغال کنه (باز هم چندین برابر کمتر در مقایسه با سایر سیستمهای کنترل نسخه). یه نمونه زنده از مدیریت سورس کدهای Mozilla Firefox توسط Keith P منتشر شده که نشون میده سیستمهای کنترل نسخه چقدر توی استفاده از فضای دیسک برای مدیریت تاریخچه فایلهای شما کارآمد عمل میکنن.

مخزن CVS موزیلا 2.7 گیگابایت حجم داره که وقتی توی Subversion وارد بشه، حجمش به 8.2 گیگابایت میرسه و وقتی توی Git قرار بگیره، حجمش به 450 مگابایت کاهش پیدا میکنه. برای یه سورس کد 350 مگابایتی، خیلی خوبه که کل تاریخچه پروژه رو از سال 1998 تا الآن با کل فضای اضافه 100 مگابایتی مدیریت کنیم.

امنیت
وقتی از Git استفاده میکنید، میتونین مطمئن باشین که هیچ کسی محتوای فایلهای شما رو دستکاری نمیکنه. هرچیزی توی Git با کمک الگوریتم هش SHA-1 قبل از ذخیره سازی بررسی کنترلی (Checksum) میشه و بعد از اینکه ازش استفاده کردین، دوباره با همون مقدار Checksum کنترل میشه.

معناش اینه که غیرممکنه محتوای هر فایل یا پوشه ای رو بدون اینکه Git ازش مطلع بشه تغییر بدین. هش SHA-1 که اینجا استفاده میشه، مجموعه ای از 40 کارکتر هگزادسیمال (0-9 و A-F) هست که براساس محتوای فایل یا ساختار پوشه تولید شده. مثال:

9e79e3e9dd9672b37ac9412e9a926714306551fe

اون دسته از شما که اطلاعات کمی درباره هش دارن میتونن درباره اش از خالقش Linus Torvalds توی مصاحبه ای که با رویداد «گفتگوی فنی گوگل» انجام داد، بشنوین.

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

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

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

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

[ADMIN]

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

برای نصب Git میتونید از قسمت دانلود سایت git-scm.com استفاده کنید.

   

نصب گیت روی لینوکس
اگه میخواین Git رو روی لینوکس نصب کنین میتونین اینکار رو با ابزارهای مدیریت بسته که همراه توزیعتون هست انجام بدین. اگه از Fedora یا CentOS استفاده میکنین، میتونید از yum استفاده کنید:

# yum install git

یا اگه از یه توزیع مبتنی بر دبیان (Debian) مثل Ubuntu استفاده میکنین، میتونید apt-get رو امتحان کنید:

# apt-get install git

برای اطلاعات بیشتر درمورد نصب روی Linux به لینک زیر مراجعه کنید:
http://git-scm.com/download/linux

نصب گیت روی Mac
چند راه برای نصب Git روی Mac وجود داره. احتمالاً راحتترین راه، نصب ازطریق خط فرمان Xcode هست. توی Mavericks نسخه 10.9 یا بالاتر میتونید اینکار رو به راحتی با اجرای دستور git برای اولین بار توی ترمینال انجام بدین. اگه نصب نشده باشه، خودش به شما پیغام میده که نصبش کنید.

اگه میخواین نسخه بروزتری داشته باشین، میتونید از برنامه نصب کننده مخصوص OSX که توی لینک زیر موجوده استفاده کنید:
http://git-scm.com/download/mac

   

میتونید از برنامه نصب کننده GitHub هم برای Mac استفاده کنید. برنامه نصب گرافیکی که توی سایتشون موجوده، میتونه ابزارهای خط فرمان Git رو هم نصب کنه. میتونید این برنامه رو از لینک زیر دانلود کنید:
http://mac.github.com

نصب گیت روی ویندوز
برای نصب Git روی Windows هم راههای مختلفی وجود داره. نسخه رسمی سایت برای ویندوز ازطریق لینک زیر قابل دانلوده:
http://git-scm.com/download/win

   

دقت کنید که این پروژه، Git برای ویندوز (یا msysGit) نام داره که از خود Git جداست. برای اطلاعات بیشتر به آدرس زیر مراجعه کنید:
http://msysgit.github.io

یه راه ساده دیگه برای نصب Git، استفاده از برنامه نصب GitHub برای ویندوزه. این برنامه شامل یه نسخه خط فرمان Git هم درکنار رابط گرافیکی کاربر هست. این برنامه به خوبی با PowerShell هم کار میکنه و کش کردن یکپارچه و تنظیمات مناسب CRLF رو هم شامل میشه. درباره این چیزها کمی بعدتر توضیح میدیم ولی فعلاً همینقدر بدونید که چیزهایی هستن که لازمشون دارین. میتونید این این برنامه رو از لینک زیر دانلود کنید:
http://windows.github.com

نصب ازطریق کد منبع
بعضی افراد ممکنه نصب Git رو از روی کد منبع سودمند بدونن (چون آخرین نسخه رو دریافت میکنید). نصب کننده های باینری (برنامه های نصب) یکم عقب تر از کد منبع هستن. البته با پیشرفتی که Git در سالهای اخیر داشته، این موضوع تأثیر و تفاوت کمتری داشته.

اگه میخواین Git رو از روی کد منبعش نصب کنید، باید کتابخانه های زیر رو نصب کنید که Git بهشون وابسته است:

• curl
• zlib
• openssl
• expat
• libiconv
  

برای مثال، اگه روی سیستمی کار میکنید که از yum (مثل Fedora) یا apt-get (مثل Ubuntu) استفاده میکنه، میتونید یکی از این دستورات رو برای نصب تمام وابستگیها اجرا کنید:

# yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel

# apt-get install libcurl4-gnutls-dev libexpat1-dev gettext libz-dev libssl-dev

وقتی همه وابستگیهای موردنیاز رو نصب کردین، میتونین فایل فشرده آخرین نسخه سورس کد رو از جاهای مختلف بگیرین. برای مثال:

• https://www.kernel.org/pub/software/scm/git
• https://github.com/git/git/releases
  

عموماً توی GitHub پیدا کردن آخرین نسخه راحتتره ولی kernel.org هم امضای نسخه ها رو داره اگه میخواین نسخه ای که دانلود میکنین رو بررسی کنید.

حالا باید سورس رو کامپایل و نصب کنید:

$ tar -zxf git-1.9.1.tar.gz
cd git-1.9.1
make configure
./configure --prefix=/usr
make all doc info
make install install-doc install-html install-info

بعد از انجام این کار، حتی میتونید Git رو با کپی گرفتن از خودش، بروزرسانی کنید:

$ git clone git://git.kernel.org/pub/scm/git/git.git

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

Git با یه ابزار به اسم git config عرضه میشه که به شما اجازه دسترسی و تغییر متغیرهای مربوط به تنظیمات Git رو میده که تمام جنبه های نمایشی و عملیاتی Git رو کنترل میکنن. این متغیرها رو میشه توی 3 مکان مختلف ذخیره کر:

1. فایل etc/gitconfig/ شامل مقادیر هر کاربر توی سیستم و مخازن مربوط به همون کاربر هست. اگه از سوئیچ system-- توی دستور git config استفاده کنید، عمل خوندن و نوشتن تنظیمات با استفاده از این فایل انجام میشه.
2. فایل gitconfig./~ یا config/git/config./~ مخصوص کاربر جاری (کاربر شما) هست. میتونید با ارسال پارامتر global-- برای دستور git config متغیرهای این فایل رو بخونید یا داخلش بنویسید.
3. فایل config توی پوشه Git هر مخزنی که درحال استفاده ازش هستین (یعنی git/config. داخل پوشه پروژه خودتون که Git رو براش فعال کردین).
   

هر سطحی مقادیر سطح قبلی خودش رو رونویسی میکنه. بنابراین، مقادیر git/config. جایگزین مقادیر معادل خودشون توی etc/gitconfig/ میشن.

توی ویندوز، Git دنبال فایل gitconfig. توی مسیر HOME$ میگرده (برای اکثر کاربران میشه C:Users$USER). برای فایل etc/gitconfig/ هم توی مسیری که Git رو روی سیستمتون نصب کردین (معمولاً توی Program Files) میگرده.

هویت شما
اولین کاری که باید بعد از نصب Git انجام بدین، معرفی نام کاربری و آدرس ایمیلتونه. این کار خیلی مهمه چون Git با استفاده از این اطلاعات، تغییرات رو ثبت (Commit) میکنه و بطور دائمی و تغییرناپذیر به تمامی ارسالهایی  که انجام میدین، میچسبه.

$ git config --global user.name "Mohammad Mostafa Shahreki"
$ git config --global user.email admin@ncis.ir

مجدداً یادآوری میکنیم که اگه از سوئیچ global-- استفاده میکنید، یکبار انجام این کار کافیه و Git خودش همیشه از این اطلاعات برای هر کاری که کاربر شما توی اون سیستم انجام میده استفاده میکنه. اگه میخواین توی یه پروژه خاص اینها رو تغییر بدین، میتونید از دستور git config بدون پارامترهای global-- و system-- استفاده کنید. البته باید توی پوشه پروژه موردنظر قرار داشته باشین.
خیلی از ابزارهای گرافیکی به شما در انجام این کار وقتی اونها رو برای اولین بار اجرا میکنید، کمک میکنن.

ویرایشگر متن شما
حالا که هویتتون رو معرفی کردین، میتونید ویرایشگر متن پیشفرض رو معرفی کنید تا Git هروقت نیاز داشت که شما یه پیامی رو تایپ کنید، اجراش کنه. اگه تنظیمش نکنید، Git از ویرایشگر پیشفرض سیستم شما استفاده میکنه که معمولاً Vim هست. اگه میخواین از یه ادیتور دیگه استفاده کنید (مثلاً Emacs یا gedit) میتونید اینطوری کار کنید:

$ git config --global code.editor emacs

نقل قول:Vim و Emacs و Gedit ویرایشگرهای متنی محبوبی هستن که اغلب توسط توسعه دهندگان توی سیستمهای مبتنی بر Unix مثل لینوکس و مک استفاده میشن. اگه با هیچکدوم از این ادیتورها آشنا نیستین یا با ویندوز کار میکنید، لازمه درمورد اینکه چطور ویرایشگر متن موردنظر خودتون رو با Git تنظیم کنین، تحقیق کنید. اگه هیچ ویرایشگری رو تنظیم نکنید و با Vim و Emacs هم آشنایی نداشته باشین، ممکنه وقتی اجرا میشن با وضعیت واقعاً گیج کننده ای مواجه بشین.

چک کردن تنظیمات شما
اگه میخواین تنظیماتتون رو چک کنین، میتونید از دستور git config --list استفاده کنید:

$ git config --list
user.name=Mohammad Mostafa Shahreki
user.email=admin@ncis.ir
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...

ممکنه یکسری کلیدها رو بیشتر از یکبار ببینید چون Git اون کلید رو داره از فایلهای مختلفی (برای مثال etc/gifconfig/ و gifconfig./~) میخونه. توی چنین وضعیتهایی، آخرین مقداری که برای هر کلید ذکر میشه استفاده خواهد شد.

میتونید مقدار هر کلید رو بصورت جداگانه هم با دستور <git config <key چک کنید:

$ git config user.name
Mohammad Mostafa Shahreki

دریافت راهنمایی
اگه نیاز به راهنمایی توی استفاده از Git داشتین، سه راه مختلف برای دریافت صفحه راهنما (manpage) برای هر دستور وجود داره:

$ git help <verb>
$ git <verb> --help
$ man git-<verb>

برای مثال اگه میخواین راهنمای دستور config رو بدونید، دستور زیر رو اجرا کنین:

$ git help config

این دستورات خیلی خوبن چون میتونید از اونها در هر مکانی استفاده کنید (حتی وقتی به اینترنت وصل نیستین). اگه آموزشهای ما کافی نبودن و نیاز به راهنمای شخصی و انسانی داشتین، میتونید از کانالهای git# و github# توی سرور Freenode IRC استفاده کنید (irc.freenode.net). این کانالها بطور مرتب با صدها کاربر که اطلاعات خیلی خوبی درمورد Git دارن و اغلب اوقات هم تمایل به کمک کردن دارن، پر میشه.

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

[ADMIN]

افزایش کارایی روزانه با کمک 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 رو انتخاب کنید:

   

Git به شما یه صفحه جدید نشون میده که از شما میخواد موقعیت پوشه ای که میخواین ازش یه مخزن بسازین رو مشخص کنین. روی دکمه Browse کلیک کنید و بعد از انتخاب پوشه Workbench، روی دکمه Create کلیک کنید:

   

حالا باید صفحه ای مثل تصویر زیر ببینید:

   

این پنجره رو نبندین؛ میخوایم از این صفحه برای ادامه مفاهیم استفاده کنیم.

چه اتفاقی افتاد؟
شما با موفقیت به Git دستور دادین که پوشه Workbench شما و محتویاتش رو تحت نظر بگیره. تصویر قبل، صفحه اصلی رو نشون میده که ما خیلی باهاش سروکار داریم. این صفحه شامل 4 قسمته که اجازه بدین به این شکل صداشون بزنیم:

• Unstaged Changes تغییراتی که هنوز بعنوان یه مرحله درنظر گرفته نشدن (بالا و چپ)
• Staged Changes تغییراتی که بعنوان یه مرحله ثبت شدن (پایین و چپ)
• Differential Content محتوای تغییریافته (بالا و راست)
• Action عملیات (پایین و راست)
  

توی مثال ما، یه پوشه به اسم Workbench ساخته و بعنوان یه مخزن آماده شد. میتونید از روش مشابهی برای تبدیل یه پوشه موجود (که حاوی فایلهایی از قبل هست) به یه مخزن برای اینکه Git اون رو تحت نظر بگیره هم استفاده کنید. وقتی که این کار رو انجام دادین، فایلهای داخل پوشه توی بخش Unstaged Changes نشون داده میشن.

آماده سازی با CLI
برای اون دسته از کسانی که دوست دارن صداهای بیشتری از دکمه های صفحه کلید نسبت به کلیک ماوس بشنون، همیشه یه حالت خط فرمان وجود داره.

درصد کسانی که توی تایپ کردن سریع هستن، بطور ثابت درحال رشده که باعث میشه اولویت بیشتری به انجام کارها توسط صفحه کلید نسبت به ماوس در هر جای ممکن داده بشه. این موضوع دلیل اصلی اینه که Gmail تقریباً برای تمامی قابلیتهاش کلید میانبر تعریف کرده.

برای ایجاد یا آماده سازی مخزن با کمک رابط خط فرمان باید کارهای زیر رو انجام بدین:

1. شِل رو باز کنید (Command Prompt توی ویندوز یا Terminal/Console توی لینوکس یا مک)
2. به پوشه Workbench با کمک دستور cd منتقل بشین
3. وقتی داخل پوشه Workbench هستین، دستور git init رو تایپ کنید و کلید Enter رو بزنید.
4. باید یه پیام وضعیت از Git دریافت کنید که میگه Initialized empty Git repository in و در ادامه، مسیر پوشه Workbench شما ذکر میشه.
   

   

آه! صدای صفحه کلید، چقدر شنیدنش لذت بخشه.

چه اتفاقی افتاد؟
شما با موفقیت به GIT گفتین که پوشه Workbench و محتویاتش رو تحت نظر بگیره. init کلمه کلیدی عملیاتی هست که یه مخزن رو آماده سازی (Initialize) میکنه.

پشت صحنه
آماده سازی، یه پوشه به اسم git. داخل پوشه Workbench شما میسازه که معمولاً توسط Git بصورت مخفی و فقط خواندنی در میاد تا از حذف یا ویرایش تصادفی توسط کاربران در امان باشه. این پوشه مکانی هست که Git تمام تاریخچه فایلها و تغییرات اونها رو نگهداری میکنه.

بنابراین مراقب این پوشه باشین؛ حذف کردن اون باعث از بین رفتن تمام تاریخچه تغییرات فایلهایی که توی اون پوشه هستن میشه.

پیکربندی Git
نصب Git رو با تنظیم کردن صحیح اون باید تکمیل کنیم. دلایل مختلفی وجود دارن که چرا باید Git رو قبل از استفاده از اون پیکربندی کنید، اما بحث درمورد تمام تنظیمات Git فعلاً مقدور نیست و هروقت نیاز بود، درمورد گزینه های مختلف توضیح میدیم. فعلاً بعنوان حداقل تنظیمات، اسم و آدرس ایمیل خودمون رو به Git میگیم تا بتونه تغییراتی که ایجاد میکنیم رو تحت هویت خودمون ثبت کنه.

تنظیم Git با کمک GUI
برای اینکه به Git نام و آدرس ایمیلتون رو با کمک GUI بگین، مراحل زیر رو انجام بدین:

1. از منوی Edit گزینه Options رو انتخاب کنید.
   
      
   
   همونطور که میبینید، صفحه تنظیمات به دو نیمه تقسیم شده:
   • تنظیمات محلی (سمت چپ - مخصوص مخزن جاری که الآن Workbench هست)
   • تنظیمات سراسری (سمت راست - به تمام مخازنی که با Git نصب شده ایجاد میشن، بطور پیشفرض نسبت داده میشه)
     
2. نگذارین این صفحه بزرگ با گزینه های زیادش گیجتون کنه. فعلاً روی بخش بالایی که با کادر قرمز توی عکس بالا مشخص کردیم تمرکز کنید و نام و آدرس ایمیل خودتون رو توی هر دو بخش محلی و سراسری مثل تصویر قبل بنویسید و روی دکمه Save کلیک کنید.
   

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

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

1. پنجره Git GUI رو باز کنید. میبینید که مخزن جدید توی بخش Open Recent Repository لیست شده و میتونین انتخابش کنین. میتونید از گزینه Open Existing Repository هم برای بازکردن مخازنی که توی لیست نیستن استفاده کنید.
   
      
2. پوشه 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

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

   

چه اتفاقی افتاد؟
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 رو بزنید) :

   

حالا روی آیکن کنار اسم فایل کلیک کنید تا تغییرات به بخش Staged Changes منتقل بشن.

اگه از CLI استفاده میکنید، دستورات زیر رو اجرا کنین:

$ git status
$ git add content.docx

   

چه اتفاقی افتاد؟
ما با موفقیت فایلمون رو به مخزن اضافه کردیم. با کلیک کردن روی دکمه 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 ببرین، کارهای زیر رو انجام بدین:

1. یه فایل به اسم gitignore. داخل مخزن بسازین و این کد رو داخلش بنویسید:
   

   ~*.*
   .gitignore

2. حالا دوباره دکمه Rescan رو بزنید یا git status رو اجرا کنید تا متوجه شگفتی اون بشین (دقت کنید که باید خود gitignore. رو هم از فهرست فایلهایی که باید بررسی و اضافه بشن، خارج کنید).
   

چه اتفاقی افتاد؟
ما با موفقیت به Git دستور دادیم که فایلهای موقت و غیرضروری که خودمون یا برنامه های دیگه میسازیم رو نادیده بگیره. با اینکه اضافه کردن gitignore. یکبار انجام میشه، باید برحسب تغییراتی که توی فایلهای ناخواسته شما انجام میشه، الگوهای این فایل رو هم اصلاح کنید. ما با الگوی *.*~ گفتیم که هر فایلی با کارکتر ~ شروع میشه رو نادیده بگیره. ضمناً خود فایل gitignore. رو هم نادیده گرفتیم. البته اگه میخواین در آینده gitignore. رو هم تغییر بدین و روند این تغییرات رو هم ذخیره کنید، بهتره خود gitignore. رو به فهرست نادیده گرفتن اضافه نکنید.

لغو تغییرات
توی هر مرحله از کار قبل از ثبت (Commit) اگه بخواین میتونید یه فایل رو از وضعیت Staged به وضعیت Unstaged برگردونید. برای انجام این کار میتونید از روشهای زیر استفاده کنین:

• GUI : روی آیکن کنار اسم فایلی که توی وضعیت Staged هست کلیک کنید.
• CLI : از دستور زیر استفاده کنید:
  

  $ git reset filename.extension

ثبت (کامیت) فایلهای اضافه شده
تا حالا ما مخزن رو ساختیم، فایلها رو اضافه کردیم و تغییرات رو با مرحله بندی اونها (قراردادن اونها توی وضعیت Staged Changes) تأیید کردیم اما تا وقتی که این تغییرات رو ثبت نکنیم، فایلها تحت کنترل نسخه نخواهند بود. این مسئله بخاطر اینه که فقط وقتی شما تغییرات رو ثبت میکنید، Git محتوای فایلها رو ثبت میکنه و اون رو بعنوان یه فاز جدید از فایل/فایلها درنظر میگیره، تا دفعه بعد بتونه ازطریق مقایسه با محتوای فایلها توی این فاز، بفهمه که تغییر کردن یا نه. درواقع Git هربار محتوا رو با آخرین وضعیت ثبت (Commit) شده، مقایسه میکنه تا تغییرات رو کشف کنه.

این یه کلمه جدید توی زبان Git شماست: این فرآیند رو کامیت کردن میگن.

خوب بگذارین یه کامیت اولیه از فایلها داشته باشیم. اولین باری که یه فایل رو به مخزن اضافه و کامیت میکنید، Git فایل جدید رو ثبت میکنه. هر کامیتی بعد از اون توی این فایلها داخل همون مخزن روی این فایلها، یه کامیت برای تغییرات برمبنای آخرین نسخه از همون فایل هست که توی مخزن موجود بوده.

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

توضیحاتی که توی هر کامیت ارائه میکنید، فقط به شما یا هر کسی که تاریخچه تغییرات مخزن رو میخونه برای فهمیدن هدف و تغییرات فایلها کمک میکنه. خیلی خوبه که توضیحی بنویسید که بتونه اطلاعات خوبی بده.

کامیت کردن فایلها توی GUI
دلیل کامیت کردن این تغییرات رو توی قسمت Initial Commit Message توی بخش Action بنویسین و روی دکمه Commit کلیک کنید. با این کار، توی نوار وضعیت برنامه GUI شناسه کامیت و توضیحاتتون دیده میشه:

   

کامیت کردن فایلها توی CLI
با فرض اینکه هنوز خط فرمان رو باز دارین، این دستور رو توی پوشه مخزن اجرا کنید:

git commit -m "Initial commit to showcase the commit functionality of Git"

اگه پیغامی مشابه پیغام GUI دریافت کردین، به معنای تأیید کامیت قبلیه (که معناش اینه که از آخرین کامیت، تغییری اتفاق نیفتاده) :

   

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

من ناگهان احساس کردم که باید بجای اینکه بگم گیت یه سیستم کنترل نسخه فوق العاده و سریع و ساده است، باید بگم Git توی کارم تأثیرگذار بوده. بنابراین محتوای content.txt رو به این شکل تغییر دادم:

I love working with Git.
It increases my productivity on multiple folds when working with files which have frequent changes.

   

شما همین تازگیا یاد گرفتین که چطور تغییرات رو به وضعیت 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

1. از منوی Repository گزینه Visualize All Branch History رو انتخاب کنید تا برنامه gitk اجرا بشه. باید صفحه ای مشابه تصویر زیر ببینید:
   
      
   
   Gitk یه مرورگر مخزن گرافیکی قدرتمنده که به ما اجازه میده کارهای مختلفی رو ازقبیل نمایش تصویری (Visual) از مخزن، برچسب گذاری، برگردوندن تغییرات و... رو انجام بدیم.
   
   مجدداً تأکید میکنم از شلوغی پنجره گیج نشین؛ مرحله به مرحله با همه چیز آشنا میشیم.
   
   فعلاً بگذارین تمرکزمون روی کادر بالا و چپ باشه که مسیری رو نشون میده که دایره های رنگی مشخص کننده کامیتهایی هستن که انجام دادین و درکنار هر دایره، توضیحاتتون نوشته شده.
   
   مستقیماً پایین این کادر، قسمت SHA1 ID قرار داره که به شما ID کامیتی که توی کادر بالا انتخاب کردین رو نشون میده. همونطور که قبلاً گفتیم، ما از این ID برای شناسایی یه کامیت خاص برای بازگشت به عقب استفاده میکنیم.
2. اولین کامیت رو انتخاب کنید که میگه Initial commit to showcase the commit functionality of Git تا ID اون توی بخش SHA1 ID نمایش داده بشه و ID اون رو از کادر مربوطه، با دوبار کلیک کردن روی اون و فشردن کلیدهای Ctrl+C کپی کنید.
3. به Git GUI برگردین و از منوی Branch گزینه Checkout رو انتخاب کنید تا پنجره عملیات چک اوت ظاهر بشه (میتونید از کلیدهای Ctrl+O هم استفاده کنید). ID کامیت رو توی کادر Revisition Expression با کلیدهای Ctrl+V الصاق (Paste) کرده و روی دکمه Checkout کلیک کنید:
   
      
4. روی دکمه OK توی پنجره ظاهرشده کلیک کنید. درمورد اصطلاح Detached Checkout بعداً توی بخش شاخه سازی توضیح میدیم.
   
      
   

چه اتفاقی افتاد؟
شما با موفقیت توی زمان به عقب سفر کردین. اگه فایل content.txt رو باز کنید، میتونید محتوای قبلی اون رو مشاهده کنید.

توی هر مرحله میتونید به آخرین تغییرات برگردین. کافیه توی پنجره Checkout گزینه Local Branch رو انتخاب کنید و مطمئن بشین که master انتخاب شده و روی دکمه Checkout کلیک کنید:

   

همونطور که میبینید، دوباره به آخرین محتوای خودتون برگشتین.

آره، فوق العاده است، اینطور نیست؟

چک اوت با CLI

1. خوب بگذارین دو دستور جدید رو یاد بگیریم:
   

   $ git log
   $ git checkout COMMIT_ID

   
   دستور git log برای نمایش تاریخچه یه مخزن بکار میره و اطلاعاتی مثل ID کامیت، نویسنده، تاریخ و توضیحات مربوط به کامیت رو نشون میده. ما به ID کامیت برای استفاده های بعدی نیاز داریم:
   
      
   
   نگران حفظ کردن یه رشته 40 کارکتری نباشین. بجز قابلیت Copy و Paste خط فرمان، چوب جادویی ما (Git) قسمت سخت کار رو انجام میده و اگه 5 کارکتر اول رو تایپ کنیم، بقیه رو خودش تکمیل میکنه.
2. از دستور git checkout برای رفتن به کامیت اول استفاده کنید و محتوای فایل رو چک کنید. هروقت خواستین میتونید با دستور زیر به آخرین نسخه برگردین:
   

   $ git checkout master

بازگشت دائمی (Reset)
برخلاف چک اوت که قبلاً یاد گرفتیم، ریست کردن، یه سفر دائمی به گذشته است. سه نوع ریست وجود داره:

• سخت
• نرم
• ترکیبی
  

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

ریست با GUI

1. از منوی Repository گزینه Visualize All Branch History رو انتخاب کنید تا پنجره gitk باز بشه.
2. توی پنجره بالا و چپ میتونید تاریخچه مخزن رو ببینید. الآن فقط یه تاریخچه خطی با 2 کامیت داریم. روی اولین کامیت کلیک راست کرده و گزینه Reset master branch to here رو انتخاب کنید:
   
      
3. یه پنجره تأیید ظاهر میشه که 3 نوع ریست رو بعنوان انتخاب، در اختیارتون میگذاره. نوع Hard رو انتخای کنید و روی دکمه OK کلیک کنید:
   
      
4. gitk باید بطور خودکار بروزرسانی بشه تا به شما تاریخچه تغییریافته مخزن رو نشون بده که توی اون، از کامیتی که انتخاب کردین به بعد، دیگه کامیتی وجود نداره. اگه این اتفاق نیفتاد، خودتون از منوی File گزینه Reload رو انتخاب کنید یا کلیدهای Shift+F5 رو بزنید.
   

ریست با CLI
ریست کردن با CLI میتونه با دستورات زیر انجام بشه:

$ git log
$ git reset --hard COMMIT_ID

   

چه اتفاقی افتاد؟
تبریک میگم. ما با موفقیت مخزنمون رو بطور دائمی به یک وضعیت قبل برگردوندیم. میتونید این موضوع رو با بررسی محتوای فایلها چک کنید.

راهنمای Git
Git یه بستر دائماً درحال رشد و مطالعه است. مهم نیست که چقدر تا حالا بهش مسلط بودین. ممکنه همیشه یه چیز جدید در هربار استفاده ازش یاد بگیرین چون راههای زیادی برای انجام کارها وجود داره. تقریباً هر دستوری که میخواین توی CLI برای کار با Git بنویسین با الگوی زیر نوشته میشه:

git keyword parameters and/or values

وقتی میگیم تقریباً تمام دستورات Git محلی/آفلاین هستن، واقعاً همینطوره.

Git یه ماژول راهنمای داخلی داره که میتونه به شما هروقت توی نحوه استفاده از یه دستور خاص یا حتی اسم خود دستور شک داشتین، کمک کنه. میتونید بلافاصله به مستندات داخلی Git با دستورات زیر مراجعه کنید:

• git help برای نمایش فهرستی از پارامترهای خط فرمان و پرکاربردترین کلمات کلیدی و توضیح اونها
• git help keyword برای نمایش مرجع کامل دستور موردنظر توی مرورگر/ویرایشگر پیشفرض سیستم شما
  

جمع بندی
ما یاد گرفتیم که چطور کارهای زیر رو توی هر دو محیط GUI و CLI انجام بدیم:

• راه اندازی یه مخزن
• پیکربندی Git
• اضافه کردن فایلها به مخزن
• نادیده گرفتن فایلهای ناخواسته که توی مخزن ما قرار دارن
• کامیت کردن فایلهای جدید یا تغییرات فایلهای موجود
• سرکشی به کامیتهای قبلی در مواقعی که نیاز به مراجعه به داده های قبلی داریم و برگشت به آخرین کامیت
• ریست کردن مخزن بطور دائم به یک کامیت دلخواه و حذف تمام کامیتهای بعد از اون
• استفاده از ماژول راهنمای داخلی Git
  

خیلی زود یاد میگیرین که چطور این کارها و خیلی کارهای دیگه رو هم انجام بدین:

• مدیریت چند محیط و سوئیچ بین اونها که توسط کاربران مختلفی واردشون شدین
• ادامه دادن به ایجاد تغییرات از یه کامیت خاص و درنتیجه مدیریت مسیرهای مختلفی که توی یه مخزن ایجاد میشه (که ازنظر فنی بهش شاخه یا Branch) میگن