۳ جایگزین عالی Git: فسیل، مرکوریال و برانداز

Git تنها سیستم کنترل نسخه منبع باز نیست. در اینجا چیزی است که شما باید در مورد سه تا از بزرگترین رقبای آن بدانید.

• فسیل
• Mercurial
• براندازی
• نتیجه‌گیری

Git به‌عنوان نرم‌افزار کنترل نسخه شروع به کار کرد که برای مدیریت کد منبع هسته لینوکس توسعه یافته است. از آن زمان این ابزار به ابزار پیش‌فرض و پیش‌فرض برای مدیریت پایگاه‌های کد منبع تقریباً برای هر پروژه منبع باز و بسیاری از پروژه‌های منبع بسته تبدیل شده است.

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

اگر هر یک از این مشکلات شما را آزار می دهد، ممکن است در مورد جایگزین های ممکن برای Git کنجکاو باشید. آنها وجود دارند و بسیاری از آنها در فضاهای خود پیشرفت می کنند زیرا ویژگی هایی را ارائه می دهند که Git ندارد. در این مقاله، سه مورد از بزرگترین جایگزین های Git را بررسی خواهیم کرد: فسیل، مرکوریال و سابورشن. ما ویژگی‌ها و موارد استفاده و پروژه‌هایی که در حال حاضر در آنها استفاده می‌شوند را پوشش می‌دهیم.

فسیل

D. ریچارد هیپ بیشتر به عنوان خالق SQLite شناخته می شود، سیستم پایگاه داده منبع باز جاسازی شده که یکی از پرکاربردترین نرم افزارها در جهان است. اما Hipp از Git برای کنترل منبع در پروژه SQLite استفاده نمی کند. در عوض، او از Fossil استفاده می‌کند، یک سیستم کنترل منبع که به طور خاص برای کمک به توسعه SQLite ایجاد کرده است.

بزرگترین تفاوت فسیل با Git این است که یک محصول همه کاره است. Git فقط از طریق یک فایل سیستم مجازی، تغییرات را در یک پایگاه کد ردیابی و حاشیه نویسی می کند. فسیل بیشتر به چیزی شبیه Bitbucket شباهت دارد – این یک سیستم خود میزبانی است که نه تنها تغییرات را ردیابی می کند، بلکه بلیط و ردیابی اشکال، ویکی ها، مستندات و بحث زنده را برای یک پروژه یکپارچه می کند. همه اینها توسط پایگاه داده SQLite پشتیبانی می شود و (مانند خود SQLite) از یک فایل اجرایی مستقل و با حجم تقریباً ۸ مگابایت اجرا می شود.

Fossil از ساختار داده ای مشابه با Git استفاده می کند، اما جایی که Git از خود سیستم فایل برای ذخیره تغییرات استفاده می کند، Fossil همه چیز را در یک پایگاه داده SQLite نگه می دارد. سوالات مربوط به تغییرات، مانند بررسی تمام تغییرات یک فایل معین در طول زمان، یا نمودارهای دقیق در مورد پیشرفت پروژه را می توان به سرعت محاسبه کرد، زیرا آنها به پرس و جوهای SQL می رسند.

تفاوت‌های طراحی و رفتاری در فسیل، به گفته هیپ، آن را برای تیم‌های کوچک‌تر و صمیمی‌تر، مانند تیم‌هایی که روی SQLite و خود فسیل کار می‌کنند، مناسب‌تر می‌سازد. فسیل همچنان می تواند به صورت غیرمتمرکز کار کند، اما اکثر تغییرات از راه دور به طور خودکار با یک مخزن اصلی همگام سازی می شوند، به جای اینکه به طور جداگانه در طول زمان توسعه داده شوند و سپس با هم تطبیق داده شوند (آنچه که هیپ آن را فلسفه “همگام سازی بر روی فشار” می نامد). پروژه Tcl/Tk مانند چند پروژه دیگر مرتبط با Tcl از فسیل استفاده می کند.

Hipp یادداشت های دقیقی در مورد حرکت بین Git و Fossil یا همگام سازی یک پروژه بین هر دو سیستم ارائه می دهد. توجه داشته باشید که ویژگی‌های فسیلی مانند ویکی پروژه، حداقل به صورت خودکار به Git منتقل نمی‌شوند.

مرکوریال

در سال ۲۰۰۵، سیستم کنترل منبع اختصاصی BitKeeper مجوز رایگان خود را برای هسته لینوکس لغو کرد. دو جایگزین پس از BitKeeper ظهور کردند. یکی از آنها Git بود که برای هسته لینوکس (و بعدها، بسیاری چیزهای دیگر) استفاده شد. مورد دیگر Mercurial بود که در نهایت توسط پروژه هسته لینوکس مورد استفاده قرار نگرفت، اما هنوز توسط توسعه دهندگانی که در فیس بوک، موزیلا، W3C و پروژه PyPy کار می کنند، استفاده می شود.

