آشنایی کامل با گیت: از مقدمات تا حرفه‌ای شدن قسمت ۱

مقدمه:

توی پست قبلی (پست قبلی) من اومدم یه توضیحاتی راجع‌به ترجمه کتاب

Git Essentials: Developer's Guide to Git

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

📚 اگه میخوای فایل PDF کتاب رو داشته باشی خودت بخونی میتونی از اینجا داشته باشیش.

تقریبن ۲۰ یا ۳۰ درصد اول کتاب خیلی راجع‌به مقدمه و مباحث پایه ای داره میپردازه که فصل اول به اسم Introduction to Git هستش و در فصل دوم که Source Code Management - SCM هستش من توی این پست میخوام که این دوتا فصل رو با هم منتشر کنم.

1. Introduction to Git:

کتاب «Git Essentials: Developer's Guide to Git» برای همه نوشته شده؛ از مبتدی‌ها تا حرفه‌ای‌های مهندسی نرم‌افزار، و هدفش اینه که شما رو با رایج‌ترین سیستم کنترل نسخه دنیا آشنا کنه. امروزه گیت (Git) تقریباً مترادف با سیستم‌های کنترل نسخه شده و یکی از ابزارهای پایه‌ایه که انتظار می‌ره هر توسعه‌دهنده‌ای اونو بلد باشه تا بتونه توی توسعه نرم‌افزار به خوبی کار کنه.

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

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

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

بعد از خوندن این کتاب چی یاد می‌گیرید؟

• آشنایی با سیستم‌های کنترل نسخه.

• نصب و راه‌اندازی گیت روی کامپیوتر خودتون.

• آشنایی با مفاهیم مرتبط با گیت.

• یادگیری دستورات پایه و پیشرفته گیت.

• توانایی همکاری روی یه مخزن گیت با شاخه‌ها، مخازن راه دور و مدل‌های مختلف شاخه‌بندی.

• توانایی سازماندهی بهتر کارتون با گیت.

• یادگیری راه‌های جلوگیری از اشتباهات و مشکلات رایج.

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

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

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

2.SourceCodeManagement-SCM:

مدیریت کد منبع (Source Code Management) چیه؟

یه سؤال خوب برای شروع اینه که: «مدیریت کد منبع چیه؟»

مدیریت کد منبع در واقع فرآیند پیگیری و دنبال کردن تغییرات توی کدهای یه نرم‌افزار رو می‌گن. این نکته هم مهمه که بدونید «مدیریت کد منبع» و «کنترل نسخه» در اصل به یه چیز اشاره دارن. توی زمینه توسعه نرم‌افزار، با اصطلاحاتی مثل “SCM”، “VCS”، “Source Control”، “Version Control”، “Revision Control” و غیره به‌صورت متناوب برخورد می‌کنید که همشون به این مفهوم اشاره دارن.

خود «کنترل نسخه» می‌تونه معنی گسترده‌تری داشته باشه - یعنی کنترل تغییرات یا نسخه‌های هر چیزی. یه کاربرد جالب از سیستم‌های کنترل نسخه اینه که تغییرات توی قوانین و مقررات یک کشور رو دنبال کنیم.

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

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

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

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

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

دقیقاً این جور سناریوها بود که منجر به ایجاد اولین سیستم مدیریت کد منبع در سال ۱۹۷۲ شد.

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

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

حالا یه سناریوی محتمل‌تر - چند نفر همزمان تغییراتشون رو روی همون فایل‌هایی که بقیه توسعه‌دهنده‌ها دارن روش کار می‌کنن، اعمال کنن.

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

مشکلات اینجا چی بودن؟

• یه توسعه‌دهنده داشت روی همون فایلی کار می‌کرد که یه نفر دیگه هم روش کار می‌کرد، بدون اینکه بدونه.

• هیچ مکانیزمی وجود نداشت که جلوی جایگزینی تغییراتی که هم‌زمان انجام می‌شدن رو بگیره.

این مشکلات باعث شد تا اولین سیستم مدیریت کد منبع به نام SCCS (سیستم کنترل کد منبع) به وجود بیاد. این ابزار اختصاصی رو مارک روکایند توی IBM در سال ۱۹۷۲ ایجاد کرد و پایه‌های سیستم‌های کنترل نسخه مدرن‌تر رو بنا نهاد.

2. What is Git ?

گیت چیست؟

در طول زمان، سیستم‌های زیادی برای حل این مشکل طراحی شدند. یکی از معروف‌ترین این سیستم‌ها “گیت” (Git) است که توسط تعداد زیادی از توسعه‌دهندگان در سراسر جهان استفاده می‌شود.

تاریخچه مختصر گیت:

گیت در سال ۲۰۰۵ توسط “لینوس توروالدز” ایجاد شد. هدف از ساخت گیت، جایگزینی سیستم کنترل نسخه‌ای بود که در آن زمان برای مدیریت کدهای هسته لینوکس استفاده می‌شد. این سیستم اوپن سورس نبود و برای جامعه‌ای که روی هسته کار می‌کردند، مشکلاتی ایجاد می‌کرد. علاوه بر این، آن ابزار دیگر رایگان هم نبود.

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

گیت چطوری کار میکنه؟

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

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

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

• امکان کار بدون دسترسی به شبکه وجود دارد، بدون اینکه امکان تقسیم آن کار به واحدهای جداگانه و معنادار از بین برود.

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

گیت این کار را با ایجاد دو منطقه انجام داده است - محلی و راه دور. منطقه محلی نیز دارای سه منطقه است: دایرکتوری کاری، ناحیه آماده‌سازی (Staging Area)، و مخزن محلی.

working directory و staging area and و local repository

یک مخزن در واقع دایرکتوری‌ای است که گیت آن را زیر نظر دارد و تغییرات داخل آن را پیگیری می‌کند.

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

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

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

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

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

در این سناریو، فایل ۱ هیچ‌وقت تغییر نکرده است. وضعیت آن در طول سه نسخه ثابت مانده است. با این حال، فایل ۲ چندین بار تغییر کرده و فایل ۳ یک بار بعد از نسخه ۱ تغییر کرده است.

هر یک از این فایل‌ها اکنون تاریخچه‌ای مخصوص به خود دارند، و این تاریخچه از نسخه‌های مختلف پروژه عبور می‌کند.

هر یک از این عکس‌های فوری (snapshots) یا وضعیت‌ها روی چیزی شبیه به یک “نوار زمانی” قابل دسترسی خواهند بود. می‌توانید به راحتی بین این نسخه‌ها به عقب و جلو بروید. این دقیقا مثل این است که اگر بخواهید یک قدم به عقب بردارید، بتوانید زمان را به یک عکس فوری قبلی برگردانید.

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

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

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

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

محبوبیت گیت

تا سال ۲۰۱۹، گیت حدود ۷۰٪ از علاقه‌مندی‌های جستجو برای ۵ سیستم کنترل نسخه محبوب رو به خودش اختصاص داده. این به این معناست که منابع زیادی برای کمک به یادگیری و استفاده از گیت، به‌علاوه کمک‌های آنلاین از کاربران دیگه، در دسترس داریم.

در واقع، در مقایسه با سیستم‌های کنترل نسخه مثل Mercurial و Subversion، گیت در سایت پرسش و پاسخ مشهور StackOverflow خیلی محبوب‌تره: ۱۲۵ هزار سوال درباره گیت در مقابل ۲۳ هزار سوال برای Subversion و ۸ هزار سوال برای Mercurial.

یک تحلیل از محبوبیت سیستم‌های کنترل نسخه که توسط RhodeCode در سال ۲۰۱۶ منتشر شد، نشان‌دهنده جابجایی از Subversion به گیت در عصر امروز است.

علاوه بر این، تا اوت ۲۰۱۹، گیت همچنین ۷۰٪ از مخازن میزبان رو برای استفاده‌های شخصی و عمومی به خودش اختصاص داده.

در نهایت، پلتفرم مشهور GitHub، که برای نگهداری مخازن عمومی و خصوصی گیت استفاده می‌شه، در اواخر سال ۲۰۱۸ به تعداد ۱۰۰ میلیون مخزن رسید.

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