آموزش گیت (Git) بهترین ابزار مدیریت کد

مقدمه آموزش گیت

در مطالب قبل با پلت فرم توسعه IntelliJ IDEA آشنا شدیم در این پست به آموزش گیت میپردازیم. داشتن ورژن‌های مختلف فایل‌های php, js, css, html و … برنامه، در پروژه‌های فردی و تک‌نفره نیز امری مطلوب به نظر می‌رسد که فواید و کاربردهای خاص خود را دارد. در پروژه‌های گروهی این امر نه فقط مطلوب بلکه لازم و ضروری است. قبلا از روش subversion استفاده می‌شد که تغییرات نسبت به ورژن قبل را نگه می‌داشت و نیاز به سرور اصلی داشت. اما با معرفی روش گیت در سال 2005 توسط مخترع لینوکس، همه برنامه نویسان و گسترش دهندگان نرم افزار به برتری این روش اذعان کردند و هم اکنون بسیاری از شرکت‌های بزرگ (حتی توئیتر و فیس بوک) نیز پروژه‌های خود را با روش git در سایت github و سایر سایت‌های مشابه نگهداری و گسترش می‌دهند.

در روش گیت نیاز به اتصال دائمی به سرور برای commit) نهایی) کردن نیست و لذا می‌توان در همه حال حتی مسافرت و هواپیما نیز به کار خود ادامه دهید. همچنین در روش git کل نسخ برنامه روی دستگاه شما قابل دسترس است (بدون نیاز به سرور) برخلاف روش ساب‌ورژن.

برنامه های کنترل نسخه (VCS)

کنترل نسخه چیست و چرا باید به اون اهمیت داد؟ کنترل نسخه به معنای دنبال نمودن تغییرات اعمال شده در فایل های پروژه است. وظیفه یک برنامه کنترل نسخه ثبت تغییرات صورت گرفته بر روی فایل های پروژه مثل ویرایش کردن، افزودن و یا پاک نمودن آن هاست؛ به گونه ای که هرگاه بخواهیم بتوانیم به نسخه های مختلف پروژه دسترسی پیدا کنیم.

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

یک برنامه کنترل نسخه یا VCS (مخفف شده‌ی: Version Control System) به شما این امکان را می دهد که فایل های پروژه را به ویرایش های قبلی آن ها بازگردانید، تغییرات اعمال شده هر فایل را بعد از پیشرفت پروژه مشاهده کرده و آن را با وضعیت قبلی اش مقایسه کنید، در صورتی که گروهی روی یک پروژه کار می کنید، ببینید چه کسی در هر مرحله پروژه را ویرایش کرده و اگر در جایی اشتباهی صورت گرفته، پروژه را به حالت قبل از ویرایش بازگردانده و آن را بازیابی کنید، و…

سیستم های کنترل نسخه محلی

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

برای رهایی از این قبیل مشکلات، سال ها پیش برنامه نویسان سیستم های کنترل نسخه ای را ساختند که بر روی یک کامپیوتر نصب می شد و تغییرات همه فایل ها در نسخه های مختلف را در پایگاه داده ساده اش ذخیره می کرد. این مدل برنامه ها، که سیستم های کنترل نسخه محلی یا Local Version Control Systems نامیده می شوند تنها قابل استفاده بر روی یک کامپیوتر مشخص می باشند.

سیستم های کنترل نسخه متمرکز

مشکل هنوز برطرف نشده بود! اگر پروژه ای قرار بود به صورت گروهی انجام شود، سیستمی نیاز بود تا همه ی اعضای گروه بتوانند به صورت مشترک به آن دسترسی داشته باشند و در توسعه و پیشرفت پروژه مشارکت کنند.

برای حل این مشکل سیستم های کنترل نسخه متمرکز یا Centralized Version Control Systems ایجاد شدند. این سیستم ها که Subversion (همان SVN) و Perforce از جمله نمونه های آن هستند، دارای یک سرور هستند که تمام نسخه های پروژه (فایل ها)، و تعداد کامپیوتر هایی که به نسخه های پروژه بر روی سرور دسترسی دارند را شامل می شود. یعنی همه کارهایی که اعضای پروژه انجام می دادند و تغییراتی که  ایجاد می کردند بر روی یک سرور مشخص که همه به آن دسترسی داشتند ذخیره می شد و مشخص بود که چه کسی در چه زمانی چه بخشی از پروژه را تغییر داده است.

با همه ی مزایا و امتیازاتی که این سیستم داشت، هنوز یک مشکل بزرگ روند انجام پروژه را تهدید می کرد.

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

این مدل برای سال ها به عنوان یک استاندارد کنترل نسخه شناخته می شد. (و البته هنوز مورد استفاده قرار می گیرد.)

سیستم های کنترل نسخه توزیع شده

