Version Control System ها

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

برای مدیریت Source Code ها و همچنین برای راحت تر شدن مدیریت یک پروژه بهتر است از نرم افزارهایی به نام Version Control ها استفاده میکنیم.

زمانی که یک کار قرار است مرتبا بهبود پیدا کند بهتر است نسخه های قبلی را هم نگه داری کنیم تا شاید در آینده به کارمان بیاید . خود شما بدون اینکه بدونید از این روش استفاده کرده اید احتمالا . مثلا نام گذاری فایل ها به صورت زیر :

  • KalidAzadResumeOct2006.doc
  • KalidAzadResumeMar2007.doc
  • instacalc-logo3.png
  • instacalc-logo4.png
  • logo-old.png

    دلیل استفاده از Save as… هم همین است. ولی این که شما یک فایل اصلی داشته باشید و بقیه فایل ها شما رو گیج نکنه خیلی مهم است. مثلا فرض کنید قصد دارید یه فایل word با پسوند .doc تولید کنید.خوب نسخه اول رو مینویسید و اسمش رو میذارید myresume.doc . حالا اگه تغییرش دادید ممکنه به این صورت این کار رو مدیریت کنید که فایل قبلی رو به myresume_old.doc تغییر نام بدید و فایل جدید با تغییرات رو همون myresume.doc بنامید. حالا اگه یه فایل دیگه تولید کردید چکار میکنید؟

    به نظر میرسه بهتره به هر فایل یه ورژن بدیم. مثلا myresume_v1.doc و myresume_v2.doc و الی آخر.

    خوب پس چرا به نرم افزارهایی به نام Version Control System (VCS) نیاز داریم ؟

    الگوی نام گذاری که در قسمت قبل بحث شد شاید برای یه پروژه کلاسی و یا یه فایل word خوب باشه ولی برای یک پروژه نرم افزاری نه. آیا فکر میکنید که مثلا آخرین نسخه کد ویندوز در پوشه ای به نام windows_eight_lastest_update قرار داره و برنامه نویس های مایکروسافت این پوشه رو ویرایش میکنند ؟؟!! نه این طور نیست.

    در پروژه هایی که به سرعت تغییر میکنند و تعداد زیادی ( بیشتر از صفر نفر ! ) روش کار میکنند حتما باید از Version Control ها استفاده کرد برای دوری از هرج و مرج و دنبال کردن دقیق تغییرات.

    یک Version Control معمولا امکانات زیر را در اختیار ما قرار میده:

    • Backup and Restore :هر فایلی که تغییر کرد ذخیره خواهد شد. علاوه بر آن هر زمانی که خواستیم به یک فایل که مثلا در تاریخ ۱ خرداد ۹۱ داشتیم برگردیم با اینکه این فایل الان خیلی تغییرکرده این کار امکان پذیر خواهد بود.
    • Synchronization : اجازه میدهد که تمام برنامه نویسان پروژه آخرین نسخه تولیدی از کار همه اعضای گروه را داشته باشند. البته میتوان سطوح دسترسی تعیین کرد.
    • Short-term undo : ممکن است شما یه تغییر کوچک روی فایل باعث مشکلات زیادی بشود. با استفاده از VCS ها شما به راحتی به ورژن قبلی یک فایل خواهید رفت.
    • Track Changes : بعد از اینکه هر فایل تغییر کرد در نرم افزار VCS میتوان دلیل این تغییر را هم بیان کرد تا در آینده دلیل این تغییر را بدانیم و راحت تر تغییرات را دنبال کنیم.
    • Branching and merging : شاید گاهی اوقات لازم باشد که بتوانیم یک تکه از پروژه رو جدا کرده در یک محیط ایزوله ( منظور این است که در پروژه اصلی دخالت ندارد و تغییر در آن تغییر در پروژه اصلی را باعث نمی شود. ) کد را تغییر داده و بعد در صورت نیاز آن را به پروژه اصلی الصاق کنیم.

    لغات اصلی در کار با یک VCS

    زمانی که با یک VCS کار میکنیم لغات زیر زیاد شنیده می شود:

    • Repository (repo) : جایی که فایل های پروژه نگه داری میشود. مثل یک انبار ( یک دیتابیس )
    • Server  : جایی که repo روی آن قرار میگیرد.
    • Client : کامپیوتر هایی که به repo برای گرفتن کد و یا فرستادن کد وصل میشوند.
    • Working Set/Working Copy: : یه نکته رو دقت کنید. زمانی که شما در یک محیط VCS قرار دارید کد را در کامپیوتر خود تغییر داده و برای سرور ارسال میکنید تا نگه داری شود. به جایی که کد خودتان قرار دارد Working Set یا Working Directory گفته میشود.
    • Trunk/Main : پوشه اصلی در repo که کد در آن قرار میگیرد.

    در زمانی که با یک VCS کار میکنیم ممکن است عملیات هایی هم انجام دهیم که شامل موارد زیر است :

    • Add  : زمانی که برای اولین بار یک فایل را به یک VCS اضافه کنیم و در واقع شروع زمان نگه داری تمام ورژن های این فایل.
    • Reversion : همانطور که گفتیم زمانی که یک فایل به VCS اضافه میشود شامل ورژن هایی خواهد شد. برای مثال v1, v2, …
    • Head : آخرین Reversion یک فایل در repo
    • Checkout  :  دانلود کردن یک فایل از repo را گوییم.
    • Check in  : فرستادن یک فایل تغییر کرده برای به repo در صورتی که تغییر کرده باشد. در این صورت فایل یک reversion جدید خواهد گرفت و بقیه میتوانند این فایل را “check out”  کنند.
    • Checkin Message : زمانی که یک فایل تغییر میکند بهتر است برای آن دلیلی بیان شود. که چرا فایل تغییر کرده.
    • Changelog/History : میتوانیم تمام تغییرات یک فایل و تاریخ و Chekcin Message آن ها را ببینیم.

    Update/Sync :  شما میتوانید نسخه کدی که روی آن کار میکنید را به آخرین نسخه ای که توسط مدیر تولید شده به روز کنید.

    برای مثال :

    علی فایل list.txt را به Repository ما Add میکند. علی فایل را از Repository ما Check out  میکند آنرا تغییر میدهد. آن را Check in میکند با Check in message   : مواد لازم اضافه شد. روز بعد حسین Local Working Directory  خود را Update  میکند. و متوجه میشود که فایل list.txt توسط علی تغییر کرده است.

    یک مثال عملی :

    همونطور که گفتیم ویندوز یه پوشه نیست که همه برنامه نویسان کد شون رو با اون مطابقت بدند و تغییرات رو روی اون اعمال کنند.

    مثال رو برو را دقت کنید. خط آبی رنگ همان پروژه اصلی است. فرض کنید ما مسئول نوشتن Windows Media Player 10 ( MP10)  و همچنین Internet Explorer 6 ( IE6) هستیم. خوب گروه بالا گروه MP هست که یه شاخه از پروژه اصلی ایجاد کرده و انرا تغییر داده و MP11 رو ایجاد کرده . اگر این ورژن MP تست شد و مشکلی نداشت آنرا از شاخه به پروژه اصلی منتقل میکنیم که به آن Reverse Integrate یا RI گوییم. دقیقا همین اتفاق برای IE افتاده و IE هفت به پروژه اصلی آمده است. حالا گروه MP باید آخرین نسخه پروژه اصلی را داشته باشد چون ممکن است تغییرات گروه IE برای آنها مهم بوده باشد. در این صورت شاخه خود را با آخرین نسخه آپدیت کرده که به آن FI یا Forward Integrate گوییم.  دقیقا همین کار را گروه IE هم انجام میدهد. و کار به همین صورت جلو میرود.

    منبع

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

۱,۴۳۱ total views, 1 views today

Print Friendly, PDF & Email

درباره ی سعید دادخواه

یه برنامه نویس !

همچنین ببینید

ویدیوهای بخش گرافیک

سلام دوستان گل عیدتون مبارک بعضی از دوستان درخواست آپلود بخش گرافیک رو داشتند که …

دیدگاه بگذارید

avatar
  مشترک شو!  
میخوام باخبر شم از