یوشا

برنامه Git برای کار با repository، پنج پروتکل در اختیار ما گذاشته که هرکدوم مزایا و معایب خودشونو دارن... این پروتکل ها:

1- File (یا همون Local protocol)

2- HTTP (یا همون Dumb protocol)

3- HTTPS (یا همون Smart protocol)

4- SSh

5- Git

هستن. اما از کدوم پروتکل باید استفاده کنیم؟ کدوم پروتکل امنیت بیشتری داره؟ و کدوم پروتکل سرعت بیشتری داره؟

File://

این پروتکل برای کار با repository های داخل هارد(local) طراحی شده و ما در اینجا کاری بهش نداریم.

HTTP://

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

HTTPS://

• در حال حاضر، ساده ترین، محبوب ترین و سازگارترین(compatible) پروتکل استفاده از Git هستش.
• هم قابلیت Read-only داره و هم Writable هه.
• سرعتش برای انتقال اطلاعات نرماله.
• سرور بصورت خودکار توسط certificate تایید می شه.
• hand-shake بین کلاینت و سرور در 2-3 پروسه انجام میشه.
• توسط X.509 certificate اطلاعات رو رمزنگاری می کنه.
• نیاز به SSh Keys و آپلود Public Key در سرور نداره، پس از هر مکانی و سیستمی قابل استفادست. (web-based)
• از Pr@xi پشتیبانی می کنه.
• معمولاً در پورت 443 تنظیم میشه و توسط Firewall مسدود نشده.
• گزینه مناسب برای repository های عمومی و خصوصی با ترافیک متوسط.
• احراز هویت(authentication) توسط username و password حساب کاربر در سرور انجام میشه.
• در صورت دزدیده شدن username و password، کل حساب کاربری در سرور از دست خواهد رفت.
• اکثر سرورهای HTTPS اجازه pull و clone کردن بصورت anonymous رو میدن.
• بیشتر فرایند های امنیتی در مرورگر/وب انجام میشه و نه در Git.
• دستورات و عملیات بصورت POST/GET ارسال و دریافت میشن.
• بدون تنظیم credential-caching در کلاینت، کاربر برای push کردن باید هربار احراز هویت کنه. (clone و pull رو هم شامل میشه اگر دسترسیش محدود شده باشه)
• برای راه اندازی سرور Git، به برنامه Git، یک TLS certificate معتبر و Web server نیاز داره. بنابراین راه اندازی سرور HTTPS کمی زمانبر هستش.
• این پروتکل حدوداً در سال 1995 رونمایی شد.
• نمونه URL:

git clone https://domain/project.git

SSh://

• نسبت به HTTPS از سادگی، محبوبیت و سازگاری(compability) کمتری برخورداره. (چون حرفه ای تر و قدرتمند تره)
• هم قابلیت Read-only داره و هم Writable هه.
• سرعتش برای انتقال اطلاعات سریعتر از HTTPS هه.
• سرور با اجازه کاربر توسط Fingerprint کلید تایید می شه.
• hand-shake بین کلاینت و سرور در 5-6 پروسه انجام میشه.
• توسط AES, Blowfish, RC4, 3DES, CAST128 یا Arcfour اطلاعات رو رمزنگاری می کنه.
• نیاز به SSh Keys و آپلود Public Key در سرور داره، پس کاربر باید به SSh مجهز باشه.
• از Pr@xi پشتیبانی می کنه.
• معمولاً در پورت 9418 تنظیم میشه و گاهاً توسط Firewall مسدود شده. (در سرورهای درجه 2-3 یا دولتی)
• بهترین گزینه برای repository های خصوصی و حساس.
• احراز هویت(authentication) توسط Key ها انجام میشه. (حداکثر امنیت)
• در صورت دزدیده شدن Private Key، کافیست Public key از حساب کاربری در سرور حذف بشه.
• اکثر سرورهای SSh اجازه pull و clone کردن بصورت anonymous رو نمیدن.
• بیشتر فرایند های امنیتی در خود SSh و Git انجام میشه.
• دستورات و عملیات بصورت پارامتری ارسال و دریافت میشن.
  • ssh -x git@domain "git-receive-pack 'project.git'"
• کاربر برای push کردن کافیست فقط یکبار در کلاینتش احراز هویت کنه. (clone و pull رو هم شامل میشه)
• برای راه اندازی سرور Git، به برنامه Git، و SSh نیاز داره.
• این پروتکل حدوداً در سال 1995 رونمایی شد.
• نمونه URL:

git clone ssh://username@domain/project.git

یا

git clone username@domain:project.git

Git://

• نسبت به SSh از سادگی، محبوبیت و سازگاری(compability) بیشتری برخورداره.
• در حالت معمول فقط قابلیت Read-only داره.
• سرعتش برای انتقال اطلاعات بسیار سریعتر از HTTPS و SSh هه.
• هیچ مکانیزمی برای تایید سرور نداره.
• تقریباً هیچ hand-shake ای بین کلاینت و سرور انجام نمیشه.
• هیچ مکانیزم رمزنگاری درکار نیست.
• نیاز به SSh Keys و آپلود Public Key در سرور نداره، فقط به برنامه Git نیاز داره.
• از Pr@xi پشتیبانی می کنه.
• معمولاً در پورت 9418 تنظیم میشه و گاهاً توسط Firewall مسدود شده. (در سرورهای درجه 2-3 و دولتی)
• بهترین گزینه برای repository های عمومی Read-only با ترافیک بالا یا پروژه های سنگین.
• هیچ احراز هویت(authentication) ای انجام نمیشه. (حداقل امنیت)
• هیج گونه اطلاعات حساسی برای دزدیده شدن وجود نداره.
• همه سرورهای Git اجازه pull و clone کردن بصورت anonymous رو میدن.
• هیچ فرایند امنیتی انجام نمیشه.
• دستورات و عملیات بصورت پارامتری ارسال و دریافت میشن.
  • git domain "git-receive-pack 'project.git'"
• در حالت معمول امکان write/push کردن وجود نداره.
• برای راه اندازی سرور Git فقط به Git نیاز داره.
• این پروتکل حدوداً در سال 2005 رونمایی شد.
• نمونه URL:

git clone git://domain/project.git

توجه: شما خودتون هم میتونید دسترسی Read-Only یا Writable به هر پروتوکلی که خواستید بدید.

این نکته رو هم در نظر داشته باشید که هرکدوم مزایا و معایب خودشونو دارن و باید درجای مناسبش پروتکل مناسب رو انتخاب کنید.

این مقاله جامع ترین و کامترین در نوع خودشه، حتی در بین مقالات خارجی.