لطفا جاواسکریپت مرورگر خود را فعال سازید!

نحوه فعال سازی در کروم
  1. ابتدا باید اینکارو بگنید
  2. بعدش اونکارو
نحوه فعال سازی در فایرفاکس
  1. ابتدا باید اینکارو بگنید
  2. بعدش اونکارو
ورژن کنترل (Version Control) چگونه کار می‌کند؟

ورژن کنترل (Version Control) چگونه کار می‌کند؟

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

پیش از شروع کار با پلتفرم‌های Version Control، یکسری مفاهیم عمومی وجود دارند که آشنایی با آن‌ها و از آن مهم‌تر، پیدا کردن درک درستی از سازوکار آن‌ها الزامی است که عبارتند از:

۱. شروع پروژه
در صورتی که بخواهید پروژهٔ جدیدی را شروع کنید، می‌بایست از دستور git init استفاده کنید؛ این دستور در فولدر روت پروژه‌تان، یک ریپازیتوری (Repository) خالی گیت می‌سازد و از این پس شما امکان وارد کردن فایل‌هایتان به سیستم ورژن کنترل مدنظرتان را خواهید داشت.

اما اگر می‌خواهید روی یک پروژه از پیش تعریف شده کار کنید، از دستور <git clone <remote url باید استفاده نمایید. این دستور یک کپی کامل از ریپازیتوری موجود در آدرسی که به آن می‌دهید روی کامپیوتر‌تان کپی می‌کند که تاریخچهٔ تمامی تغییرات پروژه را هم با خود به‌همراه دارد.

۲. کار بر روی فایل‌هایتان
هر کاری که دوست دارید می‌توانید با فایل‌ها انجام دهید؛ آن‌ها را ویرایش کنید، اسم‌ فایل‌ها را عوض کنید، فایل را اگر لازم ندارید حذف کنید و حتی فایل‌های جدید اضافه کنید. می‌توانید از ویرایشگر کد، IDE و فایل‌منجر دلخواه‌تان نیز استفاده کنید و در این رابطه هیچ محدودیتی نخواهید داشت. در حین ویرایش، برای فایل‌های وضعیت‌های مختلفی در نظر گرفته می‌شود که در ادامه بیشتر در مورد آن‌ها صحبت خواهیم کرد.

درواقع، فایل‌هایی که با ورژن کنترل مدیریت نمی‌شوند Untracked نامیده می‌شوند و درمقابل فایل‌هایی که با ورژن کنترل مدیریت شده‌اند Tracked خوانده می‌شوند. یک فایل Tracked می‌تواند بدون تغییر باشد به این معنا که از آخرین کامیت (Commit) تغییری نداشته است و یا تغییر کرده باشد که بدین معنا است که به‌صورت لوکال حاوی یکسری تغییرات باشد.

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

4. افزودن فایل‌ها به Staging Area
صرفاً اگر فایل تغییر کند به این معنی نیست که حتماً می‌خواهید کامیت هم بشود؛ این تصمیم با شما است که کدام فایل‌ها را کامیت کنید و برای این کار با دستور <git add <filename به طور واضحی فایل‌های مورد نظرتان را برای کامیت شدن، مشخص می‌کنید. با این عمل، اصطلاحاً گفته می‌شود که فایل‌ها به Satging Area اضافه شده‌اند.

5. کامیت کردن همهٔ تغییرات
کامیت، تمام تغییراتی را که با دستور git add در حالت Stage قرار داده‌اید را در برخواهد گرفت؛ برای ثبت همهٔ این تغییرات در دیتابیس گیت، باید از دستور git commit استفاده کنید که می‌تواند یک پیام کوچک در مورد تغییرات را هم با افزودن آپشن "m "message- به همراه داشته باشد (کامنت مد نظر را بایستی جایگزین واژهٔ message کرد.)

6. چک کردن وضعیت کلی
پیش از این با دستور git status آشنا شدیم؛ با اجرای دستور git status درست بعد از دستور git commit می‌توانید از اعمال تغییراتی که Stage شده‌اند مطمئن شوید. سایر تغییراتی که Stage نشده‌اند به‌صورت لوکال روی کامپیوتر شما ثابت مانده‌اند که می‌توانید با آن‌ها کار را ادامه داده و یا از تغییرات‌تان صرف نظر کنید.

7. لاگ‌ها
با دستور git log، می‌توانید لیست کامل کامیت‌ها را ببینید که به شما در درک بهتر پروژه، جزئیات و تغییرات آن کمک می‌کند.

آشنایی با مفاهیم برنچینگ (Branching) و مرجینگ (Merging)
گاهی‌اوقات در پروژه‌ها مجبوریم روی موضوعاتی به شکل موازی کار کرده و کارهای متفاوتی را انجام دهیم؛ مثلاً قابلیت الف، رفع باگ ۱۹، قابلیت ب و غیره. این خود باعث می‌شود که به‌سادگی دچار سردرگمی دربارهٔ محل هر تغییر بشویم لذا بسیار مهم است که این کانتکس‌ها (فضا‌های کاری) را از هم جدا نگهداریم.

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

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

1. ایجاد یک برنچ جدید
هرگاه که بخواهید برنچ جدیدی را اضافه کنید یا رفع‌باگی انجام دهید و یا حتی موضوعی را تست کنید، باید یک برنچ جدید بسازید. در گیت این کار بسیار ساده و سریع انجام می‌شود چراکه فقط کافی است دستور <git branch <new-branch-name را اجرا نمایید و صاحب یک برنج جدید خواهید شد. در مورد برنچ ساختن اصلاً تردید نکنید چراکه بسیار کارا است و البته هزینه‌ای هم برایتان ندارد!

۲. جابه‌جا شدن در بین کانتکس‌های مختلف
برای شروع کار روی یک کانتکس دیگر باید به گیت بگویید که می‌خواهید جابه‌جا شوید و به کانتکس دیگری بروید؛ این کار را با دستور <git checkout <new-branch-name می‌توانید انجام دهید. به این‌کار چک‌اوت (Checkout) نیز می‌گویند. هر کامیتی که انجام دهید در این برنچ خواهد ماند -تا وقتی به برنچ دیگری بروید- تا از سایر کانتکس‌ها جدا بماند.

۳. ادغام کردن تغییرات
وقتی قابلیت جدیدی که برای برنامه‌تان نوشته‌اید کامل شد، شاید بخواهید با برنچ دیگری این کد‌ها را ادغام (Merge) کنید؛ برای این کار، نخست به برنچی که می‌خواهید کد‌ها را با آن ادغام کنید بروید، سپس با دستور <git merge <branch-to-integrate به همراه نام برنچی که می‌خواهید پیوند داده شود، این کار را انجام دهید.

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

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

1. استفاده از یک برنچ ریموت (Remote)
اگر برنچ ریموت جالبی نظرتان را جلب کرده است، می‌توانید به‌راحتی یک نسخهٔ لوکال از آن‌را برای خود داشته باشید؛ دستور <git checkout --track <remote/branch برایتان برنچ ریموتی راکه معرفی کرده‌اید را گرفته و برنچ جدیدی بر پایهٔ آن به‌صورت لوکال روی کامپیوترتان می‌سازد.

حال زمان‌هایی پیش می‌آید که قصد دارید یک برنچ لوکال را با سایرین به‌اشتراک بگذارید؛ برای اشتراک گذاشتن یک برنچ لوکال با سایرین، از دستور <git push -u <remote><local-branch استفاده کنید.

۲. با تغییرات ریموت همگام بمانید
وقتی با دیگران در یک تیم همکاری می‌کنید، قطعاً می‌خواهید که همیشه از تغییرات جدید خبر داشته باشید؛ دستور git fetch این کار را برای شما با دانلود تغییرات جدید از ریپازیتوری ریموت انجام می‌دهد اما این تغییرات را با نسخهٔ لوکال شما ادغام نمی‌کند بلکه فقط شما را از تغییرات آگاه می‌کند و تصمیم ادغام را به شما محول می‌کند.

۳. ادغام تغییرات ریموت
برای ادغام تغییرات از ریپازیتوری ریموت، به‌راحتی دستور git pull را اجرا کنید تا برنچ HEAD فعلی‌تان را از برنچ ریموت مشابه برای‌تان دریافت و با نسخهٔ لوکالتان مستقیماً ادغام کند.

۴. آپلود تغییرات لوکال به سرور
برای آپلود تغییراتی که در برنچ HEAD فعلی‌تان داده‌اید، لازم است دستور git push را اجرا کنید و گیت کلیهٔ تغییرات شما را روی سرور ریموت می‌فرستد.

سخن پایانی
واقعیت امر آن است که سیستم‌های کنترل نسخه دارای یکسری ترفندهای خاص خود نیز هستند و زمانی که به‌صورت واقعی شروع به استفاده از آن‌ها می‌کنیم، با یکسری چالش‌هایی -مثلاً کانفلیک نسخهٔ لوکال با نسخهٔ ریموت- مواجه می‌شویم که حل‌وفصل کردن آن‌ها گاهی‌اوقات نیاز به صبر و حوصلهٔ فراوانی دارد! درواقع، آنچه در این مقاله ارائه گردید، صرفاً نمایی کلی برای دولوپرهای مبتدی بود که تازه قصد شروع به استفاده از سیستم‌های کنترل نسخه‌ای همچون Git را دارند.

منبع