راه اندازی سرور گیت خصوصی | به زبان ساده

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

چرا باید از سرور گیت شخصی استفاده کرد؟

علی‌رغم وجود نسخه‌های رایگانی از ارائه‌دهندگان میزبانی git مانند GitHub ،GitLab و Bitbucket شاید راه‌اندازی سرور گیت شخصی در نگاه نخست کار چندان معقولی به نظر نرسد، اما چند موقعیت وجود دارد که این کار مناسب خواهند بود.

فیلم آموزش گیت Git، گیت هاب و گیت لب (رایگان) + گواهینامه در فرادرس

کلیک کنید

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

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

از گیت برای هر موردی که استفاده کنید، احتمالاً می‌توانید خیلی بهتر از git خالی عمل کنید. گیت‌لب نسخه Community رایگان و اوپن سورس است و می‌توانید آن را به سادگی روی سرور شخصی خود راه‌اندازی کنید. به این ترتیب همه مزیت‌های این نوع میزبانی را به همراه یک اینترفیس وب زیبا و ابزارهای بی‌شمار CI/CD به دست می‌آورید. در صورتی که حافظه محدودی برای سرور ندارید قویاً پیشنهاد می‌کنیم از آن استفاده کنید. این سیستم در حدود 3 گیگابایت از رم را اشغال می‌کند. اما اگر به امکانات اضافی که این سیستم ارائه می‌دهد، نیازی ندارید و صرفاً یک گیت ریموت ساده می‌خواهید، می‌توانید در ادامه این راهنما با ما همراه باشید.

گیت ریموت صرفاً ریپازیتوری یک فرد دیگر است

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

شما می‌توانید گیت را از نظر فنی به صورت یک سرویس کاملاً نامتمرکز اجرا کنید. در این حالت اگر دو نفر در تیم وجود داشته باشند، هر کدام به‌روزرسانی‌ها را از دیگری pull می‌کنند. در این وضعیت push کردن به ریپازیتوری‌های غیر سرور توصیه نمی‌شود. با این حال این تنظیمات در عمل چندان قابل استفاده نیستند، مگر این که هر دو طرف دارای IP استاتیک و همیشه آنلاین باشند. از این رو اغلب افراد از مدل سرور-کلاینت استفاده می‌کنند.

با توجه به توضیحات فوق یک سرور گیت در واقع یک ریپازیتوری معمولی است که به عنوان یک کپی مستر پیکربندی شده و روی اینترنت قرار دارد. راه‌اندازی چنین سروری کار کاملاً آسانی است. ابتدا باید یک کاربر جدید ایجاد کنید. گیت از SSH برای احراز هویت استفاده می‌کند و همه ترافیک بین سرور‌ها و کلاینت‌ها با استفاده از آن رمزنگاری می‌شوند. بنابراین به یک کاربر سرویس برای مدیریت ریپو نیاز داریم.

sudo useradd git

سپس برای ادامه کار تنظیمات، باید به کاربر git سوئیچ کنیم:

su git

شما باید کلیدهای SSH خود را به فایل authorized_keys کاربر git اضافه کنید:

nano ~/.ssh/authorized_keys

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

در هر حال برای ایجاد یک ریپازیتوری واقعی کافی است دستور git init را در دایرکتوری home کاربر اجرا کنید:

git init --bare repository.git

گزینه ‎--bare در اینجا ضرورت دارد. به طور معمول زمانی که یک ریپازیتوری را کلون می‌کنید، git همه فایل‌هایی که استفاده می‌کند را ذخیره می‌سازد تا بتواند همه نسخه‌ها را در پوشه مخفی git. مدیریت کند. به این ترتیب یک نسخه قابل استفاده از هر چیزی که اینک به عنوان HEAD تعیین شده را ارائه می‌کند. این کار به طور معمول موجب می‌شود که پوشه ریپو دو برابر حجمی را داشته باشد که بدون گیت وجود داشت. هر چند اگر فایل‌های باینری بزرگی داشته باشید که در طی زمان شاهد تغییرهای زیادی باشند، ممکن است از این هم بزرگ‌‌تر شود.

یک ریپازیتوری bare در واقع یک ریپازیتوری بدون نسخه‌های قابل استفاده از فایل‌هایی است که در حال حاضر check-out شده‌اند. به جای آن پوشه ریپازیتوری صرفاً شامل محتوایی خواهد بود که باید در پوشه git. باشد. این امر موجب صرفه‌جویی در فضا می‌شود و ریپازیتوری را به عنوان یک سرور مستر پیکربندی می‌کند. از آنجا که هیچ محتوای لوکال وجود ندارد، هیچ تداخلی با HEAD برنچ نیز وجود نخواهد داشت. به طور معمول نام‌گذاری ریپازیتوری‌های bare با استفاده از پسوند فایل git. انجام می‌شود، اما الزام صریحی در این خصوص وجود ندارد.

این همه آن چیزی بود که در سمت سرور نیاز داشتید. در سمت ماشین لوکال باید ریپو را کلون کرده یا یک ریموت جدید اضافه کنید:

git remote add origin git@example.com:repository.git

URL با git@ آغاز می‌شود، زیرا به عنوان کاربر git روی SSH اتصال می‌یابد. در سمت دیگر repository.git: در عمل یک نام مسیر و نه یک شناسه است. مسیر در نسبت با دایرکتوری home کاربر git تعریف می‌شود، بنابراین اگر ریپو را جای دیگری قرار داده‌اید، باید به اینجا بیاورید و یا از نام مسیر کامل استفاده کنید.

پس از آن که به ریپوی لوکال وصل شدید، باید دسترسی کاملی برای push و pull به صورت معمول داشته باشید. به خاطر داشته باشید که git پیش‌فرض هیچ سیستم مجوزدهی درونی ندارد و از این رو هیچ مانعی برای دسترسی همه افراد به کاربر git و کسب کنترل کامل روی ریپازیتوری مستر وجود نخواهد داشت.