شروع به کار با گیت (git) - درباره ورژن کنترل

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

برای حل همین مشکل بود که برنامه‌نویسان از دههٔ ۱۹۷۰ سراغ سیستم‌های کنترل نسخهٔ محلی رفتند؛ سیستم‌هایی با یک پایگاه دادهٔ ساده که تمام تغییرات اعمال‌شده بر فایل‌های تحت کنترل را ثبت می‌کردند.

نخستین نمونهٔ شناخته‌شده از این خانواده، SCCS بود که مارک راکایند (Marc Rochkind) در سال ۱۹۷۲ در آزمایشگاه‌های بل توسعه داد و برای مدت‌ها ابزار استاندارد کنترل نسخه در دنیای یونیکس به شمار می‌رفت. یک دهه بعد، والتر تیکی (Walter F. Tichy) در دانشگاه پردیو سیستم RCS را ساخت که به دلیل سادگی و سرعت بیشتر، جایگزین SCCS شد و هنوز هم همراه بسیاری از سیستم‌عامل‌ها عرضه می‌شود.

«RCS» با نگهداری مجموعه‌ای از پچ‌ها (یعنی تفاوت‌های میان نسخه‌های متوالی یک فایل) در قالبی ویژه روی دیسک کار می‌کند؛ سپس می‌تواند با اعمال پیاپی این پچ‌ها، هر نسخه از فایل را در هر نقطه‌ای از زمان بازسازی کند.

SCCS و RCS در شیوهٔ ذخیره‌سازی تاریخچه تفاوتی بنیادی داشتند و همین تفاوت توضیح می‌دهد چرا RCS در عمل سریع‌تر بود. SCCS تمام بازبینی‌های یک فایل را به‌صورت «درهم‌بافته» (interleaved delta، که به آن weave هم گفته می‌شود) در یک فایل واحد نگه می‌داشت؛ در این قالب هر خط با نشانه‌هایی همراه است که مشخص می‌کند آن خط در کدام بازبینی‌ها حضور دارد، بنابراین هزینهٔ بازسازی نسخهٔ قدیمی و جدید تقریباً یکسان است. RCS در مقابل از «دلتای معکوس» (reverse delta) استفاده می‌کرد: تازه‌ترین بازبینی روی شاخهٔ اصلی به‌صورت کامل ذخیره می‌شود و نسخه‌های قدیمی‌تر با اعمال پیاپی تفاوت‌های معکوس ساخته می‌شوند، در حالی که روی شاخه‌های فرعی همچنان دلتای مستقیم (forward delta) به کار می‌رود. چون در کار روزمره بیشترین درخواست‌ها مربوط به آخرین نسخه است، این طراحی رایج‌ترین عملیات را به ارزان‌ترین عملیات تبدیل می‌کرد.

تفاوت مهم دیگر در مدل همکاری بود. در RCS فایل با دستور co -l (یعنی checkout همراه با قفل) بیرون آورده می‌شد و تا زمانی که همان کاربر تغییر خود را با ci ثبت نکرده بود، دیگران اجازهٔ ویرایش آن فایل را نداشتند. این مدل «قفل انحصاری» (exclusive locking) از بروز تعارض جلوگیری می‌کرد، اما کار موازی را هم عملاً از بین می‌برد: اگر همکار شما فایلی را قفل کرده و به مرخصی رفته بود، تا بازگشت او کاری از دست کسی برنمی‌آمد. سیستم‌های بعدی این مدل را کنار گذاشتند و به‌جای آن مدل «ویرایش موازی و سپس ادغام» (merge) را برگزیدند که در آن چند نفر هم‌زمان روی یک فایل کار می‌کنند و ابزار، تغییرات را در پایان با هم تلفیق می‌کند.

محدودیت اصلی این نسل از ابزارها آن بود که واحد کارشان «یک فایل» بود، نه «یک تغییر منسجم در پروژه». به همین دلیل مفهومی مانند کامیت اتمی — یعنی ثبت هم‌زمان و تفکیک‌ناپذیر تغییرات چند فایل به‌عنوان یک واحد — در آن‌ها وجود نداشت؛ مفهومی که بعدها به یکی از پایه‌های سیستم‌های مدرن تبدیل شد. در عمل یعنی اگر یک تغییر منطقی به سه فایل دست می‌زد، سه ثبت جداگانه با سه شمارهٔ بازبینی مستقل انجام می‌شد و هیچ چیز در خودِ سیستم این سه را به هم گره نمی‌زد؛ بازگرداندن آن تغییر یا فهمیدن اینکه دقیقاً کدام مجموعه فایل با هم عوض شده‌اند، بر عهدهٔ حافظه و نظم شخصی توسعه‌دهنده بود.

