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

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

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

git clone <remote url> 

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

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

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

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

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

$ git branch <new-branch-name>

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

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

$ git checkout <new-branch-name>

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

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

$ git merge <branch-to-integrate>

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

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

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

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

$ git checkout --track <remote/branch>

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

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

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

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

$ git fetch

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

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

$ git pull

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

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

$ git push

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

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

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