کار با گیت را شروع کنیم

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

درباره کنترل نسخه

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

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

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

یکی از محبوب‌ترین ابزارهای کنترل نسخه، سیستمی به نام RCS بود که هنوز با بسیاری از کامپیوترها توزیع می‌شود. RCS با ذخیره مجموعه‌های تغییرات (یعنی تفاوت‌های بین فایل‌ها) در قالبی خاص بر روی دیسک کار می‌کرد؛ سپس می‌توانست با جمع‌بندی تمام تغییرات، هر فایل را در هر لحظه‌ای بازسازی کند.

لینک RCS در گنو:

https://www.gnu.org/software/rcs/

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

مسئله مهم بعدی که افراد با آن مواجه می‌شوند این است که نیاز دارند با توسعه‌دهندگان دیگر در سیستم‌های دیگر همکاری کنند. برای حل این مشکل، سیستم‌های کنترل نسخه متمرکز (CVCS) توسعه یافتند. این سیستم‌ها (مانند CVS، Subversion و Perforce) دارای یک سرور مرکزی هستند که تمام فایل‌های نسخه‌بندی‌شده را در خود دارد و تعدادی از کلاینت‌ها که فایل‌ها را از آنجا دریافت می‌کنند. این سیستم‌ها برای سال‌ها استاندارد کنترل نسخه بوده‌اند.

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

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

سیستم‌های کنترل نسخه توزیع‌شده

در اینجا سیستم‌های کنترل نسخه توزیع‌شده (DVCS) وارد می‌شوند. در DVCS (مانند Git، Mercurial یا Darcs)، کلاینت‌ها فقط آخرین نسخه فایل‌ها را بررسی نمی‌کنند؛ بلکه کل مخزن را با تمام تاریخچه آن بازتاب می‌دهند. بنابراین، اگر هر سروری از بین برود و این سیستم‌ها از طریق آن سرور همکاری می‌کردند، هر یک از مخازن کلاینت می‌تواند برای بازگردانی سرور استفاده شود. هر کلون واقعاً یک نسخه پشتیبان کامل از تمام داده‌هاست.

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

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

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

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

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

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

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

گیت Git چیست؟

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

تصاویر فوری، نه تفاوت‌ها

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

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

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

تقریباً تمام عملیات‌ها محلی هستند

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

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

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

گیت Git دارای یکپارچگی است

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

مکانیزمی که Git برای این چک‌سام استفاده می‌کند به نام SHA-1 hash است. این یک رشته ۴۰ کاراکتری است که از اعداد هگزا دسیمال (0–9 و a–f) تشکیل شده و بر اساس محتوای یک فایل یا ساختار دایرکتوری در Git محاسبه می‌شود. یک SHA-1 hash چیزی شبیه به این است:

24b9da6552252987aa493b52f8696cd6d3b00373

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

گیت Git تقریباً فقط داده‌ها را اضافه می‌کند

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

سه وضعیت در Git

گیت Git سه وضعیت اصلی دارد که فایل‌های شما می‌توانند در آن‌ها باشند: تغییر داده‌شده (modified)، آماده‌شده (staged)، و ثبت‌شده (committed):

• تغییر داده‌شده به این معنی است که شما فایل را تغییر داده‌اید اما هنوز آن را به پایگاه داده خود اضافه نکرده‌اید.
• آماده‌شده به این معنی است که شما یک فایل تغییر داده‌شده را برای اضافه شدن به snapshot بعدی آماده کرده‌اید.
• ثبت‌شده به این معنی است که داده به‌طور امن در پایگاه داده محلی شما ذخیره شده است.

این موضوع ما را به سه بخش اصلی یک پروژه گیت می‌رساند: پوشه کاری (working tree)، منطقه آماده‌سازی (staging area) و دایرکتوری گیت (Git directory).

• پوشه کاری یک چک‌اوت checkout از یک نسخه پروژه است. این فایل‌ها از پایگاه داده فشرده Git بیرون کشیده و روی دیسک برای استفاده یا تغییر قرار داده می‌شوند.
• منطقه آماده‌سازی فایلی است که اطلاعاتی در مورد آنچه در snapshot بعدی وارد خواهد شد، ذخیره می‌کند.
• دایرکتوری Git جایی است که گیت، متاداده‌ها و پایگاه داده اشیاء پروژه شما را ذخیره می‌کند.

جریان کاری پایه در Git به این شکل است:

1. فایل‌ها را در پوشه کاری (working tree) خود تغییر می‌دهید.

2. به‌صورت انتخابی، فقط تغییراتی که می‌خواهید در commit بعدی شامل شوند را stage می‌کنید، که این تغییرات به منطقه آماده‌سازی (staging area) اضافه می‌شوند.

3. سپس commit می‌کنید که فایل‌ها را به همان شکلی که در منطقه آماده‌سازی هستند، به‌طور دائمی در دایرکتوری Git ذخیره می‌کند.

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

خط فرمان

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

