# سرآغاز #

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

## کنترل نسخه ##

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

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

### سیستمهای کنترل نسخه محلی ###

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

برای مقابله با این موذل، برنامه نویسان از زمان‌های بسیار قبل اقدام به توسعه VCSها زده‌اند که در بردارنده پایگاه داده ساده‌ای هستند به گونه ای که تمامی تغییرات انجام شده برروی فایل‌های هدف را در قالب کنترل نسخه نگهداری می‌کنند (تصویر 1-1)

Insert 18333fig0101.png
تصویر 1-1. دیاگرام کنترل نسخه محلی.

یکی از رایجترین ابزارهای VCS سیستمی با نام rcs بوده است، که هم اکنون نیز به همراه تعداد زیادی از کامپیوترهای امروزی نیز توزیع می‌شود. حتی سیستم عامل رایج Mac OS X نیز با نصب ابزارهای توسعه توسط کاربر برروی آن، دستور خط فرمان rcs را در اختیار فرد قرار می‌دهد. این ابزار به زبانی ساده با حفظ مجموعه‌ای از وصله‌ها (که تغییرات بین فایل‌ها می‌باشند) از یک نسخه به نسخه‌ای دیگر در قالب فرمتی خاص برروی دیسک عمل می‌کند؛ این ابزار با اجرای چنین سیستمی قادر است با متصل کردن وصله‌ها به یکدیگر توانایی بازسازی هر فایلی را در هر لحظه‌ای از زمان داشته باشد.

### سیستمهای کنترل نسخه‌ مرکزی ###

مسئله مهم دیگری که کاربران با آن مواجه می‌شوند، نیاز آن‌ها به همکاری با دیگر توسعه‌دهندگان برروی سیستم‌های دیگر است. برای حل این مسئله، سیستم‌های کنترل نسخه مرکزی (CVCSs) توسعه یافتند. چنین سیستم‌هایی مانند CVS، Subversion و Perforce در بردارنده سروری مرکزی هستند که تمامی نسخه‌های فایل‌ها و حتی کاربرانی که این فایل‌ها را از این مکان مرکزی checkout کرده‌اند در خود نگهداری می‌کند. برای سال‌های زیادی، چنین روشی، روشی استاندارد برای کنترل نسخه بوده است (تصویر 1-2).

Insert 18333fig0102.png
تصویر 1-2. دیاگرام کنترل نسخه مرکزی.

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

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

### سیستمهای کنترل نسخه پخشی ###

اینجا است که سیستم‌های کنترل نسخه پخشی (DVCSs) نمود پیدا می‌کنند. در یک DVCS (مانند Git، Mercurial، Bazaar یا Darcs) کابران به checkout کردن آخرین تصویر لحظه‌ای فایل‌ها اکتفا نمی‌کنند: آن‌ها مخزن را نیز به‌صورت کامل کپی می‌کنند. بنابراین اگر هر سروری که سیستم‌ها به واسطه آن در حال تعامل با یکدیگر هستند متوقف و از کار بیافتد، با کپی مخرن هر کدام از کاربران برروی سرور، عمل بازیابی انجام می‌گیرد. در واقع هر checkoutای، پشتیبان کاملی از تمامی داده‌ها است.

Insert 18333fig0103.png
تصویر 1-3. دیاگرام کنترل نسخه پخشی.

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

## تاریخچه کوتاهی از Git ##

همانند اکثر حوادث بزرگ در در زندگی، Git نیز با خلاقیتی مخرب و جنجالی آتشین شروع شد. هسته لینوکس پروژه نرم‌افزاری متن باز با وسعت نسبتاً زیادی است. جهت نگهداری هسته لینوکس برای مدت زمان زیادی (1991 - 2002) تغییرات نرم‌افزاری به واسطه وصله‌ها و فایل‌های بایگانی شده انتقال پیدا می‌کرد. در سال 2002، پروژه هسته لینوکس شروع به استفاده از سیستم DVCS خصوصی با نام BitKeeper کرد.

در سال 2005، ارتباط بین مجموعه تیم توسعه دهنده هسته لینوکس و شرکت تجاری توسعه دهنده BitKeeper گسسته شد و وضعیت ابزاری که قبل از آن  به صورت رایگان عرضه می‌گشت تغییر پیدا کرد. این اتفاق زنگ هشداری برای مجموعه تیم توسعه دهنده لینوکس (به خصوص مؤسس لینوکس، لینوس تورلوادز) بود که بر اساس تجربه‌های کسب شده در استفاده از BitKeeper، خود اقدام به تولید نرم افزاری در این زمینه بزنند. مواردی از اهداف سیستم جدید عبارت بودند از:

