فایل gitignore : برای پروژه های گیت از فایلی به نام .gitignore استفاده می شود که آدرس های داخل این فایل اصطلاحا Untrack می شوند و گیت از دنبال کردن و مدیریت نسخه های آن ها صرف نظر می کند و حتی آن ها را پوش نمی کند. دلیل استفاده از این مورد برای این می باشد که گاهی اوقات فایل های ناخواسته تولید می شوند مثلا فایل های مربوط به IDE یا برای جلو گیری از بالا رفتن حجم گیت استاده می شوند که معروف ترین آن جلو گیری از آپلود شدن پوشه node_modules می باشد در ادامه چند تا از پوشه ها یا فایل هایی که در gitignore قرار می گیرند را ذکر می کنیم
- فایل های مربوط به وابستگی ها و پکیج های پروژه مانند پوشه ی node_modules یا vendor
- کد های کامپایل شده مانند فایل های .class و .pyc و...
- فایل های ایجاد شده هنگام اجرای برنامه مانند .log و .lock و .tmp و...
- فایل های مخفی شده سیستم مانند DS_Store یا Thumb.db
- پیکربندی IDE مانند پوشه ی .idea
در حال حاضر سایت هایی هستن که برای جنریت کردن gitignore به ما کمک می کنند که یک نمونه از آن سایت toptal می باشد
کامیت ( commit ) : فضای سیستم‌های کنترل نسخه می‌توان معادلی همچون «ذخیره کردن تغییرات» برایش در نظر گرفت که با کمک آن برای هر تغییر یک تگ مشخص می کنیم که بتوانیم آن ها را راحت تر مدیریت کنیم در صورتی که از ترمینال برای کامیت کردن استفاده کنیم باید از دستورات زیر پیروی کنیم
// making all files available for commit
// با کمک این دستور همه فایل هایی که تغییر دادیم را ادد می کنیم که در ادامه برای روی آن مسیج کامیت را قرار دهیم
git add .
// commit your changes
// با این دستور برای آن فایل هایی که ادد کردیم یه کامنت می نویسیم که بعدها کامیت معنا داری داشته باشیم که بتوان آن ها را راحت تر مدیریت کرد
git commit -m "commit message"
برای مثال کامیت های ثبت شده ما در این لینک با عنواین مختلف قابل مشاهده می باشد و هر کامیت شامل یک کد یکتا، عنوان، کامیت کنند، زمان و تغییرات هر کامیت می باشد
شاخه یا Branch: در زمان ساخت پروژه یک شاخه با نام Main یا Master ساخته می شود که شاخه اصلی به حساب می آید و از روی آن شاخه نسخه داده می شود برای این که بتوان راحت تر نرم افزار را توسعه داد و درصورت تایید توسعه آن را به شاخه اصلی اضافه نمود ( درخواست ادغام که جلو تر توضیح داده شده است ) و نسخه داد برای دیدن برنج ها می توانید بر روی این لینک کلیک کنید و برای دیدن گراف برنج ها زمان تشکیل و ادغام و... بر روی این لینک کلیک نمایید
محافظت کردن از برنچ ( Protect Branch ) : پروتکت کردن یا محافظت از برنچ به معنای محدود کردن دسترسی ها به آن برنچ ( شاخه ) می باشد که این کار عمدتا به این دلیل انجام می شود که موردی اشتباها به صورت مستیم بر روی برنچی نرود یا موردی از آن پاک نشود برای این که بتوات تغیرراتی را بر روی پرنچ محدود شده اعمال کرد باید به آن برنچ Pull Request زد که در این مرحله می توان کد را بررسی دوباره کرد و مشکلات و حتی کانفیکت ها احتمالی را درست نمود، در ادامه تنظیمات مربوط به پروتکت کردن برنچ Main آمده است ->
درخواست ادغام ( Pull Request ) : هنگامی که شما یک pull request باز میکنید، در حقیقت شما تغییرات خود را پیشنهاد میکنید و درخواست میکنید تا کسی آن تغییرات را بررسی کند و در اصطلاح آن تغییرات را pull کند و آنها را با branch خود ادغام (merge) کند.
این قسمت همان‌طور که در عکس هم آمده است دارای قسمت های مختلفی می باشد که چند تا از مهم های آن ها را بیان می کنیم:
- در ابتدا و بالای Pr اسم Pr موجود می باشد که با توجه به سیاست های تایید شده در تیم باید نام گذاری شود سپس زیر آن برنچ هایی که از آن مرج قرار است صورت بگیرد مشخص شده است ( برای مثال در تصور بالا update-readme با Main مرج شده است )
- قسمت Reviewers یا بررسی کنندگان: در این قسمت پروژه را به کسی که داخل تیم می باشد Assign می کنیم تا کد و تغییرات شما را بررسی کنید و آن را تایید یا رد کند
- قسمت Assignees یا مامورین: این قسمت شامل افرادی از تیم می باشد که همراه شما برروی این تغییرات کار کرده اند و نیاز است که از تغییرات و نتایج Pr خبر داشته باشند
- قسمت Conversation یا مکالمات : که در این قسمت بررسی کنندگان می توانند نکات خود را بیان کنند و یا عنواین تغییرات نمایش داده می شود مانند مشکل در کد
- قسمت Commits : این قسمت کامیت های انجام شده در این Pr را نمایش می دهد
- قسمت Files changed : در این قسمت تمام تغییرات انجام شده در این Pr قابل مشاهده می باشد
در انتها در صورتی که بررسی کنندگان Pr را تایید کنند و کانفیکتی وجود نداشته باشد شما می توانید آن را مرج کنید و در صورت انجام درست آن وضعیت Pr به Merged ( مانند تصویر) تغییر خواهد کرد
برای مشاهده بقیه درخواست های به لینک روبه رو مراجعه کنید Pull Requests
تداخل یا conflict: زمانی اتفاق می افتد که به صورت همزمان یک تکه کد به صورت مجزا تغییر داده شود و باید این تداخل حل شود که مطمین شد کدام کد درست می باشد برای حل این مورد بهتر است برنج به صورت مداوم آپدیت باشد و از کار برروی برنج های خیلی قدیمی خود داری کردک تمونه هایی ای تداخل را در لینک های زیر می توانید ببنید.
- پرسش اول: پوشه .git یک پوشه پنهان است که هنگامی که یک مخزن git جدید ایجاد میکنید، ساخته می‌شود. این پوشه اطلاعات مربوط به تاریخچه commit، آدرس مخزن راه دور، و غیره را در خود ذخیره می‌کند. این پوشه با دستور git init ساخته می‌شود. برای مثال در ادامه محتویات فایل config داخل پوشه .git آمده است
-
پرسش دوم: این معناست که هر عملیات به صورت یکپارچه انجام می‌شود. یعنی یا کامل انجام می‌شود یا اگر مشکلی پیش بیاید، هیچ تغییری اعمال نمی‌شود پس حالت وسطی برای آن وجود ندارد
-
پرسش سوم:
- دستور fetch تغییرات را دریافت می‌کند اما آنها را اعمال نمی‌کند
- دستور pull تغییرات را دریافت می‌کند اما آنها را اعمال می‌کند
- دستور merge دو شاخه ( برنچ ) را با یکدیگر ادغام می‌کند.
- دستور rebase مانند درستور merge می باشد با این تفاوت که Rebase کردن بر خلاف merge کردن، تاریخچه را مسطح‌سازی می‌کند؛ زیرا این ابزار کار تمکیل شده را از یک شاخه به یک شاخه دیگر منتقل می‌نماید. در این روند، تاریخچه مذکور ناخواسته از بین می‌رود.
لینک توضیحات درباره تفاوت merge و rebase لینک
- پرسش چهارم:
- دستور reset تغییرات را به حالت قبل برمی‌گرداند و تاریخچه commit را تغییر می‌دهد.
- دستور revert به یک commit انتخاب شده برمی گردد ولی تاریخچه commit را حفظ می‌کند.
- دستور restore فایل‌ها را به حالت قبل برمی‌گرداند.
-
پرسش پنجم: Stage یک مرحله در git است که در آن تغییراتی که قرار است commit شوند، آماده می‌شوند. دستور stash تغییرات را در یک محل موقت ذخیره می‌کند تا بتوانید بدون اعمال آنها به کار خود ادامه دهید.
-
پرسش ششم:Snapshot در git به معنی یک تصویر از وضعیت فعلی فایل‌ها در یک زمان خاص است. هر زمان که یک commit ایجاد میکنید، git یک snapshot از وضعیت فعلی فایل‌ها می‌گیرد و آن را ذخیره می‌کند
© حسام اثنی‌عشری، امیررضا قاسمی‌ویسی | تیر-1402