چالش بزرگ بعدی زمانی پیدا شد که توسعه‌دهندگان نیاز داشتند با همکارانی روی سیستم‌های دیگر همکاری کنند. پاسخ به این نیاز، پیدایش «سیستم‌های کنترل نسخه متمرکز» (Centralized Version Control Systems یا CVCS) بود. در این سیستم‌ها — مانند CVS، Subversion و Perforce — یک سرور مرکزی تمام فایل‌های نسخه‌بندی‌شده را نگه می‌دارد و کلاینت‌ها فایل‌ها را از همان نقطهٔ مرکزی دریافت (checkout) می‌کنند. این معماری سال‌ها استاندارد عملی کنترل نسخه بود.

سرشناس‌ترین عضو این خانواده، CVS بود که دیک گرونه (Dick Grune) در سال ۱۹۸۶ آن را در قالب مجموعه‌ای از اسکریپت‌های شل روی RCS بنا کرد و نسخهٔ بازنویسی‌شده به زبان C در سال ۱۹۸۹ منتشر شد. همین ریشه‌داشتن در RCS، هم نقطهٔ قوت CVS بود و هم منشأ بیشتر کاستی‌هایش: CVS در واقع لایه‌ای شبکه‌ای و چندکاربره روی یک انبارهٔ فایل‌محور بود و بسیاری از محدودیت‌های آن انباره را به ارث برد.

شناخته‌شده‌ترین مشکلات عملی CVS این‌ها بودند:

پروژهٔ Subversion در سال ۲۰۰۰ توسط شرکت CollabNet و دقیقاً با هدف رفع همین کاستی‌ها آغاز شد؛ نسخهٔ ۱٫۰ آن در سال ۲۰۰۴ منتشر شد و در سال ۲۰۱۰ به یکی از پروژه‌های سطح‌بالای بنیاد آپاچی تبدیل شد. شعار غیررسمی پروژه در سال‌های نخست، «یک CVS بهتر» بود و همین به‌خوبی توضیح می‌دهد چه چیزهایی را تغییر داد:

نمونهٔ شاخص تجاری این نسل، Perforce است که امروز با نام Helix Core شناخته می‌شود. Perforce با آنکه معماری متمرکز دارد، هنوز هم در پروژه‌های بسیار بزرگ — به‌ویژه در صنعت بازی‌سازی و تولید محتوای دیجیتال — جایگاه محکمی دارد. دلیلش دقیقاً همان‌جایی است که سیستم‌های توزیع‌شده ضعیف‌اند: یک پروژهٔ بازی می‌تواند ده‌ها یا صدها گیگابایت دارایی باینری داشته باشد (مدل سه‌بعدی، بافت، صدا، ویدیو) که نه قابل ادغام‌اند و نه به‌خوبی فشرده می‌شوند. در مدل متمرکز، کلاینت فقط زیرمجموعه‌ای از فایل‌ها را که واقعاً نیاز دارد دریافت می‌کند و نه کل تاریخچه را؛ و مدل «چک‌اوت انحصاری» به هنرمندی که روی یک فایل باینری کار می‌کند تضمین می‌دهد که هیچ‌کس هم‌زمان همان فایل را تغییر نمی‌دهد — تضمینی که برای فایل غیرقابل‌ادغام، از هر الگوریتم merge باارزش‌تر است.

این معماری نسبت به سیستم‌های محلی مزایای روشنی دارد. برای نمونه، هر عضو تیم تا حد خوبی می‌داند دیگران مشغول چه کاری هستند؛ مدیران سیستم می‌توانند به‌دقت تعیین کنند چه کسی به چه چیزی دسترسی داشته باشد — حتی در سطح یک مسیر مشخص از درخت پروژه؛ و نگهداری یک سرور مرکزی به‌مراتب ساده‌تر از مدیریت پایگاه‌دادهٔ محلی روی تک‌تک کلاینت‌هاست.

با این حال، معایب جدی هم دارد. آشکارترین ایراد، «نقطهٔ شکست واحد» است که سرور مرکزی ایجاد می‌کند: اگر آن سرور یک ساعت از دسترس خارج شود، در تمام آن مدت هیچ‌کس نمی‌تواند همکاری کند یا تغییرات نسخه‌بندی‌شدهٔ خود را ثبت کند. و اگر دیسکِ میزبانِ پایگاه‌دادهٔ مرکزی خراب شود و نسخهٔ پشتیبان مناسبی وجود نداشته باشد، عملاً همه‌چیز از دست می‌رود — کل تاریخچهٔ پروژه، به‌جز نسخه‌های پراکنده‌ای که شاید روی سیستم‌های محلی افراد باقی مانده باشد. سیستم‌های محلی نیز دقیقاً از همین ضعف رنج می‌برند: هر جا کل تاریخچهٔ پروژه در یک نقطه متمرکز باشد، خطر از دست رفتن کامل آن وجود دارد.

وابستگی به شبکه فقط مسئلهٔ خرابی سرور نیست؛ در این مدل تقریباً هر عملیات معناداری به رفت‌وبرگشت با سرور نیاز دارد. دیدن تاریخچهٔ یک فایل، مقایسهٔ وضعیت فعلی با یک بازبینی قدیمی، یا ثبت یک تغییر — همه در گرو در دسترس بودن سرور و کیفیت اتصال شبکه‌اند. همین موضوع باعث می‌شد کامیت‌ها بزرگ و کم‌تعداد شوند: وقتی هر ثبت هزینهٔ زمانی دارد و بلافاصله دیگران را تحت تأثیر قرار می‌دهد، توسعه‌دهنده ترجیح می‌دهد تغییرات را روی هم انباشته کند و یک‌جا بفرستد.

اینجاست که «سیستم‌های کنترل نسخه توزیع‌شده» (Distributed Version Control Systems یا DVCS) وارد می‌شوند. در یک DVCS — مانند Git، Mercurial یا Darcs — کلاینت‌ها تنها آخرین نسخهٔ فایل‌ها را دریافت نمی‌کنند، بلکه کل مخزن را همراه با تمام تاریخچه‌اش به‌طور کامل کپی می‌کنند. بنابراین اگر سروری که تیم از طریق آن همکاری می‌کرد از بین برود، می‌توان مخزن را از روی کپی هر یک از اعضا بازیابی کرد. به بیان دیگر، هر clone خودش یک نسخهٔ پشتیبان کامل از تمام داده‌هاست.

نکتهٔ تاریخی جالب اینکه دو نمایندهٔ شاخص این نسل، یعنی Git و Mercurial، هر دو در آوریل ۲۰۰۵ و در واکنش به یک رویداد مشترک متولد شدند: پایان یافتن دسترسی رایگان جامعهٔ کرنل لینوکس به ابزار BitKeeper. لینوس توروالدز کار روی Git را در همان ماه آغاز کرد و مت مکال (Matt Mackall) نیز چند روز بعد Mercurial را معرفی کرد. داستان کامل این ماجرا را در بخش بعدی (در آینده اضافه خواهد شد) خواهید خواند.

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

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

مزیت‌های عملی این معماری فراتر از «پشتیبان‌گیری» است و در کار روزمره خود را نشان می‌دهد:

در مقابل، این معماری هزینه‌هایی هم دارد که کمتر دربارهٔ آن‌ها صحبت می‌شود و بهتر است از همان ابتدا بشناسیدشان:

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

این معماری امروز به الگوی غالب توسعهٔ نرم‌افزار تبدیل شده است؛ برای نمونه، در نظرسنجی سالانهٔ توسعه‌دهندگان Stack Overflow در سال ۲۰۲۲ بیش از ۹۳ درصد پاسخ‌دهندگان اعلام کردند که از Git به‌عنوان سیستم کنترل نسخهٔ خود استفاده می‌کنند. با این حال، همان‌طور که دیدید، هیچ نسلی جانشین کامل نسل پیش از خود نشد: سیستم‌های متمرکز هنوز در حوزه‌هایی که دارایی‌های باینری بزرگ و کنترل دسترسی ریزدانه حرف اول را می‌زنند جای خود را دارند، و RCS هنوز برای نسخه‌بندی یک فایل تنها روی یک ماشین ابزار کاملاً معقولی است. آنچه Git را به انتخاب پیش‌فرض تبدیل کرد، ترکیب کار آفلاین، شاخه‌بندی ارزان و مدل همکاری بدون نیاز به مجوز مرکزی بود.