Chapters ▾ 2nd Edition

4.1 گیت روی سرور (Git on the server) - پروتکل‌ها (The Protocols)

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

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

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

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

پروتکل‌ها (The Protocols)

گیت می‌تواند از چهار پروتکل متفاوت برای انتقال داده استفاده کند: محلی، HTTP، شل امن (SSH) و Git. در اینجا توضیح می‌دهیم که هر کدام چه هستند و در چه شرایط پایه‌ای ممکن است بخواهید از آن‌ها استفاده کنید (یا نکنید).

پروتکل های محلی (Local Protocol)

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

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

$ git clone /srv/git/project.git

یا می‌توانید این کار را انجام دهید:

$ git clone file:///srv/git/project.git
 گیت کمی متفاوت عمل می‌کند اگر صراحتاً در ابتدای URL عبارت `file://` را مشخص کنید.
اگر فقط مسیر را مشخص کنید، گیت سعی می‌کند از هاردلینک‌ها استفاده کند یا فایل‌های مورد نیازش را مستقیماً کپی کند.
اگر `file://` را مشخص کنید، گیت فرآیندهایی را راه‌اندازی می‌کند که معمولاً برای انتقال داده‌ها از طریق شبکه به کار می‌برد، که معمولاً بسیار کمتر بهینه است.
دلیل اصلی استفاده از پیشوند `file://` این است که بخواهید یک نسخه تمیز از مخزن داشته باشید که ارجاعات یا اشیاء اضافی در آن حذف شده باشند — معمولاً پس از وارد کردن از یک سیستم کنترل نسخه دیگر یا چیزی مشابه (برای وظایف نگهداری به <<ch10-git-internals>> مراجعه کنید).
ما اینجا از مسیر معمولی استفاده می‌کنیم چون تقریباً همیشه سریع‌تر است.

برای افزودن یک مخزن محلی به یک پروژه گیت موجود، می‌توانید چیزی مانند زیر را اجرا کنید:

$ git remote add local_proj /srv/git/project.git

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

مزایا (The Pros)

مزیت مخازن مبتنی بر فایل این است که ساده هستند و از مجوزهای فایل و دسترسی شبکه موجود استفاده می‌کنند. اگر قبلاً یک سیستم فایل مشترک دارید که کل تیم شما به آن دسترسی دارد، راه‌اندازی مخزن بسیار آسان است. کپی مخزن bare را در جایی قرار می‌دهید که همه به صورت مشترک به آن دسترسی دارند و مجوزهای خواندن/نوشتن را مانند هر دایرکتوری مشترک دیگری تنظیم می‌کنید. ما درباره نحوه صادر کردن یک کپی bare از مخزن برای این منظور در راه‌اندازی گیت روی یک سرور (Getting Git on a Server) صحبت خواهیم کرد.

این گزینه همچنین برای گرفتن سریع کار از مخزن کاری شخص دیگری گزینه خوبی است. اگر شما و همکارانتان روی یک پروژه کار می‌کنید و آنها می‌خواهند شما چیزی را بررسی کنید، اجرای دستوری مانند git pull /home/john/project اغلب راحت‌تر از این است که آنها به یک سرور ریموت پوش کنند و سپس شما از آنجا fetch بگیرید.

معایب (The Cons)

معایب این روش این است که دسترسی مشترک معمولاً سخت‌تر از دسترسی شبکه‌ای ساده است و از چندین مکان قابل دسترسی نیست. اگر بخواهید از لپ‌تاپ خود در خانه پوش کنید، باید دیسک ریموت را مونت کنید، که در مقایسه با دسترسی مبتنی بر شبکه می‌تواند دشوار و کند باشد.

مهم است ذکر شود که این لزوماً سریع‌ترین گزینه نیست اگر از یک سیستم فایل مشترک استفاده می‌کنید. یک مخزن محلی تنها زمانی سریع است که دسترسی سریعی به داده‌ها داشته باشید. مخزنی که روی NFS است معمولاً کندتر از مخزنی است که روی همان سرور از طریق SSH اجرا می‌شود، چون گیت می‌تواند روی دیسک‌های محلی هر سیستم اجرا شود.

در نهایت، این پروتکل از مخزن در برابر آسیب‌های تصادفی محافظت نمی‌کند. هر کاربر دسترسی کامل شل به دایرکتوری “remote” دارد و هیچ چیزی مانع تغییر یا حذف فایل‌های داخلی گیت و خراب کردن مخزن نمی‌شود.

پروتکل‌های HTTP (The HTTP Protocols)

گیت می‌تواند از طریق HTTP با دو حالت مختلف ارتباط برقرار کند. قبل از گیت نسخه 1.6.6، فقط یک روش ساده و عمدتاً فقط خواندنی وجود داشت. در نسخه 1.6.6، یک پروتکل جدید و هوشمند معرفی شد که به گیت امکان می‌داد به‌طور هوشمندانه انتقال داده را به شکلی مشابه SSH مذاکره کند. در چند سال اخیر، این پروتکل HTTP جدید بسیار محبوب شده چون برای کاربر ساده‌تر و در نحوه ارتباط هوشمندانه‌تر است. نسخه جدید معمولاً به عنوان پروتکل HTTP هوشمند (Smart HTTP) و نسخه قدیمی به عنوان HTTP ساده (Dumb HTTP) شناخته می‌شود. ما ابتدا پروتکل HTTP هوشمند را بررسی خواهیم کرد.

HTTP هوشمند (Smart HTTP)

HTTP هوشمند بسیار شبیه به پروتکل‌های SSH یا Git عمل می‌کند اما روی پورت‌های استاندارد HTTPS اجرا می‌شود و می‌تواند از مکانیزم‌های مختلف احراز هویت HTTP استفاده کند، یعنی اغلب برای کاربر آسان‌تر از چیزی مثل SSH است، چون می‌توانید از احراز هویت نام‌کاربری/رمز عبور استفاده کنید و نیازی به تنظیم کلیدهای SSH نیست.

احتمالاً این محبوب‌ترین روش استفاده از گیت است چون می‌تواند به صورت ناشناس مانند پروتکل git:// سرویس دهد و همچنین می‌توان با احراز هویت و رمزنگاری مانند پروتکل SSH روی آن پوش کرد. به جای اینکه برای این کارها URLهای متفاوت تنظیم کنید، اکنون می‌توانید از یک URL واحد برای هر دو استفاده کنید. اگر هنگام پوش کردن مخزن نیاز به احراز هویت داشت (که معمولاً باید داشته باشد)، سرور می‌تواند درخواست نام‌کاربری و رمز عبور کند. دسترسی خواندنی هم همین‌طور است.

در واقع، برای سرویس‌هایی مانند GitHub، URLی که برای مشاهده مخزن به صورت آنلاین استفاده می‌کنید (مثلاً https://github.com/schacon/simplegit) همان URLی است که می‌توانید برای کلون کردن و در صورت دسترسی، پوش کردن استفاده کنید.

HTTP ساده (Dumb HTTP)

اگر سرور به سرویس HTTP هوشمند گیت پاسخ ندهد، کلاینت گیت تلاش می‌کند به پروتکل ساده‌تر Dumb HTTP بازگردد. پروتکل ساده انتظار دارد مخزن bare گیت مانند فایل‌های معمولی توسط وب سرور سرو شود. زیبایی HTTP ساده در سادگی راه‌اندازی آن است. در اصل، فقط کافی است یک مخزن bare گیت زیر دایرکتوری روت اسناد HTTP خود قرار دهید و یک هوک post-update خاص راه‌اندازی کنید، و تمام (برای اطلاعات بیشتر به هوک‌های Git (Git Hooks) مراجعه کنید). از این پس، هر کسی که بتواند به وب سروری که مخزن روی آن است دسترسی داشته باشد، می‌تواند مخزن شما را کلون کند. برای اجازه دادن به دسترسی خواندنی به مخزن خود از طریق HTTP، کاری شبیه به این انجام دهید:

$ cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
$ cd gitproject.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update

همین بود. هوک post-update که به‌طور پیش‌فرض همراه با گیت عرضه می‌شود، فرمان مناسب (git update-server-info) را اجرا می‌کند تا دریافت و کلون کردن از طریق HTTP به‌درستی انجام شود. این فرمان زمانی اجرا می‌شود که شما به این مخزن پوش کنید (شاید از طریق SSH)؛ سپس دیگران می‌توانند با استفاده از چیزی شبیه به این کلون کنند:

$ git clone https://example.com/gitproject.git

در این مورد خاص، ما از مسیر /var/www/htdocs استفاده می‌کنیم که برای تنظیمات آپاچی معمول است، اما می‌توانید از هر سرور وب استاتیکی استفاده کنید — فقط مخزن بَری را در مسیر آن قرار دهید. داده‌های گیت به‌صورت فایل‌های استاتیک ساده سرو می‌شوند (برای جزئیات بیشتر درباره اینکه دقیقاً چگونه سرو می‌شوند، فصل (Git Internals) را ببینید).

به‌طور کلی، یا باید یک سرور هوشمند HTTP با قابلیت خواندن/نوشتن اجرا کنید یا فقط فایل‌ها را به صورت فقط‌خواندنی و به روش ساده (Dumb) در دسترس قرار دهید. ترکیب این دو سرویس به‌ندرت انجام می‌شود.

مزایا (The Pros)

ما روی مزایای نسخه هوشمند پروتکل HTTP تمرکز خواهیم کرد.

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

شما همچنین می‌توانید مخازن خود را فقط‌خواندنی از طریق HTTPS ارائه دهید، که به معنی رمزنگاری انتقال محتواست؛ یا حتی می‌توانید به‌گونه‌ای پیش بروید که کلاینت‌ها از گواهی‌های SSL امضاشده خاص استفاده کنند.

یک نکته خوب دیگر این است که HTTP و HTTPS پروتکل‌هایی بسیار رایج هستند و اغلب دیواره‌های آتش شرکت‌ها به ترافیک این پورت‌ها اجازه عبور می‌دهند.

معایب (The Cons)

راه‌اندازی گیت روی HTTPS ممکن است نسبت به SSH روی برخی سرورها کمی پیچیده‌تر باشد. به‌جز این مورد، مزیت کمی نسبت به دیگر پروتکل‌ها برای ارائه محتوای گیت نسبت به HTTP هوشمند وجود دارد.

اگر از HTTP برای پوش کردن با احراز هویت استفاده می‌کنید، ارائه اطلاعات ورود گاهی پیچیده‌تر از استفاده از کلیدها روی SSH است. با این حال، چندین ابزار کش کردن اعتبارنامه وجود دارد، از جمله Keychain Access در macOS و Credential Manager در ویندوز، که این کار را به‌طور قابل توجهی ساده می‌کنند. برای یادگیری نحوه راه‌اندازی کش امن پسورد HTTP روی سیستم‌تان، فصل ذخیره‌سازی اطلاعات ورود (Credential Storage) را بخوانید.

پروتکل SSH (The SSH Protocol)

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

برای کلون کردن یک مخزن گیت از طریق SSH، می‌توانید یک URL با قالب ssh:// به این شکل مشخص کنید:

$ git clone ssh://[user@]server/project.git

یا می‌توانید از نحو کوتاه‌تر شبیه scp برای پروتکل SSH استفاده کنید:

$ git clone [user@]server:project.git

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

مزایا (The Pros)

مزایای استفاده از SSH بسیار زیاد است. اول اینکه SSH نسبتاً آسان راه‌اندازی می‌شود — سرویس‌دهنده‌های SSH رایج هستند، بسیاری از مدیران شبکه با آن‌ها آشنایی دارند و بیشتر توزیع‌های سیستم‌عامل با آن‌ها تنظیم شده‌اند یا ابزارهایی برای مدیریت‌شان دارند. دوم، دسترسی از طریق SSH امن است — تمام انتقال داده رمزنگاری و احراز هویت شده است. در نهایت، مثل پروتکل‌های HTTPS، گیت و Local، SSH نیز کارآمد است و داده‌ها را تا حد امکان فشرده قبل از انتقال می‌کند.

معایب (The Cons)

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

پروتکل Git (The Git Protocol)

در نهایت، پروتکل Git را داریم. این یک سرویس‌دهنده خاص است که همراه با گیت عرضه می‌شود؛ روی پورتی اختصاصی (9418) گوش می‌دهد که خدماتی مشابه پروتکل SSH ارائه می‌دهد، اما بدون هیچ‌گونه احراز هویت یا رمزنگاری. برای اینکه مخزنی از طریق پروتکل Git سرو شود، باید فایل git-daemon-export-ok را بسازید — این سرویس‌دهنده بدون وجود این فایل مخزن را سرو نمی‌کند — اما به جز این، هیچ امنیتی وجود ندارد. یا مخزن گیت برای همه در دسترس است، یا نیست. این به این معنی است که معمولاً پوش کردن از طریق این پروتکل انجام نمی‌شود. می‌توانید دسترسی پوش را فعال کنید اما با توجه به نبود احراز هویت، هر کسی در اینترنت که URL پروژه شما را پیدا کند می‌تواند به آن پروژه پوش کند. کافی است بگوییم این مورد نادر است.

مزایا (The Pros)

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

معایب (The Cons)

به دلیل نبود TLS یا رمزنگاری دیگر، کلون کردن از طریق git:// ممکن است باعث آسیب‌پذیری اجرای کد دلخواه شود، بنابراین مگر اینکه بدانید چه می‌کنید، باید از آن اجتناب کنید.

  • اگر دستور git clone git://example.com/project.git را اجرا کنید، یک مهاجم که کنترل مثلاً روتر شما را دارد می‌تواند مخزنی که تازه کلون کرده‌اید را دستکاری کند و کد مخربی در آن قرار دهد. اگر سپس کدی را که کلون کرده‌اید کامپایل یا اجرا کنید، کد مخرب اجرا خواهد شد. اجرای git clone http://example.com/project.git هم به همین دلیل باید اجتناب شود.

  • اجرای git clone https://example.com/project.git این مشکل را ندارد (مگر اینکه مهاجم بتواند گواهی TLS برای example.com ارائه دهد). اجرای git clone git@example.com:project.git تنها در صورتی دچار این مشکل می‌شود که اثر انگشت کلید SSH اشتباه را بپذیرید.

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

scroll-to-top