گزارش آزمایش اول

دستور کار: https://github.com/ssc-public/Software-Engineering-Lab/blob/main/courseworks/experiments/git.md

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

نام تیم را قیف! گذاشتیم که حرف اول نام خانوادگی اعضای تیم می‌باشد.

سپس مشغول ساخت مخزن و پروژه شدیم. پس از آن تمام لیست کارها را با توجه به مستندات در آورده و در کانبان بورد خود وارد کردیم.

در ادامه مشغول پیاده‌سازی شدیم و وبسایت نهایی را در زیر مشاهده می‌نمایید:

https://abolfazlghalandary.github.io/Ghif-Team-SE-Lab-1/

پاسخ به سوالات

سوال 1

این پوشه یکی از پوشه های اساسی در گیت می باشد که اهمیت و کاربرد زیادی برای ما دارد. در واقع در این پوشه تمامی اطلاعاتی که گیت نیاز دارد تا بداند چه تغییراتی در کد پروژه ایجاد شده است نگه‌داری می‌شود. در این پوشه فایل‌ها و پوشه‌های مختلفی وجود دارد که از جمله فایل های مهم آن می توان به index, head description , fetch_head اشاره کرد. نمی خواهیم به توضیح این فایل ها بپردازیم اما برای نمونه کارکرد فایل head را بیان می کنیم که هنگامی که ما به یک برنچ checkout انجام می دهیم، این فایل تغییر کرده و اطلاعاتی درون آن نوشته می شود.از جمله پوشه های آن می توان به objects و refs اشاره کرد. در پوشه objects کدهای پروژه همانند فریم های عکس قرار دارند و در فایل config مربوط به این پوشه تنظیمات مخزن نگهداری می شود. در پوشه refs به کامیت های موجود در پروژه اشاره می کنیم. در نهایت برای ساختن پوشه .git کافی است یک مخزن ساخته و این پوشه نیز به همراه مخزن ساخته خواهد شد.

سوال 2

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

سوال 3

-دستور fetch : با زدن این دستور بررسی می شود که آیا مخزن ریموت ما نسبت به لوکال تغییری داشته است و یا نه و در صورت تغییر، تغییرات را بدون merge کردن روی مخزن لوکال ما می آورد.

-دستور pull : این دستور همانند دستور قبلی است اما تفاوت آن این است که هنگامی که می خواهد تغییرات را روی مخزن لوکال بیاورد، آن را merge می کند و سپس آخرین نسخه کد در اختیار ما قرار می گیرد.

-دستور merge : این دستور برای ترکیب کردن دو برنچ دلخواه به کار می رود. معمولا در اکثر پروژه ها بدین صورت است که فیچرها را روی برنچ های غیر از main توسعه می دهند و هنگام اتمام کار، آن را با main ترکیب ی کنند. البته باید توجه داشت که تعارض هایی با سایر تغییرات نداشته باشد و با موفقیت ترکیب شود.

-دستور rebase : این دستور تمام کامیت هایی که روی یک برنچ زده شده است را روی یک کد اولیه دیگر اعمال می کند. یعنی عملا شبیه دستور merge عمل می کند و اینکه تاریخچه گیت را منظم تر می کند.

-دستور cherry-pick : با انتخاب یک کامیت مشخص و خاص، می توان آن را از یک برنچ به برنچی دیگر انتقال داد.

سوال ۴ (قدرت گرفته از perplexity.ai)

دستور	عملکرد اصلی	تأثیر بر تاریخچه
reset	بازگرداندن به یک commit خاص	تغییر تاریخچه
revert	معکوس کردن تغییرات یک commit	حفظ تاریخچه
checkout	جابجایی بین شاخه‌ها یا بررسی فایل‌ها	بدون تغییر تاریخچه
restore	بازیابی فایل‌های حذف شده یا تغییر یافته	بدون تغییر تاریخچه
switch	جابجایی بین شاخه‌ها	بدون تغییر تاریخچه

سوال ۵ (قدرت گرفته از perplexity.ai)

مفهوم Stage (Index) درGit

این دستور به عنوان یک ناحیه موقتی بین دایرکتوری کاری (Working Directory) و مخزن (Repository) عمل می‌کند. این ناحیه به توسعه‌دهندگان اجازه می‌دهد تا تغییرات را قبل از انجام commit آماده کنند. به عبارت دیگر، staging area محلی است که تغییرات را برای commit بعدی جمع‌آوری می‌کند.

ویژگی‌های Stage (Index)

حفظ تغییرات: تغییراتی که در دایرکتوری کاری انجام می‌شوند، ابتدا باید به staging area اضافه شوند تا در commit بعدی لحاظ شوند.

انتخابی بودن: توسعه‌دهندگان می‌توانند تصمیم بگیرند که کدام تغییرات را به staging area اضافه کنند و کدام را کنار بگذارند. این امکان به آن‌ها اجازه می‌دهد تا commitهای منطقی و مرتبط بسازند.

دستور git add: برای افزودن فایل‌ها به staging area از این دستور استفاده می‌شود. به عنوان مثال، با استفاده از git add ، فایل مورد نظر به staging area اضافه می‌شود.

دستور Stash در Git

دستور git stash برای ذخیره موقت تغییرات در دایرکتوری کاری استفاده می‌شود. این دستور به شما اجازه می‌دهد تا تغییرات فعلی خود را ذخیره کنید و دایرکتوری کاری را به حالت آخرین commit برگردانید. این کار بسیار مفید است زمانی که شما نیاز دارید به یک شاخه دیگر بروید یا کار دیگری انجام دهید بدون اینکه تغییرات فعلی شما از بین برود.

ویژگی‌های دستور Stash

ذخیره موقت: تغییرات ذخیره‌شده با git stash در یک لیست قرار می‌گیرند و می‌توانند بعداً بازیابی شوند.

دستور git stash pop: برای بازیابی آخرین stash و حذف آن از لیست استفاده می‌شود.

دستور git stash apply: برای بازیابی آخرین stash بدون حذف آن از لیست استفاده می‌شود.

سوال ۶

مفهوم snapshot و commit

به وضعیت پروژه/پوشه/فایل در یک نقطه از زمان snapshot گفته می‌شود. هر کامیت در واقع یک snapshot از وضعیت کد پس از اعمال تغییرات است و با اعمال کامیت آن snapshot جای کد فعلی را می‌گیرد. هر کامیت غیر از کامیت root نیز یک یا چند کامیت والد دارد (در صورت داشتن چند کامیت والد بعنی کامیت ما از نوع merge commit است) که در پیام آن کامیت تغییرات آن کامیت نسبت به کامیت‌های والد بیان می‌شود.

سوال ۷

تفاوت میان local repository و remote repository در این است که local repository هر فرد روی سیستمش قرار دارد و remote repository بر روی سرور توسعه قرار دارد. هر تغییری که برنامه نویسی در کد اعمال بکند ابتدا در مخزن لوکالش رخ می‌دهد و تنها بعد از این که به مخزن ریموت بفرستد توسط دیگران قابل مشاهده خواهد بود و به کد اصلی خواهد پیوست.