از نظر مفهومی، Mercurial و Git به یک شکل کار می کنند. هر دو از نموداری از تغییرات ایجاد شده در یک پایگاه کد استفاده می کنند و هر تغییری می تواند فرزندان زیادی داشته باشد. اما مجموعه دستورات اصلی Mercurial برای موارد استفاده رایج کوچک‌تر است و تسلط بر آن آسان‌تر است – در مقایسه با استفاده از دوجین به علاوه یک در اکثر سناریوهای Git، شش یا هفت دستور است.

یک تفاوت کلیدی با Git نحوه عملکرد شاخه ها در درخت منبع است. وقتی شاخه‌ها را در Git تغییر می‌دهید، دایرکتوری فعلی شما بازنویسی می‌شود تا محتویات شاخه را منعکس کند. در Mercurial، چند استراتژی مختلف برای انشعاب وجود دارد:

• می‌توانید مخزن را در فهرستی دیگر شبیه‌سازی کنید و روی آن به‌عنوان یک شاخه کار کنید (تغییر شاخه‌ها آسان است اما ساخت آن‌ها کند است).
• می‌توانید نقاط مختلفی را در یک مجموعه تغییرات نشانک‌گذاری کنید و از آنها به‌عنوان پایه‌ای برای تغییرات استفاده کنید، که بسیار شبیه رفتار خود Git است.
• می‌توانید از یک «شاخه نام‌دار» استفاده کنید، که در آن نام به‌عنوان بخشی دائمی از مجموعه تغییرات ایجاد می‌شود – از این نظر مفید است که نام در هر تغییر بعدی به آن شاخه منعکس می‌شود، اما می‌تواند درهم‌تنیدگی ایجاد کند.
• شما می‌توانید شاخه‌های ناشناس و بدون نام ایجاد کنید، که برای تغییرات سریع مناسب هستند، اما اگر به درستی در یادداشت‌های تغییر خود توضیح ندهید، می‌توانند گیج‌کننده شوند.

اگر می‌خواهید نحوه رفتار Git را تغییر دهید، معمولاً از سایر برنامه‌های مستقل استفاده می‌کنید، مطابق با فلسفه زنجیره ابزار لینوکس “هر برنامه یک کار را انجام می‌دهد”. در مقابل، Mercurial یک مکانیسم توسعه ارائه می دهد، به طوری که کدهای شخص ثالث را می توان مستقیماً در Mercurial ادغام کرد و عملکرد آن را گسترش داد. Mercurial همراه با انبوهی از برنامه‌های افزودنی ارائه می‌شود که همه چیز را از مقایسه تغییرات با ابزارهای خارجی تا پاک کردن همه چیز را ممکن می‌سازد. در یک دایرکتوری مشخص که به طور فعال توسط Mercurial تغییر نکرده است. شاید مفیدترین ویژگی ظاهری، توانایی همگام سازی یک مخزن Mercurial با یک مخزن Git باشد، که اگر در حال انتقال یک پایگاه کد از یکی به دیگری هستید، عالی است.

براندازی

پروژه براندازی بنیاد آپاچی – همچنین به نام SVN شناخته می شود – در ابتدا در سال ۲۰۰۰ ظهور کرد. نسخه اولیه ۱.۰ آن در سال ۲۰۰۴، کمی قبل از Git بود. Apache، FreeBSD و SourceForge برخی از شناخته شده ترین کاربران Subversion هستند. پروژه GCC تا سال ۲۰۱۹ از آن استفاده می کرد اما از آن زمان به Git مهاجرت کرده است.

تفاوت اصلی SVN با Git این است که متمرکز است، به این معنی که مخزن در یک مکان ثابت و واحد ذخیره می شود. مشارکت‌کنندگان معمولاً کپی‌های محلی از پایگاه کد نمی‌سازند، اما روی شاخه‌های کد در کپی متمرکز کار می‌کنند. یک سرپرست می‌تواند کنترل‌های دسترسی بسیار دقیق را در مخزن Subversion تنظیم کند، بنابراین نیازی نیست مشارکت‌ها به صورت دستی مرتب شوند.

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

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

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

خود GitHub برای مدتی از مخازن Subversion پشتیبانی می‌کرد، اما از ژانویه ۲۰۲۴ به تدریج پشتیبانی را متوقف می‌کند. (GitLab و Bitbucket از مخازن Subversion پشتیبانی نمی‌کنند؛ برای استفاده از آنها، باید یک مخزن را به صورت دستی به Git تبدیل کنید.)

نتیجه گیری

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