3# آموزش سیستم مدیریت کد Git
اندازه‌ی قلم متن
تخمین مدت زمان مطالعه‌ی مطلب: سه دقیقه

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

(Working Tree (Directory: پوشه‏‌ی روتی است که فایل‏های پروژه در آن نگه‏داری می‏‌شود. این پوشه باید حاوی پوشه‌ای به نام git. باشد که محتویات این پوشه، در اصل Repository ما را تشکیل می‏دهند.

اشیا در Git:

برای درک بهتر عملکرد سیستم مدیریت کد Git بهتر است نگاهی به اجزای تشکیل دهنده آن داشته باشیم. به طور کلی Git دارای 4 نوع object است، که هر کدام وظیفه خاصی را به عهده دارند:

1)Tree: شیئ Tree دقیقا مانند دایرکتوری‏‌ها در یک سیستم مدیریت فایل است. در واقع tree‌ها ساختاری درختی را ایجاد می‏‌کنند تا وضیعت فایل‏ها و پوشه‌ها را در Repository حفظ نمایند. هر tree توسط یک کد منحصر به فرد SHA-1 نام گذاری می‌شود.

2)(BLOB(Binary large object: اگر با سیستم‏های مدیریت داده نظیر SQL Server کار کرده باشید قطعا با BLOB آشنایی دارید. BLOB‌ها در واقع چیزی نیستند جز یک مجموعه از بایت‏‏ها که می‏توانند حاوی هر چیزی باشند (نظیر عکس، فایل متنی،  فایلهای اجرایی و...) در Git فایل‏ها به صورت BLOB و به شکل کامل ذخیره می‏‌شوند. همچنین مقدار هش شده محتویات فایل‏ها با استفاده از SHA-1 در خود فایل ذخیره می‏‌شود. به این ترتیب در صورت تغییر در فایل، مقدار هش جدید با مقدار موجود در فایل فرق کرده و Git متوجه می‏‌شود که فایل دچار تغییر شده است. نکته قابل توجه این است که بر خلاف بسیاری از سیستم‏های مدیریت کد، در هر بار تغییر فایل، Git تنها تغییرات را ذخیره نمی‏‌کند بلکه از کل محتوا یک snapshot می‏‌گیرد. شاید به نظر بسیاری تهیه این ‏snapshotهای فراوان باعث زیاد شدن حجم Repository شود، اما Git هوشمندانه تنها فایل‏‌هایی را مجددا ذخیره می‌نماید که مقدار آن‏ها تغییر کرده است. در غیر این صورت یک نشانگر به فایل موجود در snapshot جدید ایجاد می‏کند.

3)Commit: این شئ، یک  snapshot از وضعیت فعلی Working Tree است. در واقع با هر با دستور commit این object ایجاد شده و حداقل حاوی اطلاعات زیر است:

مقدار هش درختی که به آن اشاره می‏کند

نام ثبت کننده دستور commit

توضیحی درباره علت ایجاد commit

خود commit نیز توسط یک کد منحصر به فرد SHA-1 شناخته می‏‌شود.

4)Tag: چون کار کردن با کد‏های هش commit ممکن مشکل باشد، می‌توان از تگ‏ها به عنوان نامی برای commit استفاده نمود. خود تگ می‏‌تواند حاوی توضیحاتی باشد.

آشنایی با (Stage(Index:

هر فایل قبل از آنکه بخواهد در Repository توسط دستور commit ذخیره شود باید ابتدا به Stage آورده شود. در این حالت Git تغیرات فایل را دنبال کرده و سپس می‏‌توان توسط دستور commit فایل را در Repository وارد کرد. بنابراین ذخیره یک فایل در Git دارای سه مرحله است:

Modified : یعنی فایل تغییر کرده اما به stage اضافه نشده است

Staged: فایل تغییر کرده به stage اضافه شده است.

Commited: فایل در Repository ذخیره شده است.

head:

اشاره‏‌گری است که به آخرین شئ commit اشاره می‏‌کند. هر Repository می‏تواند یک head برای هر شاخه‏‏‌ی مختلف داشته باشد؛ اما در هر لحظه تنها یک head به عنوان head جاری شناخته می‏‌شود که معمولا آن را با حروف بزرگ یعنی HEAD مشخص می‏‌کنند.

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

  • #
    ‫۱۲ سال و ۲ ماه قبل، سه‌شنبه ۱۷ مرداد ۱۳۹۱، ساعت ۰۱:۳۲

    من در مورد ترتیب modified و stage شک دارم .
    وقتی یک فایل به پوشه پروژه اضافه میشه برای اینکه تغییراتش توسط Git دنبال و ثبت بشه باید وارد  stage بشه یا به عبارتی Add بشه و در اولین commit بعد از اون به عنوان staged ثبت میشه . از این به بعد تغییرات در این فایل دنبال و در commit‌های بعدی به عنوان modified نشون داده میشه . درسته ؟ یا اشتباه متوجه شدم ؟
    • #
      ‫۱۲ سال و ۲ ماه قبل، سه‌شنبه ۱۷ مرداد ۱۳۹۱، ساعت ۰۲:۲۴
      خیر به این صورت نیست تصور کنید شما پنج فایل  درون working directory خود دارید همچنین دو  فایل جدید نیز اضافه کردید تا زمانی که آن‌ها را با استفاده از دستور add به stage نیاورید git اقدامی برای ساخت سابقه برای آن فایل‌ها نمی‌کند به عنوان مثال سه فایل از پنج فایلی که قبلا وجود داشته تغییر کرده باشد و از این سه فایل تغییر کرده تنها دو تا و یکی از فایل‌های جدید به stage اضافه شده شده باشند و دستور commit اجرا شود تنها همان دو فایل تغییر کرده و فایل جدید موجود در stage در repository ذخیره می‌شوند
      اما در مورد سوال شما می‌تونید فعلا به این صورت تصور کنید که بعد از commit فایل از روی stage حذف میشه (البته دستورات git در این زمینه متفاوت عمل می‌کنند و لزوما اینگونه نیست) بنابراین فایلی که قبلا commit شده و الان تغییر کرده و روی stage نیست وضعیت modified دارد
  • #
    ‫۱۲ سال و ۲ ماه قبل، چهارشنبه ۱۸ مرداد ۱۳۹۱، ساعت ۰۴:۵۲
    بیصبرانه منتظر قسمت‌های بعدی اون هستم . میخوام هر چه سریعتر به قسمت GitExtension و Git Source Control Provider برسیم . کلی سوال واسم ایجاد شده .