'\" t .\" Title: gitprotocol-http .\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author] .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 2026-06-29 .\" Manual: Git Manual .\" Source: Git 2.55.0 .\" Language: Persian .\" .TH "GITPROTOCOL\-HTTP" "5" "2026\-06\-29" "Git 2\&.55\&.0" "Git Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "نام (NAME)" gitprotocol-http \- پروتکل‌های مبتنی بر HTTP در گیت .SH "خلاصه (SYNOPSIS)" .sp .nf .fi .sp .SH "توضیحات (DESCRIPTION)" .sp گیت از دو پروتکل انتقال مبتنی بر HTTP پشتیبانی می‌کند: یک پروتکل «ساده» (dumb) که در سمت سرور تنها به یک وب‌سرور استاندارد HTTP نیاز دارد، و یک پروتکل «هوشمند» (smart) که به یک ماژول سرور یا CGI آگاه به گیت نیازمند است\&. این سند هر دو پروتکل را شرح می‌دهد\&. .sp به عنوان یک ویژگی طراحی، کلاینت‌های هوشمند می‌توانند به طور خودکار نشانی‌های URL پروتکل «ساده» را به URLهای «هوشمند» ارتقا دهند\&. این کار به همه کاربران اجازه می‌دهد از یک نشانی URL منتشرشده یکسان استفاده کنند، و طرفین ارتباط (peers) به طور خودکار بهینه‌ترین روش انتقال در دسترس را انتخاب نمایند\&. .SH "قالب نشانی اینترنتی (URL FORMAT)" .sp نشانی‌های اینترنتی (URL) برای مخازن گیت که از طریق HTTP قابل دسترسی هستند از ساختار استاندارد HTTP URL مستندشده در RFC 1738 استفاده می‌کنند، بنابراین به فرم زیر هستند: .sp .if n \{\ .RS 4 .\} .nf http://:/? .fi .if n \{\ .RE .\} .sp در این مستند، عبارت جایگزین \fB$GIT_URL\fR نمایانگر نشانی مخزن http:// واردشده توسط کاربر نهایی خواهد بود\&. .sp سرورها باید تمام درخواست‌ها به مسیرهای منطبق با \fB$GIT_URL\fR را مدیریت کنند، زیرا هر دو پروتکل HTTP «هوشمند» و «ساده» مورد استفاده در گیت با افزودن اجزای مسیر اضافی به انتهای رشته \fB$GIT_URL\fR ارائه‌شده توسط کاربر کار می‌کنند\&. .sp یک نمونه از یک کلاینت ساده که یک شیء منفرد (loose object) را درخواست می‌کند: .sp .if n \{\ .RS 4 .\} .nf $GIT_URL: http://example\&.com:8080/git/repo\&.git URL request: http://example\&.com:8080/git/repo\&.git/objects/d0/49f6c27a2244e12041955e262a404c7faba355 .fi .if n \{\ .RE .\} .sp یک نمونه از یک درخواست هوشمند به یک درگاه همه‌منظوره (catch\-all gateway): .sp .if n \{\ .RS 4 .\} .nf $GIT_URL: http://example\&.com/daemon\&.cgi?svc=git&q= URL request: http://example\&.com/daemon\&.cgi?svc=git&q=/info/refs&service=git\-receive\-pack .fi .if n \{\ .RE .\} .sp یک نمونه از یک درخواست به یک زیرماژول (submodule): .sp .if n \{\ .RS 4 .\} .nf $GIT_URL: http://example\&.com/git/repo\&.git/path/submodule\&.git URL request: http://example\&.com/git/repo\&.git/path/submodule\&.git/info/refs .fi .if n \{\ .RE .\} .sp کلاینت‌ها باید در صورت وجود، اسلش پایانی \fB/\fR را از انتهای رشته \fB$GIT_URL\fR ارائه‌شده توسط کاربر حذف کنند تا از ظاهر شدن توکن‌های مسیر خالی (\fB//\fR) در نشانی‌های URL ارسالی به سرور جلوگیری شود\&. کلاینت‌های سازگار باید \fB$GIT_URL/info/refs\fR را به صورت \fBfoo/info/refs\fR گسترش دهند نه \fBfoo//info/refs\fR\&. .SH "احراز هویت (AUTHENTICATION)" .sp در صورتی که برای دسترسی به یک مخزن نیاز به احراز هویت باشد، از احراز هویت استاندارد HTTP استفاده می‌شود و ممکن است توسط نرم‌افزار سرور HTTP پیکربندی و اعمال گردد\&. .sp از آنجا که مخازن گیت از طریق اجزای استاندارد مسیر در دسترس هستند، مدیران سرور می‌توانند از مجوزهای مبتنی بر دایرکتوری در وب‌سرور HTTP خود برای کنترل دسترسی به مخزن استفاده کنند\&. .sp کلاینت‌ها باید از احراز هویت پایه (Basic authentication) مطابق با RFC 2617 پشتیبانی کنند\&. سرورها باید با اتکا به سرور HTTP قرار گرفته در جلوی نرم‌افزار سرور گیت، از احراز هویت Basic پشتیبانی نمایند\&. .sp سرورها نباید برای اهداف احراز هویت یا کنترل دسترسی نیازمند کوکی‌های HTTP باشند\&. .sp کلاینت‌ها و سرورها می‌توانند از سایر روش‌های رایج احراز هویت مبتنی بر HTTP مانند احراز هویت چکیده (Digest authentication) پشتیبانی کنند\&. .SH "اس‌اس‌ال (SSL)" .sp کلاینت‌ها و سرورها باید از SSL پشتیبانی کنند، به ویژه برای محافظت از گذرواژه‌ها هنگام اتکا به احراز هویت Basic در HTTP\&. .SH "وضعیت نشست (SESSION STATE)" .sp پروتکل گیت روی HTTP (همانند خود HTTP) از دیدگاه سمت سرور HTTP بدون حالت (stateless) است\&. تمام وضعیت‌ها باید توسط فرآیند کلاینت نگهداری و مدیریت شوند\&. این امر توزیع بار نوبتی (round\-robin load\-balancing) ساده در سمت سرور را بدون نیاز به نگرانی درباره مدیریت وضعیت ممکن می‌سازد\&. .sp کلاینت‌ها نباید برای عملکرد صحیح نیازمند مدیریت وضعیت در سمت سرور باشند\&. .sp سرورها نباید برای عملکرد صحیح نیازمند کوکی‌های HTTP باشند\&. کلاینت‌ها می‌توانند هنگام پردازش درخواست، مطابق با RFC 2616 (HTTP/1\&.1) کوکی‌های HTTP را ذخیره و ارسال کنند\&. سرورها باید کوکی‌های ارسالی توسط کلاینت را نادیده بگیرند\&. .SH "پردازش عمومی درخواست‌ها (GENERAL REQUEST PROCESSING)" .sp به جز مواردی که ذکر شده است، تمام رفتارهای استاندارد HTTP باید از سوی هر دو طرف کلاینت و سرور فرض شود\&. این شامل موارد زیر است (اما لزوماً محدود به آن‌ها نیست): .sp اگر هیچ مخزنی در \fB$GIT_URL\fR وجود نداشته باشد، یا منبعی که توسط مکانی منطبق بر \fB$GIT_URL\fR اشاره شده موجود نباشد، سرور نباید با پاسخ \fB200\fR \fBOK\fR پاسخ دهد\&. سرور باید با \fB404\fR \fBNot\fR \fBFound\fR، \fB410\fR \fBGone\fR، یا هر کد وضعیت مناسب دیگر HTTP که دلالت بر وجود منبع درخواستی ندارد پاسخ دهد\&. .sp اگر مخزنی در \fB$GIT_URL\fR وجود داشته باشد اما دسترسی در حال حاضر مجاز نباشد، سرور باید با کد وضعیت HTTP \fB403\fR \fBForbidden\fR پاسخ دهد\&. .sp سرورها باید از هر دو نسخه HTTP 1\&.0 و HTTP 1\&.1 پشتیبانی کنند\&. سرورها باید از کدگذاری تکه‌ای (chunked encoding) برای بدنه درخواست و پاسخ پشتیبانی کنند\&. .sp کلاینت‌ها باید از هر دو نسخه HTTP 1\&.0 و HTTP 1\&.1 پشتیبانی کنند\&. کلاینت‌ها باید از کدگذاری تکه‌ای (chunked encoding) برای بدنه درخواست و پاسخ پشتیبانی کنند\&. .sp سرورها می‌توانند هدرهای ETag و/یا Last\-Modified را بازگردانند\&. .sp کلاینت‌ها می‌توانند با گنجاندن هدرهای درخواست If\-Modified\-Since و/یا If\-None\-Match، موجودیت‌های ذخیره‌شده در حافظه نهان (کَش) را مجدداً اعتبارسنجی کنند\&. .sp در صورتی که هدرهای مربوطه در درخواست موجود باشند و موجودیت تغییری نکرده باشد، سرورها می‌توانند \fB304\fR \fBNot\fR \fBModified\fR را بازگردانند\&. کلاینت‌ها باید با استفاده مجدد از موجودیت ذخیره‌شده، رفتاری کاملاً یکسان با \fB304\fR \fBNot\fR \fBModified\fR نسبت به \fB200\fR \fBOK\fR داشته باشند\&. .sp اگر هدر Cache\-Control و/یا Expires اجازه کش کردن را بدهد، کلاینت‌ها می‌توانند موجودیت ذخیره‌شده را بدون اعتبارسنجی مجدد استفاده کنند\&. کلاینت‌ها و سرورها باید از RFC 2616 برای کنترل‌های حافظه نهان پیروی کنند\&. .SH "کشف ارجاعات (DISCOVERING REFERENCES)" .sp تمام کلاینت‌های HTTP باید تبادل واکشی (fetch) یا ارسال (push) را با کشف ارجاعات موجود در مخزن راه دور آغاز کنند\&. .SS "کلاینت‌های ساده (Dumb Clients)" .sp کلاینت‌های HTTP که فقط از پروتکل «ساده» پشتیبانی می‌کنند باید ارجاعات را با ایجاد درخواستی برای فایل ویژه info/refs مخزن کشف نمایند\&. .sp کلاینت‌های ساده HTTP باید یک درخواست \fBGET\fR به \fB$GIT_URL/info/refs\fR بدون هیچ پارامتر جستجو یا پرس‌وجو (query parameter) ارسال کنند\&. .sp .if n \{\ .RS 4 .\} .nf C: GET $GIT_URL/info/refs HTTP/1\&.0 .fi .if n \{\ .RE .\} .sp .if n \{\ .RS 4 .\} .nf S: 200 OK S: S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1\&.0 S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1\&.0^{} .fi .if n \{\ .RE .\} .sp مقدار Content\-Type برای موجودیت بازگشتی info/refs باید \fBtext/plain\fR; \fBcharset=utf\-8\fR باشد، اما می‌تواند هر نوع محتوایی نیز باشد\&. کلاینت‌ها نباید تلاشی برای اعتبارسنجی Content\-Type بازگشتی انجام دهند\&. سرورهای ساده نباید نوع بازگشتی را با پیشوند \fBapplication/x\-git\-\fR بازگردانند\&. .sp برای غیرفعال کردن ذخیره موجودیت بازگشتی در حافظه نهان، ممکن است هدرهای Cache\-Control بازگردانده شوند\&. .sp کلاینت‌ها هنگام بررسی پاسخ فقط باید کد وضعیت HTTP را بررسی کنند\&. پاسخ‌های معتبر شامل \fB200\fR \fBOK\fR یا \fB304\fR \fBNot\fR \fBModified\fR هستند\&. .sp محتوای بازگردانده‌شده یک فایل متنی با فرمت یونیکس است که هر ارجاع (ref) و مقدار شناخته‌شده آن را توصیف می‌کند\&. این فایل باید بر اساس نام و طبق ترتیب C locale مرتب شده باشد\&. این فایل نباید شامل ارجاع پیش‌فرض به نام \fBHEAD\fR باشد\&. .sp .if n \{\ .RS 4 .\} .nf info_refs = *( ref_record ) ref_record = any_ref / peeled_ref .fi .if n \{\ .RE .\} .sp .if n \{\ .RS 4 .\} .nf any_ref = obj\-id HTAB refname LF peeled_ref = obj\-id HTAB refname LF obj\-id HTAB refname "^{}" LF .fi .if n \{\ .RE .\} .SS "کلاینت‌های هوشمند (Smart Clients)" .sp کلاینت‌های HTTP که از پروتکل «هوشمند» (یا هر دو پروتکل «هوشمند» و «ساده») پشتیبانی می‌کنند باید ارجاعات را با ارسال یک درخواست پارامتری برای فایل info/refs مخزن کشف کنند\&. .sp درخواست باید دقیقاً شامل یک پارامتر پرسمان باشد: \fBservice=$servicename\fR، که در آن \fB$servicename\fR باید نام سرویسی باشد که کلاینت تمایل دارد برای تکمیل عملیات با آن تماس بگیرد\&. درخواست نباید حاوی پارامترهای اضافی پرسمان باشد\&. .sp .if n \{\ .RS 4 .\} .nf C: GET $GIT_URL/info/refs?service=git\-upload\-pack HTTP/1\&.0 .fi .if n \{\ .RE .\} .sp پاسخ سرور ساده: .sp .if n \{\ .RS 4 .\} .nf S: 200 OK S: S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1\&.0 S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1\&.0^{} .fi .if n \{\ .RE .\} .sp پاسخ سرور هوشمند: .sp .if n \{\ .RS 4 .\} .nf S: 200 OK S: Content\-Type: application/x\-git\-upload\-pack\-advertisement S: Cache\-Control: no\-cache S: S: 001e# service=git\-upload\-pack\en S: 0000 S: 004895dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\e0multi_ack\en S: 003fd049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\en S: 003c2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1\&.0\en S: 003fa3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1\&.0^{}\en S: 0000 .fi .if n \{\ .RE .\} .sp کلاینت ممکن است پارامترهای اضافی (Extra Parameters - به \fBgitprotocol-pack\fR(5) مراجعه کنید) را به عنوان رشته‌ای جداشده با دونقطه در هدر HTTP به نام Git\-Protocol ارسال کند\&. .sp از گزینه \fB\-\-http\-backend\-info\-refs\fR در دستور \fBgit-upload-pack\fR(1) استفاده می‌کند\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBپاسخ سرور ساده\fR .RS 4 .sp سرورهای ساده باید با قالب پاسخ سرور ساده پاسخ دهند\&. .sp برای توضیح دقیق‌تر پاسخ سرور ساده به بخش قبلی ذیل کلاینت‌های ساده مراجعه کنید\&. .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBپاسخ سرور هوشمند\fR .RS 4 .sp اگر سرور نام سرویس درخواستی را تشخیص ندهد، یا نام سرویس درخواستی توسط مدیر سرور غیرفعال شده باشد، سرور باید با کد وضعیت HTTP \fB403\fR \fBForbidden\fR پاسخ دهد\&. .sp در غیر این صورت، سرورهای هوشمند باید با قالب پاسخ سرور هوشمند برای نام سرویس درخواستی پاسخ دهند\&. .sp هدرهای Cache\-Control باید برای غیرفعال کردن کش شدن موجودیت بازگشتی استفاده شوند\&. .sp مقدار Content\-Type باید \fBapplication/x\-$servicename\-advertisement\fR باشد\&. کلاینت‌ها در صورتی که نوع محتوای دیگری بازگردانده شود، باید به پروتکل ساده بازگردند (fall back)\&. هنگام بازگشت به پروتکل ساده، کلاینت‌ها نباید درخواست دیگری به \fB$GIT_URL/info/refs\fR ارسال کنند، بلکه باید از پاسخی که در دست دارند استفاده کنند\&. اگر کلاینت‌ها از پروتکل ساده پشتیبانی نمی‌کنند، نباید ادامه دهند\&. .sp کلاینت‌ها باید اعتبارسنجی کنند که کد وضعیت یکی از دو مقدار \fB200\fR \fBOK\fR یا \fB304\fR \fBNot\fR \fBModified\fR باشد\&. .sp کلاینت‌ها باید اعتبارسنجی کنند که پنج بایت اول پاسخ با عبارت منظم \fB^\fR[\fB0\-9a\-f\fR]{4}# مطابقت داشته باشد\&. اگر این بررسی ناموفق باشد، کلاینت‌ها نباید ادامه دهند\&. .sp کلاینت‌ها باید کل پاسخ را به صورت دنباله‌ای از رکوردهای pkt\-line تجزیه کنند\&. .sp کلاینت‌ها باید بررسی کنند که اولین pkt\-line برابر با # \fBservice=$servicename\fR باشد\&. سرورها باید مقدار $servicename را برابر با مقدار پارامتر درخواستی قرار دهند\&. سرورها باید یک LF در پایان این خط بگنجانند\&. کلاینت‌ها باید کاراکتر LF در انتهای خط را نادیده بگیرند\&. .sp سرورها باید پاسخ را با نشانگر جادویی پایان pkt\-line یعنی \fB0000\fR خاتمه دهند\&. .sp پاسخ بازگردانده‌شده یک جریان از pkt\-line است که هر ارجاع و مقدار شناخته‌شده آن را توصیف می‌کند\&. جریان باید بر اساس نام و مطابق با ترتیب C locale مرتب شده باشد\&. جریان باید ارجاع پیش‌فرض به نام \fBHEAD\fR را به عنوان اولین ارجاع شامل شود\&. جریان باید اعلان‌های قابلیت‌ها (capabilities) را پس از یک NUL در اولین ارجاع بگنجاند\&. .sp اگر "version=1" به عنوان پارامتر اضافی ارسال شده باشد، پاسخ بازگردانده‌شده حاوی "version 1" خواهد بود\&. .sp .if n \{\ .RS 4 .\} .nf smart_reply = PKT\-LINE("# service=$servicename" LF) "0000" *1("version 1") ref_list "0000" ref_list = empty_list / non_empty_list .fi .if n \{\ .RE .\} .sp .if n \{\ .RS 4 .\} .nf empty_list = PKT\-LINE(zero\-id SP "capabilities^{}" NUL cap\-list LF) .fi .if n \{\ .RE .\} .sp .if n \{\ .RS 4 .\} .nf non_empty_list = PKT\-LINE(obj\-id SP name NUL cap_list LF) *ref_record .fi .if n \{\ .RE .\} .sp .if n \{\ .RS 4 .\} .nf cap\-list = capability *(SP capability) capability = 1*(LC_ALPHA / DIGIT / "\-" / "_") LC_ALPHA = %x61\-7A .fi .if n \{\ .RE .\} .sp .if n \{\ .RS 4 .\} .nf ref_record = any_ref / peeled_ref any_ref = PKT\-LINE(obj\-id SP name LF) peeled_ref = PKT\-LINE(obj\-id SP name LF) PKT\-LINE(obj\-id SP name "^{}" LF .fi .if n \{\ .RE .\} .RE .SH "سرویس هوشمند GIT\-UPLOAD\-PACK (SMART SERVICE GIT\-UPLOAD\-PACK)" .sp این سرویس از مخزنی که توسط \fB$GIT_URL\fR مشخص شده است می‌خواند\&. .sp کلاینت‌ها ابتدا باید فرآیند کشف ارجاع را با \fB$GIT_URL/info/refs\fR?service=git\-upload\-pack انجام دهند\&. .sp .if n \{\ .RS 4 .\} .nf C: POST $GIT_URL/git\-upload\-pack HTTP/1\&.0 C: Content\-Type: application/x\-git\-upload\-pack\-request C: C: 0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7\en C: 0032have 441b40d833fdfa93eb2908e52742248faf0ee993\en C: 0000 .fi .if n \{\ .RE .\} .sp .if n \{\ .RS 4 .\} .nf S: 200 OK S: Content\-Type: application/x\-git\-upload\-pack\-result S: Cache\-Control: no\-cache S: S: \&.\&.\&.\&.ACK %s, continue S: \&.\&.\&.\&.NAK .fi .if n \{\ .RE .\} .sp کلاینت‌ها نباید یک پاسخ ذخیره‌شده در حافظه نهان را مجدداً استفاده یا اعتبارسنجی کنند\&. سرورها باید هدرهای Cache\-Control کافی برای جلوگیری از کش شدن پاسخ را درج نمایند\&. .sp سرورها باید از تمام قابلیت‌های تعریف‌شده در اینجا پشتیبانی کنند\&. .sp کلاینت‌ها باید حداقل یک دستور "want" را در بدنه درخواست ارسال نمایند\&. کلاینت‌ها نباید به شناسه‌ای در دستور "want" ارجاع دهند که در پاسخ دریافتی از طریق کشف ارجاع وجود نداشته است، مگر اینکه سرور قابلیت \fBallow\-tip\-sha1\-in\-want\fR یا \fBallow\-reachable\-sha1\-in\-want\fR را اعلان کرده باشد\&. .sp .if n \{\ .RS 4 .\} .nf compute_request = want_list have_list request_end request_end = "0000" / "done" .fi .if n \{\ .RE .\} .sp .if n \{\ .RS 4 .\} .nf want_list = PKT\-LINE(want SP cap_list LF) *(want_pkt) want_pkt = PKT\-LINE(want LF) want = "want" SP id cap_list = capability *(SP capability) .fi .if n \{\ .RE .\} .sp .if n \{\ .RS 4 .\} .nf have_list = *PKT\-LINE("have" SP id LF) .fi .if n \{\ .RE .\} .sp در دست تکمیل: این بخش در آینده کامل‌تر مستندسازی خواهد شد\&. .SS "الگوریتم مذاکره (The Negotiation Algorithm)" .sp محاسبه برای انتخاب کمینه بسته (pack) به صورت زیر پیش می‌رود (C = کلاینت، S = سرور): .sp \fIگام مقداردهی اولیه:\fR .sp C: استفاده از فرآیند کشف ارجاع برای دریافت ارجاعات اعلان‌شده\&. .sp C: قرار دادن هر شیء دیده‌شده در مجموعه \fBadvertised\fR\&. .sp C: ساخت یک مجموعه خالی به نام \fBcommon\fR، برای نگهداری اشیایی که بعداً مشخص می‌شود در هر دو سمت وجود دارند\&. .sp C: ساخت یک مجموعه به نام \fBwant\fR از اشیای موجود در \fBadvertised\fR که کلاینت می‌خواهد بر اساس آنچه حین کشف ارجاع دیده واکشی کند\&. .sp C: آغاز یک صف به نام \fBc_pending\fR که بر اساس زمان ثبت (commit time) مرتب شده است (برداشتن جدیدترین‌ها در ابتدا)\&. افزودن تمام ارجاعات کلاینت\&. هنگامی که یک کامیت از صف برداشته می‌شود، والدین آن باید به طور خودکار دوباره در صف درج شوند\&. هر کامیت فقط باید یک بار وارد صف شود\&. .sp \fIیک گام محاسبه:\fR .sp C: ارسال یک درخواست \fB$GIT_URL/git\-upload\-pack\fR: .sp .if n \{\ .RS 4 .\} .nf C: 0032want \&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&. C: 0032want \&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&. \&.\&.\&.\&. C: 0032have \&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&. C: 0032have \&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&. \&.\&.\&.\&. C: 0032have \&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&. C: 0032have \&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&. \&.\&.\&.\&. C: 0000 .fi .if n \{\ .RE .\} .sp جریان داده‌ها به صورت «دستورها» سازماندهی شده است، که هر دستور به صورت مجزا در یک pkt\-line قرار دارد\&. در یک خط دستور، متن قبل از اولین فاصله نام دستور است و باقی‌مانده خط تا اولین LF مقدار آن را تشکیل می‌دهد\&. خطوط دستور با یک LF به عنوان آخرین بایت مقدار pkt\-line خاتمه می‌یابند\&. .sp دستورها در صورت حضور در جریان درخواست، باید دقیقاً به ترتیب زیر باشند: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} "want" .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} "have" .RE .sp جریان با یک تخلیه‌کننده pkt\-line خاتمه می‌یابد (\fB0000\fR)\&. .sp یک دستور "want" یا "have" منفرد باید دقیقاً دارای یک نام شیء با قالب هگزادسیمال به عنوان مقدار خود باشد\&. چند نام شیء باید با ارسال چند دستور جداگانه فرستاده شوند\&. نام‌های اشیاء باید با استفاده از قالب شیء مورد توافق از طریق قابلیت \fBobject\-format\fR (به طور پیش‌فرض SHA\-1) ارائه شوند\&. .sp لیست \fBhave\fR با بیرون کشیدن ۳۲ کامیت نخست از صف \fBc_pending\fR ایجاد می‌شود\&. اگر \fBc_pending\fR زودتر خالی شود، تعداد کمتری فرستاده می‌شود\&. .sp اگر کلاینت ۲۵۶ کامیت "have" ارسال کرده باشد و هنوز هیچ‌یک از آن‌ها را از طرف \fBs_common\fR دریافت نکرده باشد، یا صف \fBc_pending\fR کلاینت خالی شده باشد، باید دستور "done" را ارسال کند تا به سرور اطلاع دهد کار را ادامه نخواهد داد: .sp .if n \{\ .RS 4 .\} .nf C: 0009done .fi .if n \{\ .RE .\} .sp S: تجزیه درخواست git\-upload\-pack: .sp بررسی اینکه تمام اشیای موجود در \fBwant\fR مستقیماً از ارجاعات قابل دسترسی باشند\&. .sp سرور ممکن است برای مجاز دانستن درخواست‌های کمی قدیمی، تاریخچه را به عقب بپیماید یا در reflog جستجو کند\&. .sp اگر هیچ شیء "want" دریافت نشد، یک خطا بفرستد: در دست تکمیل: تعریف خطا در صورتی که هیچ خط "want" درخواست نشده باشد\&. .sp اگر هر یک از اشیای "want" قابل دسترسی نباشند، یک خطا بفرستد: هنگامی که یک سرور گیت خط \fBwant\fR نامعتبر یا بدریختی دریافت می‌کند، با یک پیام خطا که شامل نام شیء متخلف است پاسخ می‌دهد\&. .sp یک لیست خالی به نام \fBs_common\fR بسازد\&. .sp اگر "have" ارسال شده بود: .sp پیمایش روی اشیاء به همان ترتیبی که کلاینت ارائه کرده است\&. .sp برای هر شیء، اگر سرور آن شیء را به صورت قابل دسترسی از یک ارجاع داشته باشد، آن را به \fBs_common\fR اضافه کند\&. اگر کامیتی به \fBs_common\fR اضافه شود، هیچ‌یک از اجداد آن نباید اضافه شوند، حتی اگر آن‌ها نیز در \fBhave\fR آمده باشند\&. .sp S: ارسال پاسخ git\-upload\-pack: .sp اگر سرور مجموعه بسته‌ای از اشیاء را برای بسته‌بندی یافته باشد یا درخواست با "done" خاتمه یافته باشد، با بسته (pack) پاسخ می‌دهد\&. در دست تکمیل: مستندسازی پاسخ مبتنی بر بسته .sp .if n \{\ .RS 4 .\} .nf S: PACK\&.\&.\&. .fi .if n \{\ .RE .\} .sp جریان بازگردانده‌شده پروتکل side\-band\-64k است که توسط سرویس git\-upload\-pack پشتیبانی می‌شود، و بسته در جریان شماره ۱ جاسازی می‌شود\&. پیام‌های پیشرفت از سمت سرور ممکن است در جریان شماره ۲ ظاهر شوند\&. .sp در اینجا یک «مجموعه بسته از اشیاء» به گونه‌ای تعریف می‌شود که حداقل یک مسیر از هر شیء "want" به حداقل یک شیء "common" وجود داشته باشد\&. .sp اگر سرور به اطلاعات بیشتری نیاز داشته باشد، با یک پاسخ ادامه وضعیت پاسخ می‌دهد: در دست تکمیل: مستندسازی پاسخ غیربسته‌ای .sp C: تجزیه پاسخ upload\-pack: در دست تکمیل: مستندسازی تجزیه پاسخ .sp \fIانجام یک گام محاسبه دیگر\&.\fR .SH "سرویس هوشمند GIT\-RECEIVE\-PACK (SMART SERVICE GIT\-RECEIVE\-PACK)" .sp این سرویس از مخزنی که توسط \fB$GIT_URL\fR اشاره شده است می‌خواند\&. .sp کلاینت‌ها ابتدا باید کشف ارجاع را با \fB$GIT_URL/info/refs\fR?service=git\-receive\-pack انجام دهند\&. .sp .if n \{\ .RS 4 .\} .nf C: POST $GIT_URL/git\-receive\-pack HTTP/1\&.0 C: Content\-Type: application/x\-git\-receive\-pack\-request C: C: \&.\&.\&.\&.0a53e9ddeaddad63ad106860237bbf53411d11a7 441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\e0 report\-status C: 0000 C: PACK\&.\&.\&.\&. .fi .if n \{\ .RE .\} .sp .if n \{\ .RS 4 .\} .nf S: 200 OK S: Content\-Type: application/x\-git\-receive\-pack\-result S: Cache\-Control: no\-cache S: S: \&.\&.\&.\&. .fi .if n \{\ .RE .\} .sp کلاینت‌ها نباید یک پاسخ کش‌شده را مجدداً استفاده یا اعتبارسنجی کنند\&. سرورها باید هدرهای Cache\-Control کافی برای جلوگیری از کش شدن پاسخ را درج کنند\&. .sp سرورها باید از تمام قابلیت‌های تعریف‌شده در اینجا پشتیبانی کنند\&. .sp کلاینت‌ها باید حداقل یک دستور در بدنه درخواست ارسال کنند\&. در بخش دستور از بدنه درخواست، کلاینت‌ها باید شناسه‌ای را که از طریق کشف ارجاع به دست آورده‌اند به عنوان old_id ارسال کنند\&. .sp .if n \{\ .RS 4 .\} .nf update_request = command_list "PACK" .fi .if n \{\ .RE .\} .sp .if n \{\ .RS 4 .\} .nf command_list = PKT\-LINE(command NUL cap_list LF) *(command_pkt) command_pkt = PKT\-LINE(command LF) cap_list = *(SP capability) SP .fi .if n \{\ .RE .\} .sp .if n \{\ .RS 4 .\} .nf command = create / delete / update create = zero\-id SP new_id SP name delete = old_id SP zero\-id SP name update = old_id SP new_id SP name .fi .if n \{\ .RE .\} .sp در دست تکمیل: این بخش در آینده کامل‌تر مستندسازی خواهد شد\&. .SH "منابع (REFERENCES)" .sp \m[blue]\fBRFC 1738: Uniform Resource Locators (URL)\fR\m[]\&\s-2\u[1]\d\s+2 \m[blue]\fBRFC 2616: Hypertext Transfer Protocol \(em HTTP/1\&.1\fR\m[]\&\s-2\u[2]\d\s+2 .SH "همچنین ببینید (SEE ALSO)" .sp \fBgitprotocol-pack\fR(5) \fBgitprotocol-capabilities\fR(5) .SH "گیت (GIT)" .sp بخشی از مجموعه \fBgit\fR(1) .SH "نکات (NOTES)" .IP " 1." 4 RFC 1738: Uniform Resource Locators (URL) .RS 4 \%https://www.ietf.org/rfc/rfc1738.txt .RE .IP " 2." 4 RFC 2616: Hypertext Transfer Protocol \(em HTTP/1.1 .RS 4 \%https://www.ietf.org/rfc/rfc2616.txt .RE