خب، اینجا همان جایی بود که سیستم های کنترل نسخه توزیع شده یا Distributed Version Control Systems وارد ماجرا شدند   Git، Mercurial، Bazaar و Darcs از جمله این سیستم ها به شمار می روند.

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

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

تاریخچه Git

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

در سال ۲۰۰۲، لینوس، برای توسعه هسته لینوکس، از سیستم کنترل نسخه‌ی BitKeeper(مدل DVCS) استفاده کرد که به تمام اعضای حاضر در توسعه پروژه، اجازه می داد به صورت رایگان از سرویس BitKeeper استفاده کنند.

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

این باعث شد تیم توسعه لینوکس و مشخصا خود لینوس توروالدز که خالق لینوکس بود، ابزار مورد نیاز ویژه خودشان برای کنترل نسخه ها را تولید کنند.

از سایر اهدافی که در این سیستم جدید مدنظر بود، می توان به موارد زیر اشاره کرد:

سرعت

طرح ساده

پشتیبانی قوی برای توسعه غیرخطی (هزاران تغییر همزمان توسط افراد حاضر در توسعه پروژه(کاملا توزیع شده بر اساس مدل DVCS)

و اینکه برای پروژه هایی به بزرگی لینوکس پاسخگو باشد.

این سیستم که git نامگذاری شد در همان سال (۲۰۰۵)، تنها ۲ ماه پس از شروع توسعه‌ی آن، به عنوان نرم افزار رسمی کنترل نسخه برای توسعه هسته لینوکس مورد استفاده قرار گرفت.

هدف از تهيه اين سند اين است كه بتوان تمام اطلاعاتي كه براي برنامه ريزي و كنترل فعاليتهاي فرآيند آزمون موردنياز است را در يكجا جمع آوري نمود. در اين سند، رويكردهاي موراستفاده در آزمون سيستم بيان ميشوند و از اين سند بعنوان مرجعي براي مديريت و راهبري فرآيند آزمون سيستم، استفاده ميشود.

مبانی Git

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

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

git به اطلاعات و فایل های یک پروژه، بسیار متفاوت از سایر سیستم های کنترل نسخه نگاه می کند و به شکل دیگری آن‌ها را ذخیره می کند. دانستن این تفاوت‌ها به جلوگیری از گیج شدن در هنگام کار کمک می کند.

ذخیره بصورت یک عکس بجای ذخیره‌ی تغییرات

بزرگترین تفاوت گیت git با سایر سیستم های کنترل نسخه مثل SVN، در نوع نگاه git به داده‌های پروژه (فایل‌‌ها، فولدرها) و نحوه ذخیره آنها است.

بسیاری از سیستم های کنترل نسخه اطلاعات مربوط به هر پروژه را بر اساس تغییرات صورت گرفته در فایل ها ذخیره می کنند. این سیستم ها (مثل SVN، Perforce، Bazaar و…) به اطلاعات یک پروژه اینطور نگاه می کنند که یک مجموعه، فایل‌هایی هستند که در این پروژه وجود دارند، و مجموعه دوم، تغییراتی هستند که در گذر زمان روی فایل های موجود در پروژه (یا همان مجموعه اول) اعمال شده اند.

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

 سایر سیستم ها، تمایل دارند که اطلاعات هر پروژه را بصورت تغییرات اعمال شده بر روی نسخه های اصلی فایل های پروژه، ذخیره کنند. اما git به این شکل اطلاعات پروژه را ذخیره نمی کند. هر بار که شما یک یا چند فایل از پروژه را تغییر داده و آن را در git ذخیره می کنید (اصطلاح commit کردن)، git یک تصویر از نسخه تغییر یافته آن فایل ها تهیه می کند و یک مرجع به آن اختصاص می دهد؛

به عنوان یک مثال ساده، تصور کنید یک می خواهید حرکت یک توپِ در حال حرکت را ثبت کنید. کاری که سیستم هایی مانند SVN انجام می دهند این است که در لحظه اول توپ را در مکان اصلی آن ثبت می کنند و در لحظه های بعدی از حرکت توپ، تنها “جابجایی” و یا “تغییر مکان” توپ را دنبال کرده و ذخیره می کنند. اما git به جای ذخیره تغییر مکان توپ، در هر لحظه یک عکس یا snapshot از حرکت توپ تهیه کرده و ذخیره می کند. به این ترتیب ما در هر لحظه یک توپ داریم که موقعیت مکانی آن تغییر کرده اما وابسته به موقعیت ابتدایی آن نیست! (واقعا مثال ساده‌ای بود  (

نمودار زیر بصورت شماتیک نحوه عملکرد git را نشان می دهد:

در این نمودار، A₁ نشان دهنده تصویر فایل A پس از اولین تغییر است

 برای کارایی بیشتر، اگر فایلی نسبت به حالت قبل تغییر نکرده باشد، git دومرتبه آن را ذخیره نمی کند، بلکه از همان فایل نسخه پیشین استفاده می کند. برای مثال در Version 2، فایل B تغییر نکرده و هرگاه Version 2 پروژه نمایش داده شود، git از فایل B موجود در Version 1 استفاده خواهد کرد.

این تمایز مهم بین git و سایر سیستم های کنترل نسخه (VCS) است؛ چیزی که گیت را به ابزاری قدرتمند برای مدیریت فایل تبدیل کرده که تمام جنبه های کنترل نسخه را پوشش می دهد.

انجام کارها به صورت محلی

همانطور که در نوشته پیشین به آن اشاره شد، با استفاده از git که یک “سیستم مدیریت نسخه توزیع شده” یا “DVCS” است، در بیشتر عملیات ها، شما تنها به فایل های موجود در کامپیوتر خودتان نیاز خواهید داشت و تقریبا همه چیز بصورت محلی انجام می شود. در حالی که در “سیستم های کنترل نسخه متمرکز” یا “CVCS” مانند SVN، اکثر عملیات ها وابسته به کامپیوتر سرور یا مرکزی بوده و این باعث ایجاد سربار یا overhead در شبکه شده و سرعت عملیات را کاهش می دهد.

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

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

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

دسترسی به فایل ها بر اساس مقدار Hash

در ابتدا لازم است توضیحی ابتدایی در مورد Hash داده شود.

Hash رشته ای است که از “توابع درهم‌سازی” یا “Hash functions” حاصل می شود و بسته به نوع الگوریتم تابع درهم‌ساز، تعداد کاراکترهای آن متفاوت است. از توابع درهم‌ساز می توان به MD5 ،SHA-1 ،HAVAL و WHIRLPOOL اشاره کرد.

برای مثال، رشته‌ی “هش” خروجی از دو تابع MD5 و SHA-1 برای عبارت ”kava.ir”، بصورت زیر است:

1 2	31a99cefedd513ec1873db7d9c21c1af            // MD5 Hash f5527fbbd67a0af38eb2ac958c544789b0af110b    // SHA-1 Hash

می توان گفت Hash تولید شده، برای هر رشته‌ یا عبارتِ ورودی به توابع درهم‌ساز، منحصر بفرد است؛

بنابراین اگر بجای وارد نمودن یک عبارت، محتوای یک فایل را به این توابع وارد کرده و مقدار Hash خروجی تابع را ذخیره کنیم، و فایل را ویرایش نموده و دوباره مقدار Hash آن را با همان تابع محاسبه کنیم، این دو مقدار “هش” با یکدیگر متفاوت خواهند بود. از این روش می توان فهمید که آیا در یک فایل تغییری رخ داده است یا خیر.

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

مکانیزم و الگوریتمی که git برای محاسبه Hash فایل‌ها و پوشه‌ها از آن استفاده می کند، SHA-1 نام دارد. خروجی این تابع، یک رشته ۴۰ کاراکتری است که ترکیبی از حروف a-f و اعداد ۹-۰ می باشد (یک رشته‌ی هگزادسیمال یا مبنای ۱۶) که بر اساس محتوای فایل یا ساختار پرونده‌ی پروژه محاسبه می شود.

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

سه حالت اصلی در Git

این بخش مهمترین قسمت از مبحث امروز است که باید در مورد git به یاد بسپارید، اگر می خواهید ادامه‌ی روند آموزش را به راحتی طی کنید، به این بخش توجه کنید.

۳ حالت یا وضعیت اصلی برای فایل های شما در git وجود دارد:

• سپرده شده یا “Committed”
• تغییر یافته یا “Modified”
• به روی صحنه رفته یا “Staged”

Committed به این معنی است که اطلاعات شما به طور ایمن در پایگاه داده‌ی git ذخیره شده است.
Modified به این معنی است که شما فایل را وبرایش کرده و تغییر داده اید اما هنوز Commit نکرده‌اید (در git ذخیره نکرده‌اید) Staged به این معنی است که شما یک فایل تغییر یافته یا Modify شده را برای قرار گیری در Commit بعدی به روی صحنه برده‌اید. (یعنی علامت گذاری نموده اید تا در اولین Commit در git ذخیره شود)

نمودار زیر سه بخش اصلی یک پروژه git را به ما نشان می دهد: پوشه‌ی محیط کار، بخش stage یا صحنه و پوشه‌ی git یا همان repository

پوشه‌ی git یا همان repository که با نام .git در پوشه‌ی محیط کار (پروژه) ایجاد می گردد، جایی است که تمام اطلاعات پس از هر Commit در آن ذخیره می شود. این بخش مهمترین قسمت از git است که تاریخچه تغییرات پروژه را دربر می گیرد و در انتقال پروژه از کامپیوتر محلی به سرور و بلعکس، انتقال می یابد.

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

بخش stage یا صحنه، تنها یک فایل ساده است که در داخل پوشه git قرار گرفته است. این فایل حاوی اطلاعات مربوط به فایل هایی است که باید در Commit بعدی، در پوشه git ذخیره شوند.

روند انجام کار در git به صورت زیر است:

1. شما فایل های موجود در پوشه پروژه را ویرایش می کنید.
2. فایل های تغییر یافته یا افزوده/کاسته شده از پروژه را به stage اضافه می کنید.
3. فایل های به روی stage رفته را Commit کرده و با اینکار یک تصویر از وضعیت پروژه و فایل های روی stage را به صورت دائمی در پوشه git خود، ذخیره می کنید.

پس اگر یک نسخه از یک فایل مشخص در پوشه‌ git است، آن فایل Commit شده نامیده می شود.
اگر یک فایل ویرایش شده و یا به پروژه افزوده یا از آن حذف گردیده، و به stage نیز اضافه شده است، آن فایل staged یا “به روی صحنه رفته” نامیده می شود. و اما اگر آن فایل پس از ویرایش به stage اضافه نشده باشد، در Commit بعدی شرکت داده نشده و Modified یا “ویرایش شده” نامیده می شود.

گرفتن یک Git Repository

برای این کار دو روش وجود دارد:

1. ایجاد یک Repository در دایرکتوری جاری: برای این کار کافی است دستور git init را اجرا کنید.
2. Clone کردن یک remote repository : یک remote repository را با استفاده از دستورgit clone “remote repository address” می توانیم بگیریم به این معنی که پس از گرفتن آن این repository به صورت repository محلی در مسیری که آن را میگیریم ذخیره می شود

اعمال تغییرات به Repository محلی

همانطور که در شکل ذیل مشخص است 4 حالت برای یک فایل وجود دارد:

تمام فایل هایی که بصورت clone گرفته شده است به حالت unmodified می باشد. البته برای فایل هایی که به صورت init، Repository آنها ایجاد شده می توان با استفاده از دستور git add “file name” حالت شان را به unmodified تغییر داد.

اگر فایلهایی که در حالت unmodified هستند ویرایش شوند به حالت modified در می آیند و سپس با استفاده از دستور git add “file name” (در صورت نیاز) به حالت staged در می آیند یعنی آماده commit شدن با استفاده از دستور git commit می باشند.

با دستور git status می توان پی برد فایل ها در کدام یک از این چهار حالت می باشند.

شاخه بندی در Git

شاخه ها (Branch) روشی برای اعمال انجام تغییرات هستند بدون تغییر پروژه اصلی. به عنوان مثال فرض کنید می خواهید که برای یک Bug خاص کد لازم را بنویسید در این حالت بهتر است بجای کار کردن برروی Branch اصلی و پیش فرض با نام Master یک Branch مثلا با نام bug1 ایجاد کرده با استفاده از دستور:

git branch bug1

برای اینکه به این شاخه انتقال یابیم و تغییرات را اعمال کنیم از دستور زیر استفاده می کنیم:

Git checkout bug1

سپس تغییرات را برروی این Branch انجام داده و پس از اطمینان حاصل کردن از اینکه تغییرات به درستی اعمال شده اند این تغییرات را برروی شاخه Master انتقال داد. برای انتقال این تغییرات ابتدا باید با دستور زیر به شاخه Master برگشته:

Git checkout master

سپس با استفاده از دستور زیر ادغام دو شاخه را انجام می دهیم که نتیجه ادغام برروی شاخه ای که برروی آن هستیم (فعلا Master) اعمال می شود:

Git merge bug1

در این مرحله می توانیم با استفاده از دستورات commit و push تغییرات را برروی سرور اعمال کرد.

نکته: در صورت وجود تضاد (conflict) merge با استفاده از دستور git mergetool خطا را رفع نمایید.

دستورات pull و push

برای گرفتن آخرین نسخه فایل ها برروی سرو کافی است از دستور زیر استفاده کنید:

Git pull “remote server address” “branch name”

برای اعمال آخرین تغییراتی که commit کرده اید از دستور زیر استفاده کنید:

Git push “remote server address” “branch name”

آدرس کانال تلگرام سایت بیگ دیتا:

t.me/bigdata_channel

آدرس کانال سروش ما:
https://sapp.ir/bigdata_channel

جهت دیدن سرفصل های دوره های آموزشی بر روی اینجا کلیک کنید.

جهت ثبت نام در دوره های آموزشی بر روی اینجا کلیک کنید.

بازدیدها: 2749