*  	سرعت
*	طراحی ساده
*	پشتیبانی قوی از توسعه غیر خطی (هزاران انشعاب موازی)
*	کاملاً پخشی
* 	قابلیت کنترل بهینه پروژه‌های بزرگ همانند هسته لینوکس (از نظر سرعت و اندازه داده)

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

## مقدمات Git ##

خوب، Git چیست؟ این بخش از نظر یادگیری، بخشی مهم قلمداد می شود، زیرا اگر فرد از پایه و اساس عملکرد Git  اطلاع پیدا کند، آنگاه خواهد توانست آسان‌تر در استفاده مؤثر از آن بهره جوید. در حین یادگیری Git، بهتر است فرد ذهن خود را از مواردی که احیاناً در رابطه با دیگر VCSها همانند Subversion و Perforce می‌داند تخلیه کند؛ بدین سبب از بروز اشتباهات موردی در استفاده از این ابزار پیشگیری می‌شود. با وجود آن‌که رابط کاربری Git نسبتاً مشابه با دیگر سیستم‌ها است، ولی در ذخیره سازی و نگاه به اطلاعات، دید بسیار متفاوتی در مقایسه با دیگر سیستم‌ها دارد؛ دانستن این تفاوت‌ها می‌تواند به فرد در جلوگیری از  بروز اشتباهات بعدی در استفاده از این ابزار یاری دهد.

### تصاویر لحظه‌ای، نه تفاوتها ###

اصلی‌ترین تفاوت بین Git و دیگر VCSها (که شامل Subversion و هم خانواده های آن نیز می‌شود) دیدگاهی است که Git نسبت به داده‌های خود دارد. از نظر مفهومی، اکثریت دیگر سیستم‌ها اطلاعات را به مثابه لیستی از تغییرات بر مبنای فایل، ذخیره می‌کنند. این سیستم‌ها (CVS، Subversion، Perfoce، Bazaar و غیره) همان‌طور که در تصویر 1-4 نشان داده شده است، به اطلاعاتی که نگهداری می‌کنند به شکل مجموعه‌ای از فایل‌ها و تغییراتی که برروی هر فایل در مرور زمان انجام گرفته است، می‌نگرند.


Insert 18333fig0104.png
تصویر 1-4. دیگر سیستم‌ها داده‌ها به شکل تغییرات در نسخه پایه هر فایل ذخیره می‌کنند.

سGit از چنین تفکر یا روش ذخیره سازی داده‌ای پیروی نمی‌کند. در عوض دیدگاه Git نسبت به داده‌های خود به شکل تصاویر لحظه‌ای از یک سیستم فایلی کوچک است. هر زمانی که شخص commitای انجام می‌دهد یا وضعیت پروژه خود را در Git ذخیره می‌کند، در اصل تصویری از وضعیت تمامی فایل‌ها در لحظه موردنظر تهیه و ارجاعی به تصویر لحظه‌ای ایجاد شده ذخیره می شود. برای آن‌که این عمل به صورت بهینه انجام پذیرد، اگر در فایلی تغییری ایجاد نشده باشد، Git اقدام به ذخیره سازی مجدد فایل نمی‌کند - تنها پیوندی به نسخه مشابه آن فایل که قبلاً ذخیره شده است را ذخیره می کند. طریقه نگرش Git به داده در تصویر 1-5 نمایش داده شده است.

Insert 18333fig0105.png
تصویر 1-5. Git داده‌ها را به شکل تصاویر لحظه‌ای از پروژه در مرور زمان نگهداری می‌کند.

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

### تقریباً تمام عملیات به صورت محلی انجام می‌پذیرد ###

اکثر عملیاتی که در Git انجام می‌پذیرد جهت اجرا تنها نیازمند فایل‌ها و منابع محلی هستند - به‌طور کلی نیازمند هیچ‌گونه اطلاعاتی از کامپیوتری دیگر در شبکه نیست. اگر شما فردی هستید که به CVCSای عادت کرده‌اید که در آن اکثر فعالیت‌ها دارای افزونگی رکود شبکه‌ای داشته‌اند، شاید این مزیت Git این فکر را برای شما تداعی کند که خدایان سرعت Git را با قدرتی وصف ناشدنی مورد لطف و رحمت قرار داده‌اند. از آن جهت که تمامی تاریخچه پروژه برروی دیسک محلی قرار دارد، به نظر می‌رسد که اکثر عملیات به صورت لحظه‌ای و بلادرنگ انجام می‌پذیرند.

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

همچنین بدین معناست که در صورت آفلاین بودن و یا وصل نبودن به VPN دامنه عملکرد شخص زیاد محدود نمی‌شود. اگر سوار بر هواپیما یا قطار شده باشید و تصمیم به انجام کاری داشته باشید، می‌توانید به راحتی commit را انجام داده و زمانی که دسترسی به شبکه پیدا کردید آپلود را انجام دهید. اگر به خانه رفته باشید و قادر به فعال سازی VPN خود نشده باشید، باز هم وقفه‌ای در کار شما حاصل نمی‌شود. در اکثریت دیگر سیستم‌ها انجام این موارد غیرممکن یا به سختی انجام می‌پذیرد. به عنوان مثال در Perforce، در صورتی که به شبکه متصل نباشید در واقع توانایی انجام کاری نخواهید داشت؛ در Subversion و CVS، امکان دست‌کاری فایل‌ها برای شما وجود دارد، ولی برای commit تغییرات روی پایگاه داده محدودیت دارید (زیرا اتصال شما به پایگاه داده بر قرار نیست). شاید این موضوع مسئله مهمی به نظر نیاید، ولی شاید با مشاهده تفاوت‌های بزرگی که می‌تواند به موجب آن ایجاد شود، شگفت زده شوید.

### Git صداقت دارد ###

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

مکانیزمی که Git برای تولید checksum استفاده می‌کند، هش SHA-1 است. این هش یک رشته 40 کاراکتری از کاراکترهای مبنای شانزده است (0 - 9 و a - f) که از روی محتویات فایل و یا ساختار پوشه موردنظر در Git محاسبه می‌گردد. در ادامه یک نمونه از هش SHA-1 آورده شده است:


	24b9da6552252987aa493b52f8696cd6d3b00373

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

### عموماً Git فقط داده اضافه میکند ###

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

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

### سه وضعیت ###

توجه، توجه. اگر می‌خواهید پروسه یادگیری Git را بدون دردسر ادامه دهید، این بخش را به دقت مطالعه کنید. فایلها در Git می‌توانند در سه وضعیت اصلی قرار داشته باشند: committed، modified و staged. committed بدین معناست که فایل موردنظر در پایگاه داده محلی ذخیره شده است. modified یعنی تغییری در فایل ایجاد شده است ولی هنوز commitای از این فایل روی پایگاه داده انجام نگرفته است. فایلی که در وضعیت staged قرار گرفته است، فایلی تغییر یافته است که نسخه فعلی آن در تصویر لحظه‌ای بعدی جهت commit نشانه‌گذاری شده است.

حال می‌توان سه بخش اصلی پروژه Git را معرفی کرد: پوشه Git، پوشه در حال کار (working directory) و staging area.

Insert 18333fig0106.png
تصویر 1-6. پوشه در حال کار، staging area و پوشه Git

در Git، metadata و پایگاه داده پروژه در پوشه Git ذخیره می‌شوند. این قسمت مهمترین بخش Git است، در واقع هنگامی که از مخزن کامپیوتری cloneای گرفته می‌شود، کپی از این پوشه ایجاد می‌گردد.

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

staging area عموماً از یک فایل ساده تشکیل شده است که محتوی اطلاعاتی است که مشخص می‌کند که چه چیزهایی در commit بعدی قرار می‌گیرند. معمولاً این فایل را index می‌نامند ولی عبارت staging area نیز در حال تبدیل شدن به نامی استاندارد برای چنین فایلی است.

روند کاری Git عموماً به صورت ذیل است:

1. ایجاد تغییرات روی فایل‌های واقع در پوشه در حال کار.
2. stage کردن فایل‌ها و اضافه کردن تصاویر لحظه‌ای فایلها به staging area.
3. commit کردن، که به موجب آن وضعیت فعلی فایل‌ها در staging area تحت یک تصویر لحظه‌ای به صورت دائمی در پوشه Git ذخیره می‌گردد.

اگر نسخه‌ای از یک فایل در پوشه git قرار داشته باشد، commit شده فرض می‌شود. اگر تغییری در فایل ایجاد شده باشد و به staging area اضافه شده باشد، گوییم staged شده است. و اگر در فایل از آخرین مرتبه‌ای که checkout شده است تغییری ایجاد شده باشد ولی staged نشده باشد، گوییم modified شده است. در فصل 2، با این وضعیت‌ها بیشتر آشنا خواهید شد و یاد خواهید گرفت که چگونه می‌توان از آن‌ها به نحو احسنت استفاده کرد و یا حتی به صورت کامل از روی مرحله stage پرش کرد.

## نصب Git ##

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

### نصب از طریق سورس ###

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

برای نصب Git نیاز به کتابخانه های curl، zlib، openssl، expat و libiconv است که Git نیازمند آنهاست. به عنوان مثال، اگر روی سیستمی کار می‌کنید که yum (مانند Fedora) یا apt-get (مانند سیستم های مبتنی بر Debian) دارد، می‌توانید برای نصب این بسته‌های نیازمندی از دستورهای ذیل استفاده کنید:

	$ 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

حال که تمامی نیازمندی‌ها نصب گردید، می‌توان آخرین نسخه Git را از وب سایت آن دانلود کرد:

	http://git-scm.com/download

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

	$ tar -zxf git-1.7.2.2.tar.gz
	$ cd git-1.7.2.2
	$ make prefix=/usr/local all
	$ sudo make prefix=/usr/local install

بعد از کامل شدن این مراحل می‌توان از خود Git برای دریافت آپدیت‌های Git استفاده کرد:

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

### نصب بر روی لینوکس ###

اگر قصد نصب Git بر روی لینوکس به واسطه یک نصاب باینری را دارید، می‌توانید این کار را از طریق ابزار مدیریت بسته های نرم‌افزاری که همراه توزیع موردنظر شما ارائه می‌شود انجام دهید. اگر توزیع شما Fedora است، می‌توانید از yum استفاده کنید:

	$ yum install git-core

یا اگر توزیعی مبتنی بر Debian مانند Ubuntu دارید، می‌توانید از apt-get استفاده کنید:

	$ apt-get install git

### نصب برروی Mac ###

برای نصب برروی Mac دو روش آسان وجود دارد. آسان‌ترین روش استفاده از نصاب گرافیکی Git است، که امکان دانلود آن از صفحه Google Code وجود دارد (تصویر 1-7):

	http://code.google.com/p/git-osx-installer

Insert 18333fig0107.png
تصویر 1-7. نصاب Git OS X

روش دیگر نصب از طریق MacPortها (`http://www.macports.org`) است. اگر MacPortها را نصب شده روی سیستم خود دارید، می‌توانید Git را با دستور ذیل نصب کنید

	$ sudo port install git-core +svn +doc +bash_completion +gitweb

نیازی به افزودن تمامی اضافات نیست، ولی شاید برای استفاده از Git به همراه مخازن Subversion، احتمالاً افزودن +svn  گزینه مناسبی است.

### نصب بر روی ویندوز ###

نصب Git روی ویندوز بسیار آسان است. پروژه msysGit یکی از آسان‌ترین مراحل نصب را دارد. تنها نیاز است که فایل نصاب exe را از صفحه GitHub دانلود، و آن را اجرا کرد:

	http://msysgit.github.com/

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

نکته برای کابران ویندوز: کاربر باید جهت کار با Git از پوسته ارائه شده به همراه msysGit (به سبک Unix) استفاده کند، تا بتواند دستورات چند خطی پیچیده‌ای که در این کتاب آورده شده را اجرا کند. اگر به هر دلیلی، نیاز به استفاده از پوسته خود ویندوز/کنسول خط فرمان، شدید باید در عوض تک کوت (simple quote) از دابل کوت  (برای پارامترهایی که در بر دارنده فاصله هستند) استفاده کنید و باید پارامترهای موجود در آخرین خط که با circumflex accent (^) به پایان می‌رسند را داخل کوت قرار دهید، زیرا این علامت، نشانگر ادامه دار بودن خط در ویندوز است.

## تنظیمات شروع به کار Git ##

حال که Git روی سیستم نصب شده است، نیاز به شخصی‌سازی بعضی از منابع Git است. انجام این تنظیمات فقط برای یک مرتبه انجام می‌پذیرد؛ و بعد از آن با هر بار ارتقاء بدون تغییر باقی می‌مانند. همچنین امکان تغییر آن‌ها در هر زمانی که نیاز باشد به کمک خط فرمان وجود دارد.

به همراه Git ابزاری ارائه شده است با نام git config که امکان خواندن و اعمال متغیرهای تنظیماتی که تمامی ابعاد ظاهری و عملیاتی Git را کنترل می‌کند فراهم می‌سازد.

*  فایل `/etc/gitconfig`: حاوی مقادیر تمامی کاربران سیستم  و مخازن آن‌ها است. اگر به همراه `git config` از گزینه `--system` استفاده شود، خواندن و نوشتن به صورت اختصاصی از این فایل انجام می‌پذیرد.
*  فایل `~/.gitconfig`: مختص کاربر مشخصی است. با استفاده از گزینه `--global` خواندن و نوشتن Git به صورت اختصاصی از این فایل انجام می‌پذیرد.
*  فایل config موجود در پوشه git (`.git/config`) یا هر مخزنی که در حال استفاده از آن می‌باشید: مختص یک مخزن خاص است. مقادیر هر سطح باعث لغو مقادیر سطح قبلی خود می‌شود. بنابراین مقادیر `.git/config` موجب لغو مقادیر `/etc/gitconfig` خواهد شد.

در سیستم‌های ویندوزی، Git در پوشه `$HOME` (متغیر محیطی `%USERPROFILE%` در ویندوز) که برای اکثر کاربران با توجه به نسخه سیستم در مسیرهای `C:\Documents and Settings\$USER‍ یا `C:\Users\$USER` (`$USER‍ در ویندوز متغیر محیطی `%USERNAME%`) قرار دارد، فایل `.gitconfig` را جستجو می‌کند. همچنین نسبت به مسیر ریشه MSys که همان مسیر نصب انتخاب شده در هنگام اجرای نصاب Git در ویندوز می‌باشد، به دنبال فایلی با نام /etc/gitconfig می‌گردد.

### شناسه کاربر ###

اولین عملی که بعد از نصب Git باید انجام شود، مقداردهی دو متغیر نام کاربری (user name) و آدرس پست الکترونیکی (e-mail address) است. این عمل از آن جهت اهمیت دارد که در هر commit این اطلاعات به‌صورتی تغییر ناپذیر روی commit انجام شده حک می‌شوند.

	$ git config --global user.name "John Doe"
	$ git config --global user.email johndoe@example.com

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

### ویرایشگر کاربر ###

حال که شناسه تنظیم شد، می‌توان ویرایشگر متن پیش فرضی را معرفی کرد تا هنگامی که نیاز به درج پیغامی در Git است فراخوانی شود. به صورت پیش فرض Git از ویرایشگر پیش فرض سیستم برای این امر استفاده می کند، که معمولاً Vi یا Vim است. اگر نظر شخص به استفاده از ویرایشگر متنی متفاوتی مانند Emacs باشد، می‌توان به صورت ذیل عمل کرد:

	$ git config --global core.editor emacs

### ابزار Diff ###

ابزار مفید دیگری که شاید نیاز به تنظیم داشته باشد، ابزار diff پیش فرضی است که برای رفع مغایرت ایجاد شده در هنگام اجرای دستور merge استفاده می‌گردد. به عنوان مثال اگر هدف استفاده از vimdiff باشد خواهیم داشت:

	$ git config --global merge.tool vimdiff

سGit از ابزارهای kdiff3، tkdiff، meld، xxdiff، emerge، vimdiff، gvimdiff، ecmerge و opendiff جهت merge پشتیبانی می‌کند. با این وجود امکان تعریف ابزاری شخصی نیز وجود دارد؛ برای اطلاعات بیشتر جهت انجام این مورد می‌توانید به فصل 7 مراجعه کنید.

### بررسی تنظیمات ###

برای مشاهده و بررسی تنظیمات، می‌توان از دستور `git config --list` استفاده کرد که در نتیجه آن Git تمامی تنظیمات موجود تا آن لحظه را در قالب لیستی نمایش می‌دهد:

	$ git config --list
	user.name=Scott Chacon
	user.email=schacon@gmail.com
	color.status=auto
	color.branch=auto
	color.interactive=auto
	color.diff=auto
	...

احتمال دارد در این لیست کلیدهایی بیش از یک بار مشاهده شوند، دلیل این امر آن است که Git کلید مشابهی را از فایل‌های مختلفی (مانند `/etc/giconfig` و `~/.gitconfig`) خوانده است. در این‌گونه موارد، Git آخرین مقدار کلید منحصر به فردی که مشاهده می‌کند را جهت استفاده به‌کار می‌گیرد.

همچنین برای مشاهده مقدار مورد استفاده یک کلید خاص توسط Git، می‌توان از دستور `git config {key}` استفاده کرد:

	$ git config user.name
	Scott Chacon

## دریافت راهنمایی ##

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

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

برای مثال، برای مشاهده صفحه راهنما دستور config داریم

	$ git help config

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

## خلاصه ##

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