Skip to content

amirarab888/SW-Lab-1

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

48 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

SW-Lab-1

نام و نام خانوادگی نفر اول: Amir Hossein Arabzadeh شماره دانشجویی نفر اول: 98105908

نام و نام خانوادگی نفر دوم: AmirMahdi Kousheshi شماره دانشجویی نفر دوم: 98171053

نام و نام خانوادگی نفر سوم: Ahmadreza Khanari شماره دانشجویی نفر سوم: 99170412

مخزن (Repository)

ساخت و دعوت همه اعضای گروه

  1. image

  2. image

    تنيمات اولیه شامل ایجاد یک مخزن Git و ایجاد یک شاخه‌ی اصلی (main) در GitHub بود. برای این‌کار ابتدا یک مخزن در GitHub ساخته و سپس فایل‌های اولیه‌ی را (شامل gitignore) در آن قرار دادیم.

        git add 
        git commit -m "Initial commit"
        git push
    

گزارش پروژه

در ابتدا چندین موضوع برای انتخاب پروژه‌ی نهایی توسط اعضا مطرح شد و درنهایت پروژه‌ی ToDo List به عنوان پروژه‌ی نهایی انتخاب شد. بعد از انتخاب پروژه، تسک‌های مربوط به انجام این پروژه را شکستیم و در بورد قرار دادیم. ما پروژه را به ۴ قسمت کلی تبدیل کردیم و درنهایت تسک‌های کوچک از آن ساختیم.

ما ۴ قسمت کلی صفحه‌ی ثبت‌نام کاربر، صفحه‌ی ورود کاربر، صفحه‌ی ToDo List و دیپلوی سایت بر روی GitHub را به عنوان کارهای اصلی در نظر گرفتیم و درنهایت به تسک‌های کوچک هرکدام از این کارها را شکوندیم.

  • ایجاد بورد کانبان (Kanban Board)
    1. image
    2. photo_2024-10-18_13-27-58

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

  • پیاده سازی
    1. بعد از ساخت پروژه، ابتدا صفحه ثبت نام را ایجاد کردیم.
    2. photo_2024-10-18_13-49-24
    3. سپس به سراغ صفحه لاگین رفتیم.
    4. photo_2024-10-18_13-51-36
    5. همزمان، بورد کانبان را آپدیت می کنیم.
    6. photo_2024-10-18_13-56-14
    7. در ادامه آپدیتی بر روی صفحه لاگین داشتیم.
    8. photo_2024-10-18_14-08-24
    9. در این مرحله، به کانفلیک میخوریم.
    10. photo_2024-10-18_14-12-38
    11. photo_2024-10-18_14-13-00
    12. photo_2024-10-18_14-13-06
    13. photo_2024-10-18_14-13-10
    14. دقت شود که به صورت همزمان، روی بورد کار شد که عکس از مراحل انجام آن به طور کامل و مستمر گرفته نشد اما در انتها، مرج ریکوئست ها و همچنین کامیت ها در بخش insight قابل مشاهده می باشد.
    15. photo_2024-10-18_14-20-53
    16. photo_2024-10-18_14-22-46
    17. بعد از لاگین، یک صفحه اصلی برای راحت تر کردن دسترسی به سه بخش اصلی سایت ایجاد میکنیم.
    18. photo_2024-10-18_14-15-50
    19. کانفلیکت دوم: این مورد زمانی پیش آمد که قابلیت ادیت بعد از قابلیت ساخت تسک به پروژه اضافه شد.
    20. photo_2024-10-18_14-25-50
    21. photo_2024-10-18_14-26-30
    22. photo_2024-10-18_14-26-56

