ورژن کنترل(VCS) و گیت چیست؟
یک برنامهنویس مبتدی تا زمانی که با چیزی تحت عنوان Version Control System (سیستم کنترل نسخه) آشنایی نداشته باشد، هرگز نخواهد توانست برچسب حرفهای روی خود بزند! شرکتهای نرمافزار تراز اول، برنامهنویسان باتجربه و به طور کلی حرفهایها در دنیای برنامهنویسی در پروسهٔ کاری خود از یکسری VCS استفاده میکنند و آنچه در این فصل قصد داریم بررسی کنیم، مقدمهای بر این دست سیستمها به همراه انواع آنها و مزایای استفاده از چنین سیستمهایی است.
Version Control System که به اختصار VCS خوانده میشود عبارت است از سیستمی که به توسعهدهندگان نرمافزار کمک میکند تا علاوه بر امکان مشارکت روی پروژههای نرمافزاری، بتوانند به تاریخچهای از کدهایی که قبلاً نوشتهاند نیز دست پیدا کنند و به طور کلی اهداف استفاده از سیستمهای ورژن کنترل (VCS) را میتوان در موارد زیر خلاصه نمود:
- فراهم آوردن فرصتی برای توسعهدهندگان به منظور کار کردن به صورت همزمان
- مجزاسازی نسخههای توسعه داده شدهٔ اختصاصی تکتک توسعهدهندگان
- نگهداری تاریخچهای از هر نسخه از هر چیزی که به اشتراک گذاشته شود
به طور کلی، میتوانیم سیستم ورژن کنترل را به عنوان یک دیتابیس در نظر بگیریم که به توسعهدهندگان این اجازه را خواهد داد تا در هر زمانی که تمایل داشته باشند، نسخهای از نرمافزار مد نظر خود را در آن ذخیره سازند. حال در آینده زمانی که به یکسری Version (نسخه) قدیمی نگاهی میاندازیم،
دقیقاً متوجه خواهیم شد که کدام بخش از نرمافزار دستخوش تغییر شده است. به طوری کلی، از جمله مزایای نرمافزارهای ورژن کنترلی مثل Git این است که محدود به زبان برنامهنویسی خاص و همچنین ویرایشگر کد خاصی نبوده و هر نوع سورسکدی که با هر نرمافزاری نوشته شده باشد را ساپورت میکنند.
فرض کنیم که یکی از اعضای تیم آرشام نام دارد و دیگری حمید. بهزاد در حال کار کردن روی فایلی است تحت عنوان مثلاً login.php که در چنین شرایطی می بایست به محمد بگوید که یک بار شروع به کار کردن روی این فایل نکند چرا که در این صورت، تغییراتی که بهزاد دارد روی فایل میدهد ممکن است از دست بروند.
حال فرض کنیم به غیر از آرشام و حمید، چندین توسعهدهنده ی دیگر هم به تیم اضافه میشوند و اینجا است که عمق فاجعه هم دوچندان شده و امکان بروز خطا چندین برابر خواهد شد. در اینجا است که وجود یک نرمافزار ورژن کنترل شدیداً احساس می گردد. در چنین نرم افزاری، هر یک از اعضای تیم این امکان را خواهد داشت تا با فراغ بال در هر کجا و هر زمانی شروع به کار روی هر فایلی از پروژه که خواست بکند چرا که در نهایت، نرمافزار ورژن کنترل این امکان را به ما خواهد داد تا کلیه ی تغییرات را اصطلاحاً Merge یا «ادغام» کرده و کلیه ی توسعه دهندگان از تمامی تغییرات برخوردار خواهند شد.
علاوه بر این، در شرایطی که تیم های توسعه ی نرمافزار از ورژن کنترل استفاده نکنند، به دشواری خواهند توانست اقدام به Backup (بکاپ یا نسخه ی پشتیبان) گیری نرمافزار خود کنند. مهمترین مسأله در اینجا، نامگذاری نسخه ها است تا در آینده بر آن اساس بتوان یک نسخه ی خاص را یافت. اگر فرض را هم بر این بگذاریم که بتوانیم به نسخه ی بکاپ مد نظر خود دست پیدا کنیم، حال چگونه می بایست متوجه شویم که در این نسخه ی مد نظر چه بخشهایی دستخوش تغییر شده اند.
تمامی نقاط ضعف فوق الذکر، ما را مجاب خواهد کرد که به سمت ورژن کنترل مهاجرت کنیم. در سیستمهای ورژن کنترل، پروژه ی ما صرفاً یک نسخه بیشتر نخواهد داشت که نسخه ی نهایی است و سایر نسخه ها نیز به عنوان بکاپ در نظر گرفته خواهند شد که به سادگی قابل دسترسی هستند.
هر زمانی که ما تغییری در پروژه ایجاد میکنیم و قصد داریم پروژه ی خود را در سیستم ورژن کنترل آپلود کنیم، نرمافزار از ما میخواهد که حتماً توصیف کوتاهی از تغییراتی که در پروژه دادهاید ذکر کنید. حال فرض کنیم در پروژه ی خود تغییراتی دادهایم اما بعداً کاشف به عمل میآید که تغییرات اخیر اصلاً اثربخش نبودهاند و نیاز داریم تا نرمافزار را به نسخه ی مثلاً یک هفته قبل برگردانیم. با استفاده از سیستمهای ورژن کنترل، این کار به سادگی و با نوشتن چند دستور ساده امکانپذیر خواهد بود.
انواع سیستم های ورژن کنترل یا کنترل نسخه
در این آموزش قصد داریم تا دو سیستم ورژن کنترل معروف که عبارتند از Subversion و Git را مقایسه کنیم. Subversion که به اختصار SVN نیز خوانده می شود یک سیستم کنترل نسخه ی اصطلاحاً Centralized یا «متمرکز» است. به عبارت دیگر، تمامی اعضای تیم توسعه ی نرمافزار روی یک نسخه ی واحد که روی سروری خاص قرار دارد کار می کنند. وقتی توسعهدهنده ای اقدام به دریافت یک نسخه از پروژه از روی سرور می کند، اس وی ان آخرین نسخه از پروژه را در اختیار وی قرار خواهد داد.
در سیستم ورژن کنترل Git که یک سیستم اصطلاحاً Distributed یا «نامتمرکز» است، شرایط تا حدودی متفاوت تر است. زمانی که یکی از توسعه دهندگان پروژه ای را از روی سرور اصطلاحاً Clone (کلون به معنی دریافت کردن) می کند، وی نسخهای کامل و جامع از آنچه روی سرور قرار دارد را در دست خواهد گرفت که شامل تاریخچه ی تغییرات پروژه نیز می باشد.
برنچ
معنی لغوی Branch «شاخه» است و برای درک بهتر این موضوع، میتوان پروژه ی اصلی را به مثابه ی یک درخت تلقی کرد که روی هر شاخه ی آن میتوان هر چیزی که تمایل داشته باشیم ایجاد کرده و این در حالی است که هر شاخه مجزا از سایر شاخه ها میتواند مورد استفاده قرار گیرد. همانطور که قبلاً توضیح داده شد، در سیستم ورژن کنترل اس وی ان، دایرکتوری هایی که دارای معنای خاصی هستند -مثلا به زمان یا تغییرات خاصی اشاره می کنند- تحت عنوان برنچ شناخته می شوند. زمانی که یک برنچ جدید می سازیم، ما یک کپی از کل پروژه در یک فولدر جدید ساخته ایم.
در سیستم ورژن کنترل گیت، برنچ معنای متفاوتی نسبت به اس وی ان دارا است. در گیت، برنچ به بخش خاصی از یک نسخه اشاره میکند بنابراین، به هیچ وجه هیچ گونه کپی جدید از پروژه،
دایرکتوری های جدید و فایلهای جدیدی از روی پروژه ی اصلی ساخته نخواهد شد. در سیستم گیت، به محض ایجاد یک پروژه، یک برنچ هم به صورت پیشفرض تحت عنوان Master یا «اصلی» ایجاد میگردد و شما به عنوان یک توسعه دهنده، همواره روی یک برنچ در گیت کار می کنید. پروژه ای که روی آن کار می کنید، حاوی فایلهایی است که متعلق به برنچ فعال اصلی که اصطلاحاً Head نامیده میشود میباشند و کلیه ی نسخه ها و برنچ های دیگر در ریپازیتوری لوکال -سیستم خودتان- ذخیره خواهند شد.
آشنایی با مفهوم Commit در ورژن کنترل
زمانی که در سیستم اس وی ان چیزی را Commit (کامیت به معنی سپردن) می کنیم، شرایطی خاصی برقرارند که عبارتند از:
- شما صرفاً زمانی میتوانید تغییری را کامیت کنید که به ریپازیتوری مرکزی متصل باشید و در حالت آفلاین چنین امکانی برای شما وجود نخواهد داشت.
- کامیت شما خیلی سریع به ریپازیتوری مرکزی منتقل خواهد شد.
- شماره ای از نزولی به صعوی به کامیت شما اختصاص خواهد یافت که به عنوان شناسه ی کامیت شما در نظر گرفته می شود.
کامیت کردن در گیت تا حدودی متفاوت است. برخی خصوصیات کامیت در گیت عبارتند از:
- برای کامیت کردن، شما اصلاً نیازی به آنلاین بودن و داشتن ارتباط با ریپازیتوری اصلی نخواهید داشت چرا که نسخه ی کامل و جامعی از پروژه روی سیستم لوکال شما قرار دارد. لذا کامیت ها در ریپازیتوری لوکال شما ثبت شده و صرفاً زمانی که خودتان تصمیم بگیرید، به ریپازیتوری اصلی یا آنلاین انتقال خواهند یافت.
- صرفاً به این خاطر که یک فایل تغییر کرده است بدان معنا نیست که فایل مد نظر به صورت خودکار می بایست در کامیت بعدی در نظر گرفته شود. خود توسعهدهنده می بایست تغییراتی که مد نظرش هستند را مشخص کند تا در کامیت در نظر گرفته شوند.
- از آنجا که کامیت ها در ریپازیتوری لوکال توسعهدهنده که آفلاین است اعمال می شوند، سیستم گیت قادر نخواهد بود تا مشخص کند مثلاً کامیت شماره 5 متعلق به کدام توسعهدهنده است. لذا شماره های نسخه های مختلف در گیت اصطلاحاً Hash یا «رمزنگاری» میشوند تا هر کامیت دارای یک شناسه منحصر به فرد باشد.
به اشتراک گذاری
در اس وی ان، پروژه ی شما زمانی که آن را کامیت می کنید به صورت خودکار به سرور مرکزی انتقال داده خواهد شد و کامیت کردن صرفاً زمانی امکانپذیر است که شما با سرور مرکزی ارتباط آنلاین داشته باشید اما در گیت هیچ چیزی به صورت خودکار به سرور اصلی سپرده نخواهد شد و این توسعهدهنده است که تصمیم میگیرد که برنچ با اعضای تیم به اشتراک گذاشته شود یا خیر!
علاوه بر این، به اشتراک گذاری پروژه کاملاً ایمن است، Conflict (کانفلیکت یا تداخل) صرفاً روی سیستم لوکال توسعهدهنده ایجاد میشود و هرگز اتفاق بدی برای پروژه ی قرار گرفته روی سرور نخواهد افتاد! همین مسأله منجر میگردد که برنامه نویسان مبتدی با خیال راحت کار کنند و هرگز نگران این نباشند که سهواً پروژه ای که روی ریپازیتوری اصلی قرار گرفته است را خراب کنند.
تاریخچه ی سیستم ورژن کنترل یا کنترل نسخه
هسته ی لینوکس -Linux Kernel- یک پروژه ی اپن سورس واقعا عظیم است و توسعه دهندگان زیادی از سراسر دنیا روی آن کار می کنند. در سال های اولیه ی شکل گیری لینوکس، بخش اعظمی از این پروژه در قالب فایلهایی که توسط برنامه نویسان مختلف توسعه داده میشد و در اختیار ادمین -یا ادمین های پروژه- قرار میگرفت و ایشان مسئول اعمال تغییرات مد نظر بودند تا این که تیم توسعه ی لینوکس در سال 2002 شروع به استفاده از یک سیستم ورژن کنترل تحت عنوان BitKeeper کرد.
در سال 2005 ارتباط مابین توسعه دهندگان هسته ی لینوکس و شرکتی که نرمافزار Bitkeeper را طراحی کرده بود رو به سردی گذاشت و همین مسأله منجر به این گشت تا جامعه ی توسعه دهندگان لینوکس -به خصوص خالق اصلی هسته ی لینوکس آقای لینوس تروالدز- تصمیم به این گرفتند تا بر اساس درسهایی که از نرمافزار قبلی گرفته بودند، سیستم ورژن کنترل اختصاصی خود را طراحی کنند.
از همان روز نخست، جامعه ی توسعه دهندگان لینوکس سرعت، سادگی، پشتیبانی قوی، امکان کار کردن از راه دور و همچنین قابلیت پشتیبانی از پروژه های بزرگ را مد نظر داشتند. نتیجه این شد که سیستم ورژن کنترل GIT که یک ابزار اپن سورس و رایگان است در سال 2005 متولد شد که بخش اعظمی از آن با زبان C نوشته شده است. در حال حاضر، این سیستم به عنوان معروف ترین و محبوب ترین سیستم ورژن کنترل دنیا محسوب می گردد که شرکت های بزرگی همچون یاهو، توییتر، گوگل، آمازون، مایکروسافت و اپل از آن استفاده می کنند.
خب دوستان سعی کردیم خیلی خلاصه درباره سیستم کنترل نسخه صحبت کنیم.
در درس بعدی با ما همراه باشید با ادامه آموزش دستورات پایه و مهم گیت
منبع این مقاله : سکان آکادمی