استفاده از گیت برای وردپرس و بکارگیری گیت هاب در پروژه های وردپرس
فرقی ندارد که درگیر یک پروژه کوچک کدنویسی در وردپرس هستید یا اینکه در یک پروژه بزرگ وردپرس مشارکت دارید، در هر صورت شما نیاز دارید که به تاریخچه کارهایی که در حین انجام پروژه انجام داده اید، دسترسی داشته باشید تا هرگاه که بخواهید آن ها را مورد بازبینی یا استفاده مجدد قرار دهید. برای همین هر برنامه نویس وردپرس نیز باید از گیت برای وردپرس استفاده نماید در غیر این صورت در انبوهی از کدهای بی سر و ته غرق خواهد شد و زمان ارزشمند بسیار زیادی را از دست خواهد داد.
مقدمه: ضرورت استفاده از سیستم های کنترل ورژن
همه توسعه دهندگان و کدنویسان، هر روزه حجم قابل توجچهی از کد را می نویسند و یا مورد ویرایش قرار می دهند. یک نرم افزار که هر روز در حال توسعه می باشد و روز به روز بزرگتر می گردد، به مرور زمان شامل حجم بالایی از کد های تولید شده بوده و از طرف دیگر ممکن است افراد مختلفی نیز در آن مشارکت و همکاری نمایند.
یکی از مسائل مهم در توسعه نرم افزار، داشتن سیستمی برای ثبت اطلاعات و تاریخچه توسعه نرم افزار می باشد، چرا که با بیشتر شدن حجم تغییرات در آن و همین طور گذشت زمان، تغییرات مجدد در آن بدون داشتن یک سیستم کاملا منظم، تقریبا غیر قابل انجام است. این امر زمانی بیشتر احساس می شود که ابعاد پروژه بزرگتر، زمان ادامه پروژه بیشتر و تعداد افرادی که در حال همکاری در پروژه هستند متغیر می گردد.
سال هاست که برای رفع این مشکل، از سیستم های کنترل ورژن یا همان Version Control System که به VCS نیز معروف می باشند، استفاده می گردد. پروژه های وردپرس هم از این امر مستثنی نبوده و در بیشتر بخش های وردپرس اعم از توسعه هسته آن و همین طور پروژه های طراحی قالب وردپرس و نیز پروژه های پلاگین نویسی وردپرس، بصورت گسترده از سیستم های کنترل ورژن استفاده می گردد.
یکی از رایج ترین سیستم های کنترل ورژن در دنیا، گیت می باشد که توسط خالق لینوکس، لینوس بندیکت توروالدز (Linus Benedict Torvalds) پایه گذاری شده است و بسیاری از پروژه ها و شرکت های دنیا از این سیستم برای کنترل کردن ورژن سیستم های خود استفاده می کنند.
فرقی ندارد که شما یک برنامه نویس حرفه ای در وردپرس باشید و یا در یک پروژه خیلی کوچک مشغول سفارشی سازی یا همان customize کردن یک قالب وردپرس یا پلاگین وردپرس باشید، به هرحال شما می باید به نوعی کارهای خود را track نمایید تا در صورتی که نیاز به آن ها داشته باشید، بتوانید دوباره به آن ها رجوع کرده و یا تغییرات را به حالت اول بازگردانید. به همین منظور باید از گیت برای وردپرس و پروژه های خود استفاده نمایید.
چه کسانی می توانند بخش های “گیت برای وردپرس” را مطالعه نمایند؟
ساختار گیت و همین طور استفاده از گیت هاب برای به اشتراک گذاری کدها با استفاده از این سیستم، برای هر توسعه دهنده یا کدنویس به بک صورت است. فرقی ندارد که شما در جاوا کد می زنید و یا می خواهید یک ماژول جوملا بسازید. در هر صورت اصول گیت برای همه به یک شکل است.
در واقع هدف از آموزش های این فصل ها، لیست کردن بخشی از امکانات گیت و همین طور گیت هاب می باشد که شما به صورت روزمره با آن ها سر و کار خواهید داشت. فقط برای درک بیشتر کاربرد آن در پروژه های وردپرس، مثال ها در قالب یک پروژه وردپرس ارائه شده است.
توجه داشته باشید که امکانات گیت مسلما بسیار گسترده تر از چیزی است که در این فصل ها آمده است و در واقع هدف از این فصل ها، داشتن مرجعی برای رجوع فوری به آن در صورت نیاز می باشد. این نیازی بود که خود بارها حس کرده ام. بارها اتفاق افتاده که بخشی از دستور را فراموش کرده ام و مجبور شده ام تا دوباره سرچ کنم تا به دستور مورد نظر برسم. برای همین تصمیم گرفتم که لیست دستورات کاربردی و پر استفاده را در این فصل ها قرار بدهم تا وقتی نیاز دارم که از گیت برای وردپرس استفاده نمایم، به سرعت به آن دسترسی داشته باشم.
اگر به دنبال آموزش کامل گیت و همین طور گیت هاب هستید، در زیر همین مطلب لینک هایی ارائه شده است که برای آموزش بیشتر می توانید به آن ها مراجعه کنید.
آموزش های گیت برای وردپرس شامل چه بخش هایی می باشد؟
با توجه به نکات گفته شده در بخش قبل، این آموزش ها شامل خلاصه ای از مفاهیم گیت و همین طور گیت هاب می باشد که در بسیاری از آن ها از عکس استفاده شده است تا به نوعی مفاهیم گیت را یادآوری نماید.
بسیاری از دستورات کاربردی در این آموزش ها لیست شده است که شما می توانید بصورت چک لیست از آن ها استفاده نمایید. در حال حاضر و با رشد فزاینده IDE ها، شما دیگر نیازی ندارید تا در خیلی از موارد از دستورات خط فرمان برای آن ها استفاده نمایید. اکثر IDE ها امکانات کاملی برای کلیه امور موجود در گیت ارائه می دهند که شما می توانید از این امکانات به جای دستورات استفاده نمایید.
استفاده از دستورات گیت برای وردپرس در PhpStorm
در بسیاری از بخش های آموزش گیت برای وردپرس، علاوه بر اشاره به دستورات گیت، از روش های جایگزین برای اعمال این دستورات در PhpStorm استفاده شده است. در واقع به جای تایپ کردن دستورات گیت در خط فرمان، می توانید به راحتی از امکانات این IDE قدرتمند استفاده کرده و اعمال را به سادگی انجام دهید. البته هنوز به شخصه در بسیاری از جاها استفاده از خط فرمان را به استفاده از آن در IDE ترجیح می دهم، البته دلیل خاصی ندارد و تنها دلیل این هست که در خط فرمان در بعضی موارد احساس راحتی بیشتری دارم
راهنما برای مطالعه بیشتر:
شما می توانید از لینک های زیر برای مطالعه بیشتر استفاده نمایید:
سلام.
توضیحی که با آقای علیرضا دادین، خیلی عالی، کاربردی و دلسوزانه بود.
من هم استفاده کردم. مرسی
سلام.وقت بخیر.ایا امکانش سایت وردپرسی که در لوکال هاست است روی گیت یا گیت هاب اپلود شود.تشکر
سلام به شما دوست عزیز
بله، قطعا، و البته فرآیندهایی هم، برای automation کردن این فرآیند وجود دارد تا بعد از مثلا push کردن روی گیت هاب، مستقیم تغییرات به سایت آنلاین یا همان محیط production انتقال یابد
سلام
ما یک تیم ۳ نفره برنامه نویس هستیم که روی یک سایت وردپرسی با حجمی تقریبا ۷ گیگ (پوشه ی آپلود پر از عکس است) کار میکنیم. اخیرا با مشکل کانفلیکت مواجه شدیم و میخوایم از گیت استفاده کنیم ولی سوالاتی برای بنده پشی آمده است.
۱- فرض کنید کل پروژه روی گیت لب فرستاده شده. آیا میتوان از طریق بروزر خروجی کار را بررسی کنیم؟ با توجه به اینکه حجم پروژه، تعداد پلاگین ها و حجم دیتابیس بالاست و نمیتوان کل پروژه را روی سیستم لوکال کلون کرد.
۲- اگر یکی از برنامه نویس ها پلاگینی را دیسیبل کند آیا این تغییر، در روند کار برنامه نویس دیگر خللی ایجاد نمیکند؟
سلام به شما آقا علیرضا عزیز
در موردی که فرمودید، می تونم تجربه های خودم و تیم مون رو برای شما بگم، که در این مدل پروژه ها، با چه سبکی باید جلو رفت:
مورد اول: در صورتی که میخواهید از گیت و مشابه آن برای کنترل ورژن استفاده کنید، بهتره که از VPS یا سرور اختصاصی استفاده کنید. هاست اشتراکی مناسب این کار نیست و عملا ممکن هست دسترسی ssh به سرور داده نشده و شما نتونید کارهای توسعه رو به راحتی بر روی سرور production خود اجرا کنید.
مورد دوم: در پروژه های متوسط تا enterprise ، عموما از یک work flow automation استفاده می شود. به این معنی که عموما سه سرور مجزا در نظر گرفته می شود. یکی سرور تست، یک سرور میانی و سپس سرور اصلی یا همون سرور production شما.( البته بسته به بودجه پروژه میشه این سه تا را به دو تا محدود کرد و سرور میانی رو حذف کرد)
در این سیستم مثلا توسعه دهنده های بک اند، از یک repository مجزا برای خودشون استفاده می کنند و توسعه دهنده فرانت اند هم برای خودشون repository مجزا دارند. به عنوان مثال از فرض کنید از git lab استفاده شود، در اینجا، هر بخش به صورت مجزا و توط خود گیت لب می تواند فرایند Push کردن اتوماتیک به سرور تست شما، انجام بشه و بعد از اینکه در مرحله اول همه چیز تست شد، کد ها بر روی سرور production قرار بگیره.
در صورتی که از تکنولوژی های جدید مثل داکر استفاده بشه، عملا هر developer می تونه برای خودش در کانتینر روی سیستم خودش، کارهاش رو انجام بده و بدون تداخلی، کارها رو روی repository مرتبط با خودش push بکنه. البته از اینجا به بعد ممکن هست انواع conflict هم پیش بیاد که وظیفه team leader این خواهد بود که به این مشکلات رسیدگی کنه و اون ها رو بر طرف بکنه.
در پروژه های وردپرسی، به دلیل اینکه ممکنه خیلی بخش های بک اند و فرانت اند از هم جدا نباشه و همه باهم انجام بشه، بنابراین یه خورده ممکنه فرآیند با پروژه های فعلی که در حال اجراست، فرق داشته باشه.
این ساختار بسته به پروژه شما ممکنه فرق داشته باشه. فرض کنیم قالب شما در حال توسعه هست و همچنین چند تا پلاگین هم به صورت مجزا در حال توسعه هست. کاری که عموما ما انجام میدیم، یک repository مجزا برای توسعه قالب داریم و همین طور برای هر پلاگینی که در حال توسعه هست، یک repository مجزا داریم.
هر توسعه دهنده یک clone از آخرین نسخه branch اصلی (می تونه مثلا master باشه) رو هر روز برمیداره و در انتهای روز کارهای خودش رو در برنچ مرتبط با خودش push می کنه به repository مرتبط با خودش. در زمان های مشخص هم مدیر پروژه (که می تونه همون فرد توسعه دهنده هم باشه) با چک کردن کدها، اون رو با branch اصلی merge می کنه و بعد طبق همون فرآیند automation که گفته شد، push میشه به سرور تست، تا تست ها روی اون انجام بشه (مثل همون فرآیندی که قبل تر خدمت تون عرض کردم)
این فرآیند برای قالب ها و پلاگین ها هرکدام به صورت مجزا اجرا میشه.
مورد سوم (در مورد حجم پروژه): عملا developer های شما، نیازی به خیلی از بخش های پروژه ندارند. مثلا تیم توسعه به پوشه uploads و مثلا عکس های داخل اون، کاری نداره، البته میشه خیلی از بخش ها را در gitignor قرار داد و بخش هایی از یک پروژه را در یک repository قرار داد، اما به نظر من کار درستی نیست و اصلا به کار تیم توسعه دهنده نخواهد اومد.
پس عملا چیزهایی که اشاره کردید، به کار تیم توسعه نخواهد آمد (به نظر من و با توجه به پروژه هایی که تا به حال داشتیم). چیزی که به کار تیم توسعه خواهد اومد، sync بودن ورژن پلاگین ها، قالب وردپرس و همین طور ورژن وردپرس بر روی سیستم توسعه دهنده با سایت اصلی هست (که باعث میشه توسعه دهنده در صورت وجود داشتن conflict بین کارهای خودش و آن ها، بتونه اون ها رو رفع بکنه)
برای sync بودن سورس و ورژن این ها هم، روش های زیادی وجود داره. ساده ترین روش این هست که دقیقا همون پلاگین ها و قالب هایی که روی سایت اصلی هست، بر روی سیستم توسعه دهنده هم نصب باشه و با آمدن آپدیت های جدید، هم سایت اصلی و هم سیستم های لوکال توسعه دهنده، همه با هم آپدیت شوند (همین طور وردپرس سایت که آپدیت شد، برای سیستم های لوکال هم انجام بشه) به دلیل اینکه با آمدن آپدیت، این مورد بر روی همه سیستم ها دیده میشه، بنابراین این کار خیلی ساده خواهد بود.
اما بهتر از این، می تونه استفاده از composer و یا wp-cli برای این کار باشه و از یک فایل json.lock برای نگهداری آخرین ورژن ها، استفاده بشه و هر توسعه دهنده، هر بار خودش رو با این فایل چک می کنه که ببینه آیا با کل سایت اصلی ، sync هست یا خیر.
با این روال همیشه خیال تون راحت هست که اگه conflict ای وجود داشته باشه، از همون ابتدا بر روی سیستم توسعه دهنده دیده میشه. ضمن اینکه همه چیز از روی سایت اصلی، mirror میشه بر روی سیستم توسعه دهنده ها، بنابراین اگه نیاز هست که یک پلاگین disable بشه روی سایت اصلی، توسعه دهنده های دیگر هم این را خواهند دید. اگر توسعه دهنده ای برای خودش به صورت لوکال می خواهد پلاگینی رو disable کنه، این کار رو فقط می تونه روی سیستم خودش انجام بده (وگرنه اصلا مفهومی نداره که روی سایت اصلی یک پلاگین فعال باشه اما توسعه دهنده کدهای خودش رو بدون تست با پلاگین (یا پلاگین های مورد نظر) به روی repo خودش push بکنه)
این البته تجربه بنده از چند تا پروژه بوده که انجام دادیم. هرکس می تونه این روال رو بسته به پروژه خودش، تغییر بده. فکر می کنم می تونید سناریو رو دقیق تر تشریح کنید و در WordPress stackchange (از زیر مجموعه های stackoverflow) مطرح کنید تا نظر دیگر متخصصان در این زمینه رو، بدونید.
امیدوارم این تجربه ها مورد استفاده شما قرار بگیره
برای شما آرزوی بهترین ها رو دارم