در ادامه صفحات مربوط به ToDo List هم ساختیم و در شاخه‌های مربوطه قرار دادیم. ما برای زدن featureهای جدید از شاخه‌های با الگوی feature/* ساختیم. همچنین در یکی از باگ‌هایی که داشتیم یک شاخه‌ی hotfix زدیم و آن باگ را رفع کردیم. نمونه‌ای از اسامی شاخه‌ها در عکس زیر آمده است.

  1. image

در ادامه به دیپلوی کردن بر روی GitHub Actions و ساخت صفحه بر روی دامنه‌ی GitHub پرداختیم.

  1. image

  2. image

  3. image

  4. image

  5. image

  6. image

  7. image

  8. image

  9. image

  10. image

  11. image

  12. image

در نهایت آدرس سایت در زیر آمده است:

حال به پاسخ سوالات می‌پرسیم.

سوالات

پوشه‌ی .git چیست؟ چه اطلاعاتی در آن ذخیره می‌شود؟ با چه دستوری ساخته می‌شود؟

این پوشه شامل اطلاعات متادیتا و داده‌های مرتبط با objectهای پروژه است. در واقع، این پوشه مهم‌ترین بخش Git به شمار می‌آید، زیرا تمامی اطلاعاتی که Git برای مدیریت پروژه نیاز دارد، در این پوشه ذخیره می‌شود. اطلاعاتی مانند تاریخچه تغییرات (commit history)، شاخه‌ها (branches)، برچسب‌ها (tags)، و سایر داده‌های ضروری در اینجا قرار دارند. این پوشه با استفاده از دستور git init ساخته می‌شود.

منظور از atomic بودن در atomic commit و atomic pull-request چیست؟

Atomic Commit:

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

Atomic Pull-Request:

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

تفاوت دستورهای fetch، pull، merge، rebase و cherry-pick

fetch:

  • این دستور اطلاعات موجود در remote repository را به local repository منتقل می‌کند.
  • هیچ تغییری در working directory ایجاد نمی‌کند؛ فقط تاریخچه commitها و تغییرات در local repository به‌روزرسانی می‌شود.

merge:

  • با استفاده از این دستور، می‌توان یک شاخه را با شاخه دیگری ادغام کرد.
  • تغییرات دو شاخه به کمک یک commit جدید ادغام می‌شوند، که به این commit "merge commit" گفته می‌شود.

pull:

  • این دستور ترکیبی از دو دستور fetch و merge است.
  • ابتدا اطلاعات از remote repository به local repository منتقل می‌شود (fetch) و سپس شاخه فعلی با شاخه‌ای از origin ادغام می‌شود (merge).

rebase:

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

cherry-pick:

  • این دستور به شما امکان می‌دهد یک یا چند commit خاص را از یک شاخه به شاخه دیگری انتقال دهید.
  • برخلاف merge، نیاز نیست تمام تغییرات یک شاخه را در شاخه دیگر ادغام کنید؛ فقط commitهای خاص انتخاب‌شده منتقل می‌شوند.

تفاوت دستورهای reset، revert، restore، switch و checkout

reset:

  • این دستور برای حذف تغییرات ذخیره‌نشده فایل‌ها و بازگشت به حالت قبل استفاده می‌شود.
  • می‌تواند شاخه فعلی را به یک commit خاص بازگرداند، اما این بازگشت در تاریخچه Git ثبت نمی‌شود.
  • بسته به پارامترهایی مانند --soft، --mixed، و --hard، نحوه اثرگذاری آن بر فایل‌ها و staging area متفاوت است.

revert:

  • همانند reset عمل می‌کند اما برعکس آن، تغییرات را در تاریخچه Git ثبت می‌کند.
  • یک commit جدید ایجاد می‌کند که تغییرات یک commit خاص را برعکس (undo) می‌کند، بدون حذف تاریخچه قبلی.

restore:

  • این دستور برای بازگرداندن فایل‌های تغییر داده‌شده به حالت آخرین commit ثبت‌شده استفاده می‌شود.
  • می‌تواند برای لغو تغییرات در working directory یا staging area استفاده شود.

switch:

  • این دستور برای تغییر شاخه (branch) استفاده می‌شود.
  • نسخه جدیدتری نسبت به checkout است که استفاده از آن برای تغییر شاخه ساده‌تر و ایمن‌تر است.
  • فقط برای تغییر شاخه‌ها طراحی شده است و نمی‌تواند commitها را مستقیماً تغییر دهد.

checkout:

  • این دستور برای جابه‌جایی بین شاخه‌ها (branches) یا بازگشت به یک commit خاص استفاده می‌شود.
  • می‌تواند شاخه را به commit خاصی برگرداند و حتی شاخه‌های جدید ایجاد کند.
  • علاوه بر تغییر شاخه، می‌تواند فایل‌ها را به حالت commit خاص برگرداند.

منظور از stage یا index چیست؟ دستور stash چه کاری انجام می‌دهد؟

Stage یا Index:

  • منظور از stage (یا index) فضایی است که تغییرات اعمال‌شده در فایل‌ها را که قرار است در commit بعدی ثبت شوند، ذخیره می‌کند.
  • در واقع، مرحله‌ای بین انجام تغییرات و ثبت آن‌ها در commit است؛ به این معنا که فایل‌ها به مرحله آماده‌سازی (staging) منتقل می‌شوند تا در commit بعدی قرار گیرند.

دستور stash:

  • دستور stash به شما کمک می‌کند تغییرات اعمال‌شده در فایل‌ها را به طور موقت ذخیره کنید تا بتوانید به commit قبلی بازگردید یا کار دیگری انجام دهید.
  • این دستور محتویات فایل‌های stage یا index را در یک پشته (stack) ذخیره می‌کند و سپس فایل‌ها را به حالت commit قبلی بازمی‌گرداند، بدون اینکه این تغییرات را کاملاً از دست بدهید.

مفهوم Snapshot چیست؟ ارتباط آن با Commit چیست؟

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

ارتباط Snapshot با Commit:

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

تفاوت‌های Local Repository و Remote Repository چیست؟

Local Repository:

  • Local repository مخزنی است که در کامپیوتر شخصی شما قرار دارد و تمامی commitها و داده‌های پروژه را به صورت محلی نگهداری می‌کند.
  • فقط شما به این مخزن دسترسی دارید و تمامی تغییرات به صورت محلی در سیستم شما ذخیره می‌شوند.
  • زمانی که شما روی پروژه خود کار می‌کنید و تغییرات را commit می‌کنید، این تغییرات فقط در local repository شما ثبت می‌شوند.

Remote Repository:

  • Remote repository مخزنی است که روی یک سرور ذخیره شده و به دیگران نیز دسترسی می‌دهد.
  • این مخزن به صورت عمومی یا خصوصی می‌تواند در دسترس چندین کاربر باشد و افراد با دسترسی به آن می‌توانند پروژه را روی سیستم‌های شخصی خود دانلود کرده و تغییرات خود را به آن ارسال کنند.
  • مخزن‌های remote معمولاً برای همکاری بین تیم‌ها و نگهداری پشتیبان پروژه‌ها استفاده می‌شوند.

تفاوت کلی:

  • تفاوت اصلی در محل ذخیره‌سازی و دسترسی است: local repository در کامپیوتر شخصی شما ذخیره می‌شود و دسترسی محدود به خود شما دارد، در حالی که remote repository روی سرور ذخیره شده و برای چندین کاربر قابل دسترسی است.
  • به جز این تفاوت، هر دو از لحاظ ساختاری و عملکردی مشابه هستند.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors