سیستم کنترل نسخه گیت

وقتی شروع به کار با یک Version Control System یا به اختصار VCS می‌کنید، باید در ابتدا با کلیات این سیستم آشنا شده و آن‌‌ها را به‌ درستی درک کنید. همچنین قبل از اینکه ذهن‌تان را با کامندهای مختلف درگیر کنید، باید مطمئن شوید که مفاهیم عمومی را به‌ خوبی متوجه شده‌اید. در غیر اینصورت کار با سیستم‌های کنترل نسخه همچون Git تبدیل به یک کابوس خواهد شد! سیستم کنترل نسخه، سیستمی برای کنترل و پی‌گیری تغییرات واحد اطلاعاتی دخیل در ایجاد یک برنامهٔ نرم‌افزاری است. واحد اطلاعاتی مزبور می‌تواند شامل فایل‌های سورس، راهنماها، اشیاء نرم‌افزاری و … باشد. سیستم کنترل نسخه در جایی اهمیت پیدا می‌کند که چند برنامه‌نویس بخواهند روی منابع مشترکی کار کنند یا مثلا هنگامی که بروز رسانی شما دچار ایراداتی شده و شما می‌خواهید آن را به نسخه قبلی که سالم است، برگردانید.

سیستم کنترل نسخه چیست

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

سیستم کنترل نسخه عبارت است از سیستمی که به توسعه‌دهندگان نرم‌افزار کمک می‌کند تا علاوه بر امکان مشارکت روی پروژه‌های نرم‌افزاری، بتوانند به تاریخچه‌ای از کدهایی که قبلاً نوشته‌اند نیز دست پیدا کنند و به طور کلی اهداف آن را می‌توان در موارد زیر خلاصه نمود:

• فراهم آوردن فرصتی برای توسعه‌دهندگان به منظور کار کردن به صورت هم‌زمان
• مجزاسازی نسخه‌های توسعه داده شدهٔ اختصاصی تک‌تک توسعه‌دهندگان
• نگهداری تاریخچه‌ای از هر نسخه از هر چیزی که به اشتراک گذاشته شود

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

نحوه عملکرد سیستم کنترل نسخه

قبلا از روش subversion استفاده می‌شد که تغییرات نسبت به ورژن قبل را نگه می‌داشت و نیاز به سرور اصلی داشت. اما با معرفی سیستم کنترل نسخه گیت در سال 2005 توسط مخترع لینوکس، همه برنامه نویسان و گسترش دهندگان نرم افزار به برتری این روش اذعان کردند و هم اکنون بسیاری از شرکت‌های بزرگ (حتی توئیتر و فیس بوک) نیز پروژه‌های خود را با سیستم کنترل نسخه گیت در سایت github و سایر سایت‌های مشابه نگهداری و گسترش می‌دهند.

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

برای شروع توصیه می‌شود که از Try Git استفاده کنید و اگر اهل ویندوز هستید، این نسخه ویندوزی را برای کار با آن دانلود و نصب کنید.

از جمله مزایای نرم‌افزارهای ورژن کنترلی مثل Git این است که محدود به زبان برنامه‌نویسی خاص و همچنین ویرایشگر کد خاصی نبوده و هر نوع سورس‌کدی که با هر نرم‌افزاری نوشته شده باشد را ساپورت می‌کنند.

اصطلاحات مورد استفاده در گیت

آموزش کار با سیستم کنترل نسخه گیت

شروع پروژه

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

git clone <remote url>

این دستور یک کپی کامل از ریپازیتوری موجود در آدرسی که به آن می‌دهید روی کامپیوتر‌تان کپی می‌کند که تاریخچهٔ تمامی تغییرات پروژه را هم با خود به‌ همراه دارد.

کار بر روی فایل‌ها

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

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

نمایش وضعیت

برای اینکه از آخرین تغییرات پروژه باخبر شوید، باید از کامند زیر استفاده کنید:

$ git status

به عبارت دیگر، با اجرای این کامند خواهید فهمید که چه فایل‌هایی را تغییر داده‌اید، آیا فایل جدیدی ساخته‌اید و یا کدام فایل‌ها را حذف کرده‌اید.

افزودن فایل‌ها به Staging Area

صرفاً اگر فایل تغییر کند به این معنی نیست که حتماً می‌خواهید کامیت هم بشود؛ این تصمیم با شما است که کدام فایل‌ها را کامیت کنید و برای این کار باید از دستور زیر استفاده کنید:

$ git add <filename>

در واقع، با استفاده از این کامند به طور واضح فایل‌های مورد نظرتان را برای کامیت شدن، مشخص می‌کنید. با این عمل، اصطلاحاً گفته می‌شود که فایل‌ها به Satging Area اضافه شده‌اند.

پروسهٔ Commit هم تمام تغییراتی را که با دستور git add در حالت Stage قرار داده‌اید را در بر خواهد گرفت؛ برای ثبت همهٔ این تغییرات در دیتابیس گیت، باید از دستور زیر استفاده کنید:

$ git commit

این دستور می‌تواند یک پیام کوچک در مورد تغییرات را هم با افزودن آپشن “m “message- به همراه داشته باشد(کامنت مد نظر را بایستی جایگزین واژهٔ message کرد).

چک کردن وضعیت کلی

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

لاگ‌ها

برای مشاهدهٔ لاگ‌ها، باید از کامند زیر استفاده کنید:

$ git log

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

آشنایی با مفاهیم Branching و مرجینگ Merging

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

HEAD Branch

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

ایجاد یک برنچ جدید

هرگاه که بخواهید برنچ جدیدی را اضافه کنید یا رفع‌ باگی انجام دهید و یا حتی موضوعی را تست کنید، باید یک برنچ جدید بسازید. در گیت این کار بسیار ساده و سریع انجام می‌شود چرا که فقط کافی است دستور زیر را وارد کنید:

$ git branch <new-branch-name>

با اجرای این کامند، صاحب یک برنج جدید خواهید شد. در مورد برنچ ساختن اصلاً تردید نکنید چرا که بسیار کارا است و البته هزینه‌ای هم برایتان ندارد!

جابه‌جا شدن در بین فضاهای کاری مختلف

برای شروع کار روی یک contex (فضای کاری) دیگر، باید به گیت دستور دهید که می‌خواهید جابه‌جا شوید و به کانتکس دیگری بروید که این کار را با دستور زیر می‌توان عملی ساخت:

$ git checkout <new-branch-name>

همچنین به این‌ کار Checkout نیز می‌گویند به طوری که هر کامیتی که انجام دهید در این برنچ خواهد ماند (البته تا وقتی به برنچ دیگری نرفته‌اید) تا از سایر کانتکس‌ها جدا بماند.

ادغام کردن تغییرات

وقتی قابلیت جدیدی که برای برنامه‌ٔ خود نوشته‌اید کامل شد، شاید بخواهید با برنچ دیگری این کد‌ها را اصطلاحاً Merge (ادغام) کنید که برای این کار، نخست باید به برنچی که می‌خواهید کد‌ها را با آن ادغام کنید رفته، سپس دستور زیر را وارد کنید:

$ git merge <branch-to-integrate>

در واقع کامند فوق را باید به همراه نام برنچی که می‌خواهید ادغام شود، اجرا کنید.

اشتراک‌گذاری پروژه از طریق ریپازیتوری‌های ریموت

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

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

استفاده از یک برنچ ریموت (Remote)

اگر برنچ ریموت جالبی نظرتان را جلب کرده است، می‌توانید به‌ راحتی یک نسخهٔ لوکال از آن‌ را برای خود با اجرا کامند زیر داشته باشید:

$ git checkout --track <remote/branch>

این کامند برنچ ریموتی را که معرفی کرده‌اید را گرفته و برنچ جدیدی بر پایهٔ آن به‌ صورت لوکال روی کامپیوترتان می‌سازد. حال زمان‌هایی پیش می‌آید که قصد دارید یک برنچ لوکال را با سایرین به‌ اشتراک بگذارید:

$ git push -u <remote><local-branch>

برای اشتراک گذاشتن یک برنچ لوکال با سایرین هم می‌توانید از کامند فوق استفاده کنید.

با تغییرات ریموت همگام بمانید

وقتی با دیگران در یک تیم همکاری می‌کنید، قطعاً می‌خواهید که همیشه از تغییرات جدید خبر داشته باشید که دستور زیر این کار را به سادگی برایتان انجام خواهد داد:

$ git fetch

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

ادغام تغییرات ریموت

برای ادغام تغییرات از ریپازیتوری ریموت، به‌ راحتی دستور زیر را اجرا کنید:

$ git pull

این کامند برنچ HEAD فعلی‌تان را از برنچ ریموت مشابه برای‌تان دریافت و با نسخهٔ لوکالتان مستقیماً ادغام کند.

آپلود تغییرات لوکال به سرور

برای آپلود تغییراتی که در برنچ HEAD فعلی‌تان داده‌اید، لازم است دستور زیر را اجرا کنید:

$ git push

که با اجرای این کامند، گیت کلیهٔ تغییرات شما را روی سرور ریموت deploy می‌کند (می‌فرستد).

سیستم‌های کنترل نسخه دارای یکسری ترفندهای خاص خود نیز هستند و زمانی که به‌ صورت واقعی شروع به استفاده از آن‌ها می‌کنیم، با یکسری چالش‌هایی مثلاً conflict (تداخل) نسخهٔ لوکال با نسخهٔ ریموت مواجه می‌شویم که حل‌وفصل کردن آن‌ها گاهی‌ اوقات نیاز به صبر و حوصلهٔ فراوانی دارد!

در واقع، آنچه در این مقاله ارائه گردید، صرفاً نمایی کلی برای developerهای مبتدی بود که تازه قصد شروع به استفاده از سیستم‌های کنترل نسخه‌ای همچون Git را دارند.

برای استفاده راحت تر از گیت، آن را به phpstorm متصل کنید. در phpstorm دیگر نیازی به کد زدن برای گیت ندارید و با محیط کاربری phpstorm می توانید تغییرات و عملیات خود را در گیت انجام دهید. برای آموزش اتصال گیت به phpstorm، مقاله ساخت مخزن گیت در PhpStorm را مطالعه فرمایید.