گیت میتواند از چهار پروتکل متفاوت برای جابهجایی دادهها استفاده کند: محلی، HTTP، شل ایمن (SSH) و گیت. در اینجا درباره اینکه این پروتکلها چه هستند و اینکه در کدام یک از موقعیتهای پایه ممکن است بخواهید از آنها استفاده کنید یا نکنید بحث خواهیم کرد.
ابتداییترین پروتکل، پروتکل محلی است، که در آن مخزن ریموت در پوشهای دیگر در همان میزبان قرار دارد. اکثراً از این پروتکل اگر شخصی در تیم شما به یک فایل سیستم مونت شده دسترسی دارد استفاده میشود یا بعضی وقتا که افراد این پروتکل غالباً زمانی استفاده میشود که همه افراد تیم شما به یک فایلسیستم اشتراکی مثلا یک NFS مونت شده دسترسی دارند، یا در موقعیت کمتر رایجی که در آن همه به یک کامپیوتر وارد میشوند. موقعیت دوم زیاد ایدهآل نخواهد بود، چون از آنجایی که تمام نمونههای مخزن کد شما در یک کامپیوتر قرار میگیرند، احتمال تخریبهای فاجعهبار را خیلی بیشتر میکنند.
اگه یک فایل سیستم مونت شده اشتراکی دارید، پس میتوانید از یک مخزن فایل-پایهٔ محلی کلون، پوش و پول کنید. برای کلون کردن چنین مخزنی، یا اضافه کردن آن به عنوان ریموت به یک پروژه موجود، از مسیر مخزن به عنوان URL استفاده کنید. برای مثال، برای کلون کردن یک مخزن محلی میتوانید چنین دستوری را اجرا کنید:
$ git clone /srv/git/project.gitیا میتوانید این کار را کنید:
$ git clone file:///srv/git/project.gitاگر در شروع URL صراحتاً file:// را مشخص کنید، گیت کمی متفاوت عمل میکند.
اگر فقط مسیر را مشخص کنید، گیت سعی میکند از لینکهای سخت استفاده کند یا مستقیماً فایلهایی را که نیاز دارد کپی کند.
اگر file:// را در مشخص کنید، گیت فرآیندهایی را اجرا میکند که معمولاً برای انتقال داده از شبکه استفاده میکند، که عموماً بسیار کم کارآمدتر هستند.
دلیل اصلی ارائه پیشوند file:// برای وقتی است که شما یک کپی تمیز از مخزن با رفرنسهای خارجی یا آبجکتهای حذف شده میخواهید — معمولاً هنگام ایمپورت کردن از یک VCS دیگر یا حالتی مشابه (برای مراحل نگهداری به ch10-git-internals.asc مراجعه کنید).
ما از آدرس مسیر معمولی در اینجا استفاده خواهیم کرد چون این کار تقریباً همیشه سریعتر است.
برای اضافه کردن یک مخزن محلی به یک پروژه گیت موجود، میتوانید از چنین دستوری استفاده کنید:
$ git remote add local_proj /srv/git/project.gitسپس، میتوانید با نام جدید مخزن local_proj، درست مانند اینکه روی یک شبکه این کار را میکردید، به آن مخزن پوش و از آن پول کنید.
مزایای مخزنهای مبتنی بر فایل این است که ساده هستند و اینکه از مجوزهای فایل موجود و دسترسی شبکه استفاده میکنند. اگر شما از قبل یک فایلسیستم اشتراکگذاری شده دارید که همهٔ تیم به آن دسترسی دارند، راهاندازی یک مخزن بسیار آسان است. شما نسخه بِر مخزن را جایی که همه دسترسی اشتراکی به آن را دارند میگذارید و مجوزهای خواندن/نوشتن را همانطور که روی هر پوشه اشتراکی دیگری تنظیم میکردید، تنظیم میکنید. درباره نحوه صادر کردن یک نسخه بر مخزن برای این کار در ch04-git-on-the-server.asc بحث خواهیم کرد.
همچنین این یک گزینه قشنگ برای برداشتن سریع کار از مخزن کاری شخص دیگری است.
اگر شما و همکارتان در حال کار بر روی یک پروژه هستید و او از شما میخواهد که چیزی را بررسی کنید، اجرای دستوری
مثل git pull /home/john/project اغلب خیلی راحتتر از این است که او به یک سرور ریموت پوش کند و متعاقباً شما از آن فچ کنید.
از معایب این متد این است که دسترسی اشتراکی به طور کلی از نظر راهاندازی و دسترسی از چندین موقعیت دشوارتر از دسترسی ساده شبکه است. اگر بخواهید از زمانی که خانه هستید از لپتاپتان پوش کنید، باید دیسک ریموت را مونت کنید که میتواند در مقایسه با دسترسی برمبنای شبکه سخت و کند باشد.
لازم به ذکر است که اگر در حال استفاده از مونت اشتراکگذاری شده خاصی هستید، این لزوماً سریعترین گزینه نیست. یک مخزن محلی تنها زمانی سریع است که دسترسی سریع به داده آن داشته باشید. یک مخزن بر روی NFS گاهاً کندتر از یک مخزن بر روی همان سرور اما به واسطه SSH است، که به گیت اجازه میدهد تا اطلاعات را به دیسکهای محلی هر سیستم منتقل کند.
در نهایت، این پروتکل از مخزن در برابر آسیب تصادفی محافظت نخواهد کرد. هر کابری دسترسی شل کامل به پوشه «ریموت» دارد و هیچ چیز جلوگیری آنها را نمیگیرد که فایلهای داخلی گیت را پاک نکنند یا تغییر ندهند و به مخزن آسیب نزنند.
گیت میتواند از طریق HTTP با استفاده از دو حالت متفاوت ارتباط برقرار کند. پیش از گیت ۱.۶.۶، فقط یک راه وجود داشت که این کار را انجام میداد که بسیار ساده و به طور کلی فقط-خواندنی بود. در نسخه ۱.۶.۶، پروتکل جدید و هوشمندتری معرفی شد که گیت را قادر میساخت تا هوشمندانه بر سر انتقال اطلاعات مذاکره کند همانند کاری SSH انجام میدهد. در چند سال اخیر، این نوع جدید از پروتکل HTTP از آنجایی که برای کاربر سادهتر است و نحوه ارتباطاتش هوشمندتر شده است، بسیار محبوب شده اس. نسخه جدیدتر را معمولاً پروتکل HTTP «هوشمند» و نسخه قدیمیتر را HTTP «غیرهوشمند» مینامند. ما اول درباره پروتکل جدیدتر میگوییم.
پروتکل HTTP هوشمند بسیار شبیه به SSH یا پروتکلهای گیت عمل میکند منتهی بر بستر استاندارد درگاههای HTTPS اجرا میشود و میتواند از مکانیزمهای گوناگون تصدیق هویت HTTP استفاده کند، به این معنا که معمولاً برای کاربر از چیزی مثل SSH راحتتر است، چراکه شما میتوانید از چیزهایی مانند نام کاربری/رمزعبور برای تصدیق هویت استفاده کنید جای اینکه اجباراً کلیدهای SSH را راهاندازی کنید.
احتمالاً در حال حاضر این محبوبترین راه برای استفاده از گیت است، از آنجا که میتواند تنظیم شود تا هم به طور ناشناس خدمت کند، مانند پروتکل git://
و همچنین میتواند تنظیم شود تا همراه تصدیق هویت و رمزگذاری مانند پروتکل SSH کار کند.
به جای اینکه مجبور باشید چندین URL متفاوت برای چنین چیزهایی راهاندازی کنید، حال میتوانید از یک URL برای هر دو استفاده کنید.
اگر سعی در پوش کردن به مخزن دارید و تصدیق هویت ضروری باشد (که معمولاً هست)، سرور میتواند از شما نام کاربری و رمزعبور درخواست کند.
همین روند نیز برای دسترسی خواندن وجود دارد.
در واقع، برای سرویسهای مانند گیتهاب، URL که شما برای نمایش آنلاین مخزن خود استفاده میکنید (برای مثال، https://github.com/schacon/simplegit) همان URL است که میتوانید برای کلون کردن، و در صورت داشتن دسترسی، پوش کردن استفاده کنید.
اگر سرور با پروتکل HTTP هوشمند پاسخ ندهد، کلاینت گیت تلاش میکند تا به پروتکل سادهتر HTTP غیرهوشمند (Dumb) بازگردد.
پروتکل غیرهوشمند انتظار دارد که مخزن بِر گیت مانند فایلهای معمولی از طرف وب سرور میزبانی شود.
قشنگی HTTP غیرهوشمند سادگی راهاندازی آن است.
در اصل، تمام کاری که شما باید انجام دهید این است که مخزن بِر گیت را زیر HTTP داکیومنت-روت قرار دهید و قلاب مشخصی برای post-update («بعد از بروزرسانی»)
راهاندازی کنید و تمام (به ch08-customizing-git.asc مراجعه کنید).
$ 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/htodcs استفاده میکنیم که مرسوم سیستمهای آپاچی است، اما شما میتواند از هر وب سرور ایستای دیگری استفاده کنید — کافیست مخزن بِر را در مسیر آن قرار دهید.
دادههای گیت به عنوان فایلهای ایستای معمولی میزبانی میشوند (برای جزئیات دقیق نحوهٔ میزبانی شدن به ch10-git-internals.asc مراجعه کنید).
عموماً یا مجبور خواهید شد که یک سرور خواندنی/نوشتنی هوشمند HTTP راهاندازی کنید یا صرفاً فایلها را با دسترسی فقط-خواندنی به روش غیرهوشمند فراهم کنید. استفاده از ترکیب این دو سرویس نادر است.
ما تمرکزمان را بر روی مزایای نسخه هوشمند پروتکل HTTP خواهیم گذاشت.
سادگی داشتن فقط یک URL برای انواع دسترسیها و داشتن اعلان سرور فقط در زمانی نیاز به که تصدیق هویت، همه چیز را برای کاربر نهایی بسیار ساده میکند. قابلیت تصدیق هویت با نام کاربری و رمزعبور بر بستر SSH یک مزیت بزرگ است، چرا که کاربران نیاز به ساخت محلی کلیدهای SSH به صورت محلی و آپلود کلید عمومی خود به روی سرور پیش از اجازه گرفتن برای برقراری تعامل با آن ندارند. برای کاربرانی که در سطح پایینتری هستند یا کاربران سیستمهایی که SSH روی آنها کمتر متداول است، این مزیت اصلی در استفادهپذیری است. همچنین پروتکلی بسیار سریع و کارآمد همانند پروتکل SSH است.
همچنین میتوانید مخزنهای فقط-خواندنی خود را بر بستر HTTPS نیز میزبانی کنید که به این معنا است که شما میتوانید انتقال محتوا را رمزگذاری کنید؛ یا میتوانید اجبار کلاینتها به استفاده از یک گواهی SSL امضا شده خاص پیش روید.
نکته قشنگ دیگر این است که هر دو پروتکل HTTP و HTTPS پروتکلهایی آنچنان پر استفاده هستند که فایروالهای شرکتی اغلب به نحوی راهاندازی میشوند تا اجازه عبور و مرور از طریق پروتکلها را مجاز بدانند.
ممکن است بر روی بعضی از سرورها، راهاندازی گیت بر بستر HTTPS به مهارت بیشتری در مقایسه با SSH احتیاج داشته باشد. سوای این مورد، مزیتهای خیلی کمی در دیگر پروتکلها در مقایسه با HTTP هوشمند برای میزبانی محتوای گیت است.
اگر از HTTP برای پوش احراز هویت شده استفاده میکنید، تهیه گواهیهایتان گاهی اوقات پیچیدهتر از استفاده از کلیدها بر بستر SSH است. با این حال چندین ابزار ذخیرهساز گواهی وجود دارد که میتوانید استفاده کنید که شامل «Keychain access» در سیستمعامل مک و «Credential Manager» در ویندوز است که این مشکل را آسانتر کند. بخش ch07-git-tools.asc را مطالعه کنید تا چگونگی راهاندازی ذخیرهسازی امن رمزعبور بر بستر HTTP بر روی سیستم خودتان را بدانید.
یک پروتکل رایج انتقال برای گیت به هنگام خودمیزبانی، بر بستر SSH است. این به این خاطر است که دسترسی SSH به سرورها در اکثر جاها از قبل راهاندازی شده است — و اگر نشده باشند، راهاندازی آن کار راحتی است. همچنین SSH یک پروتکل شبکه تصدیق هویت شده است و چون در همه جا هست، به طور کلی راهاندازی و استفاده از آن آسان است.
برای کلون کردن یک مخزن بر بستر SSH، میتوانید یک آدرس ssh:// مانند این مشخص کنید:
$ git clone ssh://[user@]server/project.gitیا میتوانید از نگارش علامت گونه («spc-like») کوتاهتر برای پروتکل SSH استفاده کنید:
$ git clone [user@]server:project.gitدر هر دو مورد بالا، اگر نام کاربری اختیاری را تعیین نکنید، گیت نام کاربری را، نام کاربری که در حال حاضر با آن ورود کردهاید پیشفرض میگیرد.
مزایای استفاده از پروتکل SSH بسیار زیاد است. اول، SSH نسبتاً راهاندازی سادهای دارد — دیمنهای SSH پیش افتاده هستند، خیلی از مدیریان شبکه تجربه کار با آنها را دارند و خیلی از توزیعهای سیستمعاملها همراه آنها راهاندازی میشوند یا ابزارهایی برای مدیریت آنها دارند. سپس اینکه، دسترسی بر بستر SSH امن است — کل انتقال دادهها رمزگذاری شده و تصدیق هویت شده است. در آخر، مانند HTTPS، گیت و پروتکلهای محلی، SSH نیز کارآمد است، قبل از ارسال اطلاعات تا جایی که ممکن است دادهها را فشرده میکند.
وجه منفی پروتکل SSH این است که از دسترسی ناشناس به مخزن گیت شما پشتیبانی نمیکند. اگر از SSH استفاده میکنید، افراد باید دسترسی SSH به سیستم شما داشته باشند، حتی در حد فقط-خواندن؛ این باعث میشود که SSH برای پروژههای متن باز که شاید افراد بخواهند صرفاً مخزن شما را کلون کرده و آن را بررسی کنند مناسب نباشد. اگر از SSH فقط در شبکه شرکتی استفاده میکنید، شاید SSH تنها پروتکلی باشد که لازم باشد با آن سروکار داشته باشد. اگر میخواهید دسترسی ناشناس فقط-خواندن به پروژههای خود بدهید و همچنان از SSH هم استفاده کنید، ملزم خواهید بود که SSH را برای پوش کردن خودتان، اما برای دیگران چیز دیگری راهاندازی کنید تا از آن فچ کنند.
در آخر، پروتکل گیت را داریم.
این پروتکل یک دیمون خاص است که همراه گیت میآید؛ به یک پورت اختصاصی (۹۴۱۸) گوش میکند که یک سرویس شبیه به پروتکل SSH، اما بدون هیچ تصدیق هویتی، ارائه میکند.
پیش از اینکه یک مخزن برای بر بستر پروتکل گیت میزبانی شود، شما باید یک فایل git-daemon-export-ok بسازید — که دیمن مخزنی را که این فایل را ندارد میزبانی نمیکند — هرچند به جز آن، هیچ ضامن دیگری نیست.
یا مخزن گیت برای همه در دسترس است تا کلون کند یا نیست.
این بدین معناست که عموماً پوش کردن بر بستر این پروتکل وجود ندارد.
شما میتوانید دسترسی پوش را فعال کنید اما، با توجه به نبود تصدیق هویت، هر کسی در اینترنت که URL پروژه شما را پیدا کند میتواند به آن پروژه پوش کند.
خلاصه اینکه این حالتی نادر است.
پروتکل گیت اغلب سریعترین پروتکل موجود شبکه است. اگر حجم عظیمی از ترافیک را برای یک پروژه عمومی یا بزرگ که نیاز به تصدیق هویت کاربر برای دسترسی خواندن ندارد را میزبانی میکنید، احتمالاً که خواهید خواست که یک دیمون گیت را برای میزبانی پروژتان راهاندازی کنید. این از همان مکانیزم انتقال-اطلاعاتی که پروتکل SSH دارد استفاده میکند اما بدون رمزگذاری و تصدیق هویت.
نقطه ضعف پروتکل گیت نداشتن تصدیق هویت است.
اصلاً مطلوب نیست که پروتکل گیت تنها راه دسترسی به پروژه شما باشد.
عموماً، برای تعدادی از توسعه دهندگان یا برنامهنویسان که دسترسی پوش (نوشتن) دارند آن را با پروتکل SSH یا HTTPS همراه خواهید کرد و
برای بقیه با دسترسی فقط خواندنی از git://، استفاده خواهید کرد.
احتمالاً سختترین پروتکلها برای راهاندازی است.
باید روی دیمون خودش اجرا شود که نیازمند پیکربندی systemd و xinetd یا چیزی مشابه است که میتوان گفت همیشه به آسانی آب خوردن نیست.
همچنین نیازمند دسترسی فایروال به پورت ۹۴۱۸ است که چون یک پورت استاندارد نیست شاید فایروالهای شرکتی همیشه اجازه آنرا ندهند.
پشت فایروالهای بزرگ شرکتی غالباً پورتهای ناامن این چنینی را مسدود هستند.