همچنین، در حالی که انتخاب رابط گرافیکی شما به سلیقه شخصی بستگی دارد، همه کاربران ابزارهای خط فرمان را نصب و در دسترس خواهند داشت. بنابراین، ما از شما انتظار داریم بدانید چگونه Terminal را در macOS یا Command Prompt یا PowerShell را در Windows باز کنید. اگر نمی‌دانید این‌ها چیست، ممکن است لازم باشد سریعاً در این مورد تحقیق کنید تا بتوانید ادامه مثال‌ها و توضیحات این کتاب را دنبال کنید.

نصب Git

پیش از شروع به استفاده از Git، باید آن را روی رایانه خود نصب کنید. حتی اگر از قبل نصب شده باشد، بهتر است آن را به آخرین نسخه به‌روزرسانی کنید. می‌توانید Git را به‌صورت بسته (package) نصب کنید یا با استفاده از یک نصب‌کننده دیگر (installer) آن را نصب کنید. همچنین می‌توانید کد منبع را دانلود و آن را خودتان کامپایل کنید.

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

نصب در لینوکس

برای نصب ابزارهای اصلی Git در لینوکس از طریق یک نصب‌کننده باینری، معمولاً می‌توانید از ابزار مدیریت بسته (package management) که همراه با توزیع شما است، استفاده کنید. اگر از Fedora یا هر توزیع دیگر مبتنی بر RPM، مانند RHEL یا CentOS استفاده می‌کنید، می‌توانید از دستور `dnf` استفاده کنید:

sudo dnf install git-all

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

sudo apt install git-all

برای گزینه‌های بیشتر، دستورالعمل‌های نصب بر روی توزیع‌های مختلف یونیکس در وب‌سایت Git در دسترس است: [https://git-scm.com/download/linux].

نصب در macOS

روش‌های مختلفی برای نصب Git در macOS وجود دارد. ساده‌ترین روش احتمالاً نصب Xcode Command Line Tools است. در نسخه Mavericks (10.9) یا بالاتر، می‌توانید با اجرای دستور `git` در Terminal برای اولین بار، به‌سادگی این ابزارها را نصب کنید:

git --version

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

اگر به نسخه به‌روزتری نیاز دارید، می‌توانید Git را از طریق یک نصب‌کننده باینری نصب کنید. نصب‌کننده Git برای macOS توسط وب‌سایت Git نگهداری و در دسترس است: [https://git-scm.com/download/mac].

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

چند روش مختلف برای نصب Git در ویندوز وجود دارد. رسمی‌ترین نسخه برای دانلود در وب‌سایت Git در دسترس است. کافی است به آدرس [https://git-scm.com/download/win] بروید و دانلود به صورت خودکار شروع می‌شود. توجه داشته باشید که این پروژه به نام Git for Windows شناخته می‌شود که از Git اصلی جدا است. برای اطلاعات بیشتر به [https://gitforwindows.org] مراجعه کنید.

برای نصب خودکار، می‌توانید از پکیج Git Chocolatey استفاده کنید. توجه داشته باشید که این پکیج توسط جامعه توسعه‌دهندگان نگهداری می‌شود.

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

نصب از منبع (Source)

برخی از کاربران ممکن است بخواهند Git را از منبع (source) نصب کنند، زیرا این روش به شما امکان می‌دهد آخرین نسخه را دریافت کنید. نصب‌کننده‌های باینری معمولاً کمی عقب‌تر هستند، اگرچه با توجه به بلوغ Git در سال‌های اخیر، این موضوع کمتر اهمیت پیدا کرده است.

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

sudo dnf install dh-autoreconf curl-devel expat-devel gettext-devel \
openssl-devel perl-devel zlib-devel
sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \
gettext libz-dev libssl-dev

برای اضافه کردن مستندات (doc, html, info)، این وابستگی‌های اضافی مورد نیاز است:

sudo dnf install asciidoc xmlto docbook2X
sudo apt-get install asciidoc xmlto docbook2x

کاربران RHEL و توزیع‌های مشتق شده از RHEL مانند CentOS و Scientific Linux باید مخزن EPEL را برای دانلود بسته docbook2X فعال کنند.

اگر از توزیع‌های مبتنی بر دبیان (Debian/Ubuntu/مشتقات اوبونتو) استفاده می‌کنید، باید بسته install-info را نیز نصب کنید:

sudo apt-get install install-info

اگر از توزیع‌های مبتنی بر RPM (Fedora/RHEL/مشتقات RHEL) استفاده می‌کنید، باید بسته getopt را نصب کنید:

sudo dnf install getopt

علاوه بر این، اگر از Fedora/RHEL استفاده می‌کنید، لازم است این لینک سمبلیک را به دلیل تفاوت در نام‌های باینری ایجاد کنید:

sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi

پس از نصب تمام وابستگی‌های لازم، می‌توانید آخرین نسخه انتشار یافته از Git را دانلود کنید. می‌توانید این کار را از سایت kernel.org [https://www.kernel.org/pub/software/scm/git] یا از لینک جایگزین موجود در GitHub [https://github.com/git/git/tags] انجام دهید.

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

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

پس از اتمام نصب، می‌توانید Git را از طریق خود Git نیز به‌روزرسانی کنید:

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

تنظیمات اولیه گیت Git

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

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

1. فایل `[path]/etc/gitconfig` که مقادیر را برای تمامی کاربران سیستم و مخازن آن‌ها اعمال می‌کند. برای نوشتن در این فایل باید از گزینه `--system` استفاده کنید. برای تغییر این فایل نیاز به دسترسی مدیر یا superuser دارید.

2. فایل `~/.gitconfig` یا `~/.config/git/config` که مقادیر خاص کاربر شما را ذخیره می‌کند. برای نوشتن در این فایل از گزینه `--global` استفاده کنید تا تمامی مخازن شما تحت تأثیر قرار گیرند.

3. فایل `config` در دایرکتوری Git (یعنی `.git/config`) مربوط به مخزنی که هم‌اکنون در حال استفاده از آن هستید.

هر سطح از تنظیمات در Git تنظیمات سطوح قبلی را نادیده می‌گیرد، بنابراین مقادیر موجود در فایل `.git/config` از تنظیمات موجود در `[path]/etc/gitconfig` پیشی می‌گیرد.

در سیستم‌های ویندوزی، Git به دنبال فایل `.gitconfig` در دایرکتوری $HOME (معمولاً C:\Users\$USER برای بیشتر کاربران) است. همچنین Git به دنبال فایل `[path]/etc/gitconfig` نیز خواهد بود، اما به ریشه MSys وابسته است که بستگی به مکانی دارد که شما Git را در سیستم ویندوز خود نصب کرده‌اید. اگر از نسخه 2.x یا بالاتر Git برای ویندوز استفاده می‌کنید، یک فایل پیکربندی سیستم در آدرس `C:\Documents and Settings\All Users\Application Data\Git\config` برای ویندوز XP و در آدرس `C:\ProgramData\Git\config` برای ویندوز ویستا و نسخه‌های جدیدتر نیز وجود دارد. این فایل پیکربندی فقط توسط دستور `git config -f <file>` با دسترسی مدیر قابل تغییر است.

برای مشاهده تمام تنظیمات خود و مبدا آن‌ها می‌توانید از دستور زیر استفاده کنید:

git config --list --show-origin

هویت Identity شما

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

git config --global user.name &quotJohn Doe&quot

git config --global user.email johndoe@example.com

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

بسیاری از ابزارهای گرافیکی (GUI) نیز به شما در انجام این کار کمک می‌کنند.

ویرایشگر Editor متنی شما

پس از تنظیم هویت، می‌توانید ویرایشگر متنی پیش‌فرضی که Git از آن برای نوشتن پیام‌ها استفاده می‌کند، پیکربندی کنید. اگر پیکربندی نشده باشد، Git از ویرایشگر پیش‌فرض سیستم شما استفاده می‌کند.

اگر می‌خواهید از ویرایشگر دیگری مثل Emacs استفاده کنید، می‌توانید دستور زیر را اجرا کنید:

git config --global core.editor emacs

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

برای مثال، اگر از Notepad++ که یک ویرایشگر محبوب برنامه‌نویسی است استفاده می‌کنید، احتمالاً از نسخه 32 بیتی استفاده خواهید کرد، زیرا در زمان نگارش این متن نسخه 64 بیتی از همه پلاگین‌ها پشتیبانی نمی‌کند. در سیستم‌های 32 بیتی یا ویرایشگرهای 64 بیتی روی سیستم‌های 64 بیتی، شما باید چیزی شبیه به این بنویسید:

git config --global core.editor &quot'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin&quot

نام شاخه پیش‌فرض default branch شما

به طور پیش‌فرض، Git هنگام ایجاد مخزن جدید با دستور `git init`، یک شاخه به نام `master` ایجاد می‌کند. از نسخه 2.28 به بعد، می‌توانید نام دیگری برای شاخه ابتدایی تنظیم کنید. برای تنظیم شاخه `main` به عنوان نام شاخه پیش‌فرض، از این دستور استفاده کنید:

git config --global init.defaultBranch main

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

اگر می‌خواهید تنظیمات پیکربندی خود را بررسی کنید، می‌توانید از دستور `git config --list` استفاده کنید تا تمام تنظیمات موجود را لیست کنید:

git config --list
user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto

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

همچنین می‌توانید بررسی کنید که Git برای یک کلید خاص چه مقداری را در نظر می‌گیرد، با تایپ کردن دستور:

git config user.name
John Doe

دریافت کمک

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

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

برای مثال، می‌توانید با اجرای دستور زیر راهنمای `git config` را دریافت کنید:

git help config

همچنین اگر نیاز به کمک بیشتری داشتید، می‌توانید از کانال‌های IRC مانند `#git`، `#github` یا `#gitlab` در سرور Libera Chat که در آدرس [libera.chat](https://libera.chat) قابل دسترسی است، استفاده کنید. این کانال‌ها معمولاً با صدها فرد آشنا به Git پر هستند و غالباً تمایل به کمک دارند.

خلاصه فصل

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