1.1 شروع به کار - دربارهٔ کنترل نسخه

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

برای حل این مشکل، سال‌ها قبل VCSهای محلی را توسعه دادند که پایگاه داده‌ای ساده داشت که تمام تغییرات فایل‌های تحت مراقبتش را نگهداری می‌کرد.

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

چالش بزرگ دیگری که مردم با آن روبرو می‌شوند نیاز به همکاری با توسعه‌دهندگانی است که با سیستم‌های دیگر کار می‌کنند. دربرخورد با این چالش سیستم‌های کنترل نسخه متمرکز (Centralized Version Control System (CVCS)) ایجاد شدند. این قبیل سیستم‌ها (مثل CVS، ساب‌ورژن و Preforce) یک سرور دارند که تمام فایل‌های نسخه‌بندی شده را در بر دارد و تعدادی کلاینت (Client/خدمت‌گیرنده) که فایل‌هایی را از آن سرور چک‌اوت (Checkout/وارسی) می‌کنند. سال‌های سال این روش استاندارد کنترل نسخه بوده است.

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

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

اینجا است که سیستم‌های کنترل نسخه توزیع‌شده (Distributed Version Control System (DVCS)) نمود پیدا می‌کنند. در یک DVCS (مانند گیت، Mercurial، Bazaar یا Darcs) کلاینت‌ها صرفاً به چک‌اوت کردن آخرین اسنپ‌شات فایل‌ها اکتفا نمی‌کنند؛ بلکه آن‌ها کل مخزن (Repository) را کپی عینی یا آینه (Mirror) می‌کنند که شامل تاریخچه کامل آن هم می‌شود. بنابراین اگر هر سروری که سیستم‌ها به واسطه آن در حال تعامل با یکدیگر هستند متوقف شده و از کار بیافتد، با کپی مخرن هر کدام از کاربران بر روی سرور، می‌توان آن را بازیابی کرد. در واقع هر کلون، پشتیبان کاملی از تمامی داده‌